|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Rate this entry!
This poll has expired.
|
||||||||||||||||||||||||||||
Author | Message | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
[Coding competition 2013] Gravity Beam: Master Gaiden by MrD
Posted: Tue Mar 26, 2013 8:19 am Last edited by Maxim on Fri Mar 29, 2013 2:36 pm; edited 1 time in total |
|||||||||||||||||||||||||||
http://www.smspower.org/Homebrew/GravityBeamMasterGaiden-SMS
|
||||||||||||||||||||||||||||
|
Posted: Fri Mar 29, 2013 2:28 pm | |||||||||||||||||||||||||||
Nice visuals, good music and good (if short) gameplay. Seems to be the most polished among the coding entries. | ||||||||||||||||||||||||||||
|
Posted: Fri Mar 29, 2013 3:14 pm | |||||||||||||||||||||||||||
The most awesome intro ever seem in a homebrew game, as well as a great ending. I'd have preferred to have damage from wall collisions, to make it more skilful on the way in, but the Sonic Crackers-like connection is interesting and makes the way out more challenging, but not actually that hard. I think we need to have some competitions for the winning time... | ||||||||||||||||||||||||||||
|
Posted: Fri Mar 29, 2013 5:35 pm | |||||||||||||||||||||||||||
That intro is great !
Music is very lovely too. Gameplay is challenging, really haha. Thrust is very powerful, it is so easy to end up in a wall or such hehe. |
||||||||||||||||||||||||||||
|
Posted: Fri Mar 29, 2013 11:21 pm | |||||||||||||||||||||||||||
The ship and the way it moves reminds me of the racoon ship in star control. Maybe my old mind is just going fuzzy. Very well done, but I'm not very good at playing it though. Mars has exploded many times... | ||||||||||||||||||||||||||||
|
Posted: Sun Apr 07, 2013 8:03 pm | |||||||||||||||||||||||||||
This is pretty damn beautiful. The presentation is awesome. The game itself is quite short but the engine seems solid. It's cool that you went for a spring model for the gravity beam rather than the stiff rod found in most Thrust clones.
If I were to criticise anything I'd say that it's a little bit easy. The thrusters are very powerful meaning it's never hard to overcome inertia (unless you go up to crazy speeds), and the bomb is able to take quite a beating without blowing up. I made some pretty reckless runs but it wasn't until I read the manual I realised that it can actually explode on me. |
||||||||||||||||||||||||||||
|
Posted: Mon Apr 08, 2013 5:31 pm | |||||||||||||||||||||||||||
Thanks for all the kinds words on my game, folks. :)
I'll upload the source code when I can. It's useless as a single source file; there's a bunch of other tools and input files that are needed to make sense of how the game functions, and they're not very pretty right now. The concept of Gravity Beam is a combination of the Amiga PD games Gravity Force 2 and Tractor Beam. Gravity Beam itself is an Amiga 500 game I wrote last year. Gravity Beam: Master Gaiden is, well, a Master System gaiden of the original! The two games are vastly different, but very similar, if that makes sense. I hope it's alright that it's kind of a port, but you folks know more than anyone that a game for a Z80 can be just as awesome as one written for a Motorola 68000. :P The code started out on Jan 16th as a music player. I'd never written for the SMS before, nor written Z80 code before. I'd also never written a music player for a console before, (one look at the Amiga Protracker player code made my head spin), but after finally working out what 'the objective' of the player was, the hard part was coming up with a format that didn't take up multiple kB per minute. After getting the music player working, I needed to write a bunch of tools that let me write music modules using a spreadsheet as an editor. (There's also a tool that 'rasterises' these binary modules to a wav file, but I haven't updated it to match the latest module format so it's useless.) I then got smooth 2D scrolling working, which was not-to-straightforward: the level is a grid of 2x2 tile megatiles which means monkeying around working out which half of a megatile is appearing as you scroll. And then you need some graphics to display which means either drawing new tiles or re-using ones you already have (Gravity Beam!). And, of course, you need to set up an editor (Thanks, Tiled!!). And I figured I may as well do things the proper way and redraw all the Gravity Beam tiles completely so that they were constructed from reusable 8x8 tile pieces rather than all being completely unique graphics. And then since I'd got this far, I wondered how long it would take to turn into a real game. Turns out, not very long! Most of GBMG's code is presentation stuff. I'd say about 60% of the time I spent on the game was the non-interactive scenes and the menus. 30% was rewriting stuff I'd already done to make it Absolutely Definitely Work on everything I could find. It's crazy how you can write things that seem perfectly reasonable at the time, but when you come back to read them later you think that they could only possibly work 'by coincidence'. All the routines in the final GBMG are well-tempered machines that make me grin like an idiot whenever I re-read them. I went through at least three versions of the algorithm that puts new rows and columns of tiles on the side of the screen, and finally hit on one that didn't need the stack, which was awesome. I am especially pleased about the ending cutscene. Right up until the last day before I submitted the game, that didn't work on hardware. The 'Big Ship' that you see first is constructed from around 92 sprites, which means I need to switch between two sprite A.tables with a Hblank interrupt. I wrote what I thought was a straightforward routine that had mostly-overlapping sprite tables, so that even if there was a glitch, it would be displaying the correct tile, but I kept having multiple glitchy lines when the transition occured. One annoying thing is that Emukon is 'the emulator that does the VDP access timing thing' (which I'd consider to be a major oversight in every other emulator ever), but even Emukon would emulate my Big Ship cutscene as working but my PAL SMS II would show missing lines. I was worried that what I was trying to do was impossible (there are some posts by Charles MacDonald on SMSPOWER that recommend leaving a blank line between changing parameters of the VDP, meaning I couldn't have a massive unbroken ship sprite), but I really wanted to get it right. My plan was to delay the change in parameters until the composition beam was to the right of the Big Ship, so that even if there was a glitch, it would be displaying nothing there anyway, and the system would have enough time before the next visible entity to cache its whatnots and display the next line of sprites correctly. Basically, adding NOPs and useless PUSH/POPs until I got the OUT write timed at the single correct horizontal position for this to work. I set up my laptop and EEPROM gear in front of the VCR, ready for several hours of taping and rewinding the scene until I got it right. I typed in the first arbitrary combination that came to mind and as luck would have it, it worked perfectly. I think it was divine inspiration. There are some routines that I didn't write: there's 16-bit multiplication, division and square root routines from z80bits. I'm afraid I just don't get the magic there yet. The game is short because a level grid turns out to be around 2k big. I didn't have enough space to put more than one level in; I was writing primarily for my 32kByte EEPROM cart which I built last year. To get big things like the graphics for the level scenery, the level layout grid, and the big cutscene graphics all fitting in, I wrote what I think is a quite nifty Huffman compression tool that takes in a list of files and Huffman compresses them by their nibbles. The tool produces a z80 decompressor with the decompression tree baked into the code. This is why there's such a big delay when restarting the level, and why the music hangs momentarily just before the title screen. Sorry if you opened the ROM in a hex editor hoping to simply see a familiar level-like shape siting in there. It's all one great big high-entropy splodge. :) Though if you open GBMG as a 64px wide 512px tall greyscale paletted image, you can see the different compressed graphics like layers in rock! And the music tracks have a very distinctive dot-dash pattern to them as my music command for 'wait for 1 frame, then set channel 1 to midi note 30 and set channel 2 to midi note 40' is encoded as a repeating sequence of {0x81, 0x01, 0x30, 0x02, 0x40}. I'm surprised at how close I got the SMS game is to the Amiga one. The SMS game has a much more vivid colour palette (Which I think look loads better. I can't stand to look at the Amiga one any more!), and the level is much denser as it was designed for a 248x192 screen rather than 320x240. Also, in the original GB, when the box exploded it simply reappeared at its starting point. You'd have to fly all the way back through the cave and pick up another box. (This rule is taken straight from Tractor Beam.) On top of that, there's a fixed time penalty for each box breakage, which I realised was redundant and harsh about half way through writing the game, but I couldn't be bothered to re-work the level end stats screen to remove it. The Mars bomb plot came about after I concluded it would be faster to make the level restart after the box explodes. Plus, it gave me an excuse to have a Big Scary Timer at the top of the game screen, and a Big Scary Game Over Screen with BIG RED LETTERS to scare kids when everything goes wrong. I think I got the difficulty right this time. Folks who've played Thrust games before seem to think that it's easy (Has anybody got a time better than 4:10.00 yet?), and folks who haven't seem to think that it's hard. I can't win! Five minutes is plenty of time to complete the mission if you're being super slow and only tapping the button, but the super strong thrusters allow you to carve out vast arcs and dash through the obstacles if you know what you're doing. I'm also relieved that you don't find the music offensive... it's the first time using these new tools, and my aim was to make the music catchy without being painful. I've found that the SMS simply can't do low notes the way I like, and just one octave higher the notes are painful to hear. That's why the ingame music sort of sounds like it's missing a channel. It is! The base GBMG music was recorded with a couple more channels, and I cut out and rearranged it until it was small enough and bearable enough. The SMS game has completely different music to the Amiga one, and it doesn't have separate 'calm' and 'panic' tracks for when you're holding the box. I did make an SMS version of the original GB panic music, but it was unpleasant to listen to... Fun fact: I wrote Gravity Beam without ever having played or seen Thrust. I assumed that Thrust was just about thrusting and shooting. I had no idea when I was making GB that Thrust also had a box. In fact, I still haven't played Thrust! Um... is it any good? |
||||||||||||||||||||||||||||
|
Posted: Mon Apr 08, 2013 8:46 pm | |||||||||||||||||||||||||||
That post is awesome ! I like how how you handled music hehe | ||||||||||||||||||||||||||||
|
Posted: Mon Apr 08, 2013 8:47 pm | |||||||||||||||||||||||||||
Oh, hey, I played Lemmings DS! | ||||||||||||||||||||||||||||
|
Posted: Mon Apr 08, 2013 10:22 pm | |||||||||||||||||||||||||||
Did you enjoy it? :D (Or did you miss hearing 'Ten Green Bottles' too much after I took it out?)
Crikey, that was six years ago! |
||||||||||||||||||||||||||||
|
Posted: Wed Apr 10, 2013 8:30 am | |||||||||||||||||||||||||||
Your game is impressive, the end scene is great!
When I start I thought the ship was too fast, it was impossible, but when you go veeery slowly it's not that hard. But it's a bit frustrating to know you can go so fast. Thanks for the explanations, I hope you'll soon release the sources! How did you export data from Tiled? I looked a little and didn't find a very simple way, so I used Tile Studio for my project (and I didn't like it...). |
||||||||||||||||||||||||||||
|
Posted: Thu Apr 11, 2013 8:10 am | |||||||||||||||||||||||||||
In Tiled, you can save maps in JSON format, which is a plaintext Javascript compatible object. It'll be a big tangle because all the data of the map will be in there.
I've got a HTML file that loads that JSON object, locates the layer with my tiles from its name, does some processing to it in Javascript, and spits out a plaintext block of .db declarations. From there, I converted it to raw binary and put it in my compression system. |
||||||||||||||||||||||||||||
|
Posted: Thu Apr 11, 2013 12:24 pm | |||||||||||||||||||||||||||
The source code is up on the wiki page. There's some instructions and descriptions of how all the stuff works too. If you have any questions, let me know, I write those kind of docs for my own benefit mainly, so I might have not included things that other folks might find useful. | ||||||||||||||||||||||||||||
|
Posted: Thu Apr 11, 2013 8:28 pm | |||||||||||||||||||||||||||
Fantastic game.
Best homebrew sms game i've tried so far. Worked great on the real hardware as well. Voted for it. :) |
||||||||||||||||||||||||||||
|
Posted: Fri Apr 12, 2013 5:31 pm | |||||||||||||||||||||||||||
Thanks for playing my game, tibone! :)
What hardware did you run it on? Did you happen to notice if there was any glitches on the ending screen? (The 'big ship' should appear as a big unbroken sprite... but it's possible it might have a big black horizontal line running through the middle of it if my coding isn't right.) |
||||||||||||||||||||||||||||
|
Posted: Sun Apr 14, 2013 8:47 pm | |||||||||||||||||||||||||||
It's amazingly suspenseful as you try to work against the clock - although the 5 minutes is hardly challenging, trying to get the message for over 4 minutes left on the clock is hard. Maybe some more fine-grain rewards at the fast end, rather than the slow end (did anyone complete it with less than 5 seconds left?) would give me more incentive. But I feel like I'm getting to a personal limit with the speed whereby my control goes all to pot and I end up slower when I try to go faster.
Anyway, here's a time for everyone else to beat. I think that will incentivise me better than the long 32 seconds I have to shave off to get the next message. Overall, for me this is clearly the best entry of the competition, very polished and complete (except for more levels and non-square collisions). And it's nice to see proper maths for the controls - it makes me wonder if my Z80 Box2D-like ideas are not completely stupid :) |
||||||||||||||||||||||||||||