Well, today went really well, I fixed up my collision routines with the scrolling background, yup, it was using a simple offset, with a case for looping every 32 row increments, seems to work well. Possibly un-optimised but good enough so far.
There’s some rudimentary noises from both cars on screen based on their speed and distance from each other, also collision noises are in there now.
The fuel-o-meter has turned into a working turbo bar to help catch-up or overtake other racers. It’s getting there, but I’m down to 4kb of ROM remaining now and the racer A.I. needs improving on the sly. I’d like to get some BGM in there also somehow.
CPU Usage is getting pretty high now though, so I may need to inestigate into other ways to load my level up. Setting colours for each tile through a switch is probably slower than referencing another variable directly I imagine but, well, a balance needs to be struck.
Tomorrow I’ll most likely be sorting out the code into banks to save space and going from there with more advanced A.I. (Not simple homing, falling of the track A.I.) those cars need to fall foul to going off track also and that’s going to be inetresting to set-up correctly!
Screenshot tonight is from the gameboy classic mode where, yes. Identical cars. I’m not too fussed about that. I am fussed about adding some steering animation though!
Please note that I’ve only done GBDK coding on my Windows Machine so some installation bits may vary depending on your choice of Operating System.
That’s it, that’s the bare minimum you’ll need to get started and get used to bare minimums, because the Gameboy, despite being a well-balanced machine, isn’t powerful, if you’re used to Unity or other modern development tools, this will be quite the step back. Let’s take a brief look at the specs
CPU Speed: 4.19 MHz ( or 0.000419 GHz if you prefer) RAM: 8kb – Expandable to 32kb depending on your ROM Carts settings
And we’re looking at ROM Sizes between 32kb to I think 1Mb. Not much space, and to start we’ll be dealing with 32kb ROM Size only.
Everything Graphical is Tile-based (8×8) and we have a screen resolution of 160 x 144 Pixels, In 4 shades of grey.
And yes, you can still make a game, running at nearly 60FPS on this, cool huh?
Tomorrow we’ll write our first program which will cover that most important thing, getting something on-screen with a few lines of code and running, it’ll be great!
Yay! Turns out it wasn’t too tough to get the collision working there, man, does visual feedback help out a shit ton with coding, I’m loving all the features in BGB, A really great Gameboy Emulator, they really help me out here.
So yeah, hopefully, that GIF will animate and you’ll see the friction applied to the car when it goes off-track. Simple stuff but hey, it’s working well and fairly quickly (I’ve got around 90% of CPU left per frame when the debugging is removed and roughly 70% with debug info being output every frame (not optimal, I know)
I’m going to need some animation frame for the car at some point, so it can at least have some appearance of turning, maybe 2 frames of animation. I can get away with only 8 tiles for that with sprite flipping, which is going to prove to be a great bonus when I get around to sparks and explosions further along the month!
Soo, yeah, next up animation frames and making other collision objects stop the car / explode it into tiny pieces, ohh rahh!
Before I sign off on this update, I should note some other systems I’ll put in ,obvoius control schemes for controlling using A and B for gas and brakes, with the D-Pad for steering, pressing up could use some sorta Turbo maybe. That would be pretty cool to figure out.
There’s still Scrolling, Music, SFX and maybe some rudimentary homing A.I. to add here, but I think the code loops should be tight enough to keep the gameboys 60fps with some cunning compression, I could make some super long levels also.
A few more developments on the racing game were begun tonight and a change of focus seemed to serve me well for once.
I was having a few issues with the background layer scrolling new tile row correctly last night and they were still occurring today so I just commented out the scrolling code for the moment and instead started on some quick sprites and getting some debug info to help me determine which tiles the car is colliding with currently, all whilst keeping variable usage down (so yeah, I’m reusing variables inside loops more now, yay RAM efficiency!)
Nothing too tough tonight but it’s good to have some more data and in-game debugging more of a possibility!
I’ll probably use the white lines as restore points should you explode off-track. They’ll need regular spacing, but that shouldn’t be too tough to sort out tomorrow perhaps? Updated screeny below, with sprites and X ‘n’ Y coordinates in the window (first 3 characters per line).
I figured now’s probably as good a time as any to look through and see where I’m at in terms of features I have working / would like to have working or at least working better.
Gameboy Controller Input
Seems to be all there, but occasionally (rarely) misses tap commands for some reason, I can’t fathom this one out though.
Background, Window and Sprite Handling
This has come along really nicely since when I begun my journey with GBDK, to the point where I now have my own tool to convert png files into usable GBDK data and export it out a plain VRAM for usage in other tools.
Whilst the game itself turned out pretty poorly, the tools I developed were vital for Global Game Jam 2016, making sprites of that size purely in 8×8 groups of pixels would be horrendous!
Sound effects are pretty much there but I’m still without the right method to convert music from a program into byte code and back into a tune on the Gameboy.
Multiple Bank Handling
Seems to be all good, I’ll be doing some crazier bank switching antics in the coming weeks, with an eye into starting and finishing a scrolling shooter, orrr possibly a racing game, it depends on my mood I guess.
Whilst I’ve enjoyed a good streak of results from recent game jams, my first Global Game Jam didn’t go quite as planned, I felt like I was working against the Gameboy throughout the 42 hours of development time available to me, as I hadn’t done any real Gameboy development work since Ludum Dare 34 in mid December, I was going to have a rough ride of sorts in any case. Quite how rough was a bit shocking to me.
Bugs occurring at stupid hours in the morning greatly affected the amount of sleep I got in during the weekend and by Sunday morning , whilst I was determined to have something finished, there really wasn’t much of a game there, although to be fair, a clicker game isn’t much of a game anyways.
There was a lot of coding going on though, for little reward, after some issues, particularly with remembering how multi-banking worked, Waifu Clicker is a clicker game, with randomnly generated characters, password system, some sound effects, difficulty curve and sadly, not much else.
After submitting a working initial build to the Jam site with 2 hours to go I attempted to bung the in-game shop in there but, more issues with decrementing my heart score (an unsigned 8-bit array) after the first pass and general exhaustion left me collapsed at my laptop.
Whilst it’s far from my best work, it proved to be a handy reminder for me to be prepared for game jam events and my preparations this time around were minimal to say the least.
Probably not, haha! I do love making games for the Gameboy though, so I’m going to continue down that line for a while now. It’s still enjoyable to code games for limited hardware for me and it’s taught me a fair amount about code optimisations, which is handy for me in general. There’s also plenty left for me to learn about it, I may have made 3 games in total for it and have one in the pipeline but there’s a lot to learn in that lil system and I’d also quite like to make myself some tools I can use better within the games I make.
I nearly ended up using my own system for the sprites for Novascape, but, sadly it had a small bug, which has now been fixed so I can make more complex backgrounds and sprites with a bit more ease than before!
I might try my hand at making a basic platformer next time around, It would be nice to get a better hang on properly mapped scrolling backgrounds. Then again, They Are Everywhere has been waiting in the wings for quite some time now and really needs completion sometime soon. Ohh decisions, decisions…
Additionally, I put some feelers out on twitter regarding making some videos to help people into Gameboy Development with GBDK as the documentation on getting started with it seems rather scarce out there. I remember searching for hours in an attempt to find a PDF that contained the actual values that converted over to notes! I made my port of Spike Dislike using an inaccurate emulator, which then showed up on actual devices and my current emulator of choice, BGB.
So, I’ll spend a lil bit of time during the Christmas break putting some videos together for the New Year, yeah!
So, last weekend Ludum Dare 34 happened and I really love the Ludum Dare game jam events, my first attempt was way back in Ludum Dare 24 and since then I’ve entered almost every one.
This time around, I set myself the additional challenge of making a Gameboy game and whilst my Flash Cart had just given up the ghost, I persisted with the plan.
For the first time ever, two themes were tied for first place, so I could choose which one to go for. Either “Growth” or Two Button Controls”.
I opted for the latter and within an hour I’d roughly planned out in my mind what I was going to make, essentially a game where you have to escape from a pit, as a spaceman, before the rising lava plume consumes you.
GAMEBOY & GAME ASSETS… OH BOY!
Now, asset creation for the Gameboy isn’t a trivial thing sadly. You’re limited to 4 colours which simplifies things a lot but, GBDK only contains some basic tile editing programs, which I love by the way, thank you very much to the developer of these, they mean I can actually get my hea around things!
So, I’m limited to 8×8 groups of pixels, which is okay for smaller sprites and looping backgrounds, but not so much for creating detailed backgrounds, that becomes a lot more time consuming and error-prone when transposing from Photoshop into each 8×8 tile.
When it comes to sound, it only gets tougher, you don’t just load up a wav file and set it to play, you’re manipulating the sound channels directly and the Gameboy is armed with:
2 pulse / square wave channels
1 noise channel
1 custom channel, so, you could in theory import wav files somehow but, it’s not recommended, we have minimal RAM and ROM to play with here!
Coding in plain C isn’t too bad though, as long as you keep everything small in terms of code size and try not to use comparison operators (e.g. less than, greater than, etc) or multiplication, division, sine, etc. (At least not without look-up tables). then you’ll be okay.
No floating point variables either, those would really bog the 4Mhz Z80 down, ideally keep everything to an unsigned 8-bit integer (0-255) which again, is tough initially but a couple of 16-bit integers are allowable.
Having mentioned all of this, the game managed to get to a fairly playable state within the first day, although at this point there were a lot of gameplay issues that still needed to be fixed, for example, you could simply hold A and not much would get in your way, sometimes not at all!
Also, there was no horizontal movement, only vertical, which felt a bit boring, so the following day, whilst refining the newly added enemies and trying to generate their placements in more annoying ways I stumbled across an idea.
A FUEL METER!
Of course, why didn’t I think of this before. If the jet pack runs out of fuel, then that’s it, you’re toast. But, it needs balancing out somehow, so in went the flashing fuel cans and gun recoil, allowing for some control over horizontal movement with the B button whilst vertical motion is all handled with the main (A) button.
But how to handle giving the player fuel? It should be based on performing a task and also, as horizontal movement is slow, lava is rising up quickly under you, it could be too tough to reach!
There was only 1 solution in my mind that would bring another layer into the game at this point, shooting enemies could release homing fuel cells which the player could collect with relative ease.
This meant that not only were enemies deadly, but you had a damned good reason to hang around and aim for them, your jetpack quickly runs out of fuel on the hard mode in the game, so enemy destruction is a must!
The game was looking pretty close to it’s final form by around 4-6pm on Day 2 and with around 7 hours left it was mostly debugging, polish and ensuring all the standard trimmings such as endings, title screens, differentiating easy mode from hard mode more and, in general making sure it all run without too many bugs.
Because, there are bugs, just a couple, but I couldn’t find how they were occurring. In the scope of things though, they’re fairly minor and, in some circumstances, give a player an advantage whilst playing, sooo, yeah. I guess I’m okay with that.
All in all, I thoroughly enjoyed Ludum Dare this time around, it wasn’t as stressful as previous ones, how much of that is down to experience and how much of it is down to going for the Gameboy, I don’t know. However, you can play NOVASCAPE for your Handheld Nintendo Gameboy System here and I recommend that you do, it’s fun, you just need to learn the controls 🙂
Well, with Ludum Dare #34 Just around the corner, under 12 hours away as I type this out, I’ve been preparing myself to put together a Gameboy Game in Under 48 Hours, based around a theme. Which I’ll discover at 2am.
So, what am I doing to prepare for this then, huh, huh?
Clear some space around me in my lil home office so I’m not being distracted by clutter.
Made sure I have made a gameboy game recently,in a small amount of time, so I’m not going in to this completely blind. You can play it on your Gameboy here, it’s a tough space invader clone and didn’t take too long to make, just a bit of time to debug. GBDK is funny with variables sometimes!
I Managed to write myself a handy tool to make sprite creation easier, meaning I can now use photoshop, export to PNG, run it through my tool and out pops the relevant data for both GBDK and it’s Tile editor program, I can see that saving me a bunch of time and allowing me to make more complex sprites a bit easier! I’ll pop this online at some point, just not right now though, time is pressing!
Probably grab a bunch of snacks later on tonight for easy eating. Not too junky though!
Most shocking of all, I’ll be getting myself a decent nights rest, so I can make sure I’m not going to burn myself out over the 2 days, I love game jams and everything that goes with them, but yeah, sleep, that’s important!
Why in the hell am I making a Gameboy Game? Why Not Use Unity. Unreal / Something else?
Haha, yeah, I’d normally be a Unity bod for any Gamejam, but, what with my recent endeavours with GBDK and Gameboy Development I wanted to see what I can make, from scratch, in 2 days. I’m not expecting my entry to fare particularly well in comparison to other games out there, but, this is just for the joy of game jams!