Couple things I want to cover here, first up is how my recent 48 hour project, a Gameboy style Chess Game went, then I’m gonna ramble for a bit about my next project and the horrors of creating bespoke content.
Mini Post-Mortem – 48 Hour Chess
What went well:
- Singular focus
- Artwork complete from the start kept motivation up
- Defined ruleset cut down on design time
- Pixel-perfect virtual camera
The entire game is based around one set of sprites I found on opengameart (credit to Clint Bellanger!) that I was so enamored with I felt they had to be put to use. This helped my motivation tremendously.
The advantage this gave me was that I had a complete set of sprites for the game, no finding out halfway through that I needed to quickly fudge together some corner sprites or doorways or whatever else was missing. I just needed a title screen and a cursor, and could then focus on making the game.
Also, importantly, I had a pre-defined ruleset going in (it’s just Chess after-all), so any design work I had to do was minimized. I only had to worry about how the player would interact with the board. Which meant I could start implementing the game immediately.
While it took more time to figure out than perhaps it was worth in the space of a 48 hour project, I’m really happy with how the virtual camera setup turned out. It renders the game view at actual Gameboy resolution (160×144 pixels) and then scales it by either 1, 2 or 4 based on the viewport size and fills the rest of the space with a ‘Super Gameboy’ style border. Not only that, but it’s nicely packaged up allowing me to use it in future projects with very little hassle.
What didn’t go well:
- The rules of Chess… I didn’t actually know them.
- Oblique Projection
I discovered halfway through the project that my knowledge of Chess was actually lacking a few key rules. I didn’t know how Check/Mate worked, and I didn’t know about en-passant or pawn promotion. This meant that the way I’d decided to implement potential moves (your list of legal moves is populated when you select a piece, for just that piece) made it a bit trickier to test for check/mate, and additional time spent researching how these rules even worked meant time not spent programming them into the game.
As a direct result, check/mate is not in the game (you have to take the king to win), and the first version had a bug with en-passant taking, and ‘castling’ wasn’t in the game either, it had to be sacrificed in the last-minute dash to get a title screen in and actually build the application. Pawn promotion however did make the game, and I’m pretty happy with how it works.
Oblique projection is only mentioned here because while it works perfectly fine in the game, I wouldn’t want to tackle a more feature-rich product with it. While math isn’t my strongest skill, working out the math for the perspective would have been a bit of a nightmare, and thinking about how I’d implement it took a sizable chunk of the first day. Thankfully, this game is only concerned about that 8×8 chess board, so I could just hardcode the math for moving up/down/left/right and not worry about things like converting a mouse-pointer or character position into/out of the oblique projection and how it interacts with screen space. Because I kept a separate model of the board, and the cursor is restrained to just that 8×8 grid, I didn’t need to work any of that stuff out.
What to take forward:
- It’s ok to cut features to complete a project
- Don’t assume you know everything, even if it seems really obvious!
This really go without saying, because no project ever finishes with 100% of the intended features. But I think it’s a lesson worth learning over and *over again* because it’s easy to beat yourself up and focus on the things you wanted that didn’t make it into the game, or the bugs you didn’t have time to fix.
But this distracts you from your actual accomplishment. You have a completed project! And in that regard, even though I had to cut castling, check/mate and en-passant didn’t really work properly, I still had a playable Chess game after just 48 hours. Considering I’d never implemented Chess before, I’m actually really proud of that.
Secondly, if I’d brushed up on my knowledge of the chess rules beforehand, I may have had enough time to squeeze in the rules that didn’t make the cut, however. I jumped straight into coding the game without stopping to ask myself, wait, do you actually know the rules for Chess? Rookie mistake!
Onwards and Upwards
I had initially planned to start researching HTML5 games next, using ImpactJS, but my motivation for that has waned significantly even though I’ve done a significant amount of work writing some code for resolution independency. I will return to that once I’ve gotten past the itch to make more Gameboy style stuff.
There’s been a couple of concepts sitting on my google docs for ages now that would be perfect for this style, so I found myself looking back to one of them now that I had a good setup for retro pixel games in Unity2D (I’ll probably make a tutorial on that relatively soon, too!)
So I spent the weekend implementing very basic movement, and a workflow for maps using Tiled (I had planned to use my own map editor, but it’s very limited compared to what Tiled can do out of the box) and bringing them into Unity, and had some fun designing a couple of dungeons and a small overworld for a Zelda-clone. I tried to keep the scope as small as possible while still being able to tell the story I had in mind.
4-5 dungeons and a small overworld can’t be that much work can it? Oh boy I think I was wrong about that one. The concept of producing 4-5 dungeons and a small overworld to connect them didn’t sound like much, but when I started actually laying stuff out it dawned on me just how much content that actually is.
Each screen is going to be represented by a 15 high and 20 wide grid of 8×8 tiles. Knowing that it was going to be a good amount of work, I decided to restrict map sizes to just large enough to be able to provide some interesting puzzles. Dungeons are a maximum size of 6×6 screens, and the overworld is 12×10 screens.
That’s, potentially, 180 dungeon screens, and 120 overworld screens, plus a handful for the insides of buildings. Holy crap that got big fast… Even planning that the dungeons will only use around half of their available screens that’s still around 210 total screens. Which equates to about 63,000 individual tiles. Each one of which, because of how small that actually seemed once I started laying out the basic route through the game, will have to be carefully and purposefully placed.
I mean ok, that’s exaggerating slightly, even though the tiles are 8×8, I can paste a lot of structures and each game world tile represents a 16×16 space, the smaller tiles just give me more flexibility visually. But still, even at 16×16 and removing a few screens that aren’t going to be used, that’s still about 27,000 tiles! Spread across 5 environments, which means 5 different tilesets need to be produced in addition to the dungeon tileset for six total plus any unique tiles I need for things like decoration or dungeon entrances.
It’s no wonder so many devs choose to generate content procedurally rather than making bespoke worlds for small games like this. But I’ve always felt a nice hand-crafted world has a bit more soul than most procedural games. That and it’s nicer to speedrunners!
And that’s before I’ve even thought about the sprites I’ll need for actual game objects and all the triggers and events I’ll need…
But I’ve started now, so I guess there’s no looking back! Here’s a sneak-peek at the overworld!
I’ve been wanting to channel my love for games like Link’s Awakening and Alundra into something tangible for years now. Hopefully this project can re-ignite my soul!