An alpha version of the game. Quite a few bugs, but it's playable! THIS IS MAC ONLY! I'm going to make a windows version as soon as I can, but because...
A small game pong-like game with a few twists to shake things up a bit! These twists include Arkanoid-style bricks that the player can destroy, powerups and spawnable minons that patrol at your side of the field. Add the grafical limitations of a Gameboy, with music and soundeffects produced by it's soundchip, and you've got yourself... Well.... This game.
Before starting to read this post, I recommend that you go to the bottom of the page and play the song from the soundtrack that's down there. Just so you have something to listen while plowing through this wall of text.
Hello! My name is Pontus Lundén, and I have for the past one and a half week been working this game. At this stage, I am just a few steps short before I release a beta of this game here on IndieDB. So, I've been thinking that I should make at least one post here before publishing the beta. However, as I'm very inexperienced with creating games by myself (I have worked on other games before, but only as a composer or a designer), I realized that writing about what I've done will most probably be kind of boring, as it will all be pretty basic stuff. So instead, I chose to make a post about how I as a single person have been working, and how I've been managing to make up for my shortcomings in the different disciplines. So, without further ado, let's get this going:
If you've developed games before, this part might seem a bit odd for a one-man developer to go through. The pre-production usually exists for the purpose of every discipline getting their stuff together, and for the group to decide how they are going to work. It could be argued that the pre-production stage starts as soon as the game idea is created, but I usually see it as the time when you start organize everything surrounding the development. When you're one person, you can pretty much do as you wish, as you're not bound by schedules or meetings or having to worry about different disciplines working in sync with each other or stuff like that. For me, however, as I lack in many disciplines, I still had to think of way that allowed me to walk around my weaknesses and bring out my strengths before starting to develop the game. This meant that the pre-production phase was used for me to decide what engine to use, what sort of game I could actually make and what I should focus on in the graphics department.
So what did I end up with? Well, after playing through Thomas was Alone and trying out Unity a bit because of it, I realized that I wouldn't really be able to create that good 3D models, witch made me think of going 2D. However, even though you can use Unity for 2D games (Thomas was Alone is an example there), after looking through a few things I came to the conclusion that for the kind of game I was developing, I could do it way easier in other engines. Instead, I decided to use the dreaded, hated and laughed at program called Game Maker. DON'T LEAVE YET! Just because it's a Game Maker game doesn't mean it HAS to be bad! Just pretty darn simplistic. And for this game, simplicity isn't that big of a problem. I also chose to limit the graphical fidelity to that of a Game Boy, because I thought it could bring pretty interesting limitations that I had to abide to. Because of this, as you can't really do super detailed sprites on a 160X144 screen, I decided to give a lot of focus on the animation.
As I wrote in the introduction, I have actually done some design work before. Not much, though. For this game, I knew there was two limitations that I had to work around: 1. My own lack in programming skills, and 2. The low resolution of the Game Boy screen (can't have detailed stats or stuff like that - Won't fit the screen). Therefor I though, as this is my first one-man game, why not start by making the most basic of games: Pong. See, pong really only needs four things; Players, a ball, a bounce-system, and a score-system. When using Game maker, even the most inexperienced person can throw together a pong game in less that half an hour. Off corse, I didn't want to leave it as a simple pong game, partly because it's not very innovative, but mostly because pong is kind of boring.
Because of this, I started with adding Arkanoid-like blocks in the game, in order to change up the levels from being just a plain playing fields. After thinking a while though, I realized that just adding blocks wouldn't do much. See, the reason why you care about the blocks in Arkanoid-like games is because you need to destroy them in order to advance. However, in a pong game, they'd only serve as obstacles, which is fine if you want to change things up for a level-design perspective, but the reason why I added blocks into the game was to give the gameplay more depth. So firstly, I thought of adding powerups. Powerups are fine, and they can add a bit of depth, but I felt that the random element of hoping that a powerup would fall out of the block wasn't enough to make people interested in destroying the them, and their main purpose would still be obstacles.
The solution became an entirely new system for me to add to the game: Minions. For each block the player would break, he/she would gain 1 coin. These coins could be used to purchase minions during the match that patrolled on the players side of the screen, protecting and buffing the player who purchased them. These minions would have to work on their own, as the player wouldn't really have time to control them when focusing on the ball. This meant that I would have to make the minions pretty simplistic in order to not steal the attention of the players. Off course, this was a good thing for me, as the simplicity of these minions worked well with my terrible programming skills.
In the end, I ended up with three different minions:
The "Small Bot": A cheap but fast robot that dies if the ball bounces off of it. However, if the player who last touched the ball was the owner of the Small Bot, the Small Bot will duck from the ball and let it fly over.
The "Mid Bot": A robot that charges the ball and makes it go faster for 5 seconds. If the ball is coming from the enemies side, it will send the ball back the way it came.
The "Big Bot": Cannot be killed by the ball (only by bullets). If the ball hits the Big Bot it simply bounces off of it. The big bot will fire bullets over to the enemies side during regular intervals.
I also made six different powerups:
Faster/Slower ball: Makes the ball go faster/slower for five seconds.
Bigger/Smaller brick: Makes the players brick grow bigger/smaller for five seconds.
Shot: Gives the player a dual-gun with ten ammo.
Defensive wall: Creates all wall behind the player that can fend off one hit by the ball. Can also be destroyed by getting shot at.
Oh wow, this is gonna be a short one. Well, seeing how Game Maker doesn't require much programming, I've only written parts of the game in code. This isn't the first time I'm coded, though. I have taken a (very) basic course in C++, and I've done quite a bit of HTML/CSS coding in the past (though my programmer friends insist that HTML is borderline proper programming). However, even though I'm not very experienced with game programming, because of the simplicity of the game, I managed to get by. There are though a few things that I've avoided due to my lack in programming skills that I'd like to fix sometime in the future. One of those things is Game Makers collision system. From what I've heard, if you program your own collision, you can get a much better system than the standard collision system that exists in game maker. I'll have to learn a bit more about how game maker ticks before I do that, though.
In all honesty, I don't know what more to say on programming, as what I've done is at most very basic (and uninteresting) stuff.
This one is a bit interesting. As I wrote earlier, I wanted to focus more on animation than detailed sprites. This was for two reasons, really: The limitations of the Game Boy screen (Both resolution and color palette) and because I generally find making good animations, albeit being a way slower process, is easier than making detailed and good looking sprites. I also think that fluid animations are more important for a game to look good than detailed sprites. Still, just because I focused on animations didn't mean I didn't hit a few bumps in the road.
The thing about working with graphical limitations like color palettes and resolution is that it's actually a bit of a double edged sword: Because you have less space and fewer colors to work with, the sprite will look pretty good even if you don't add tons of details on it. At the same time, when you for some reason need to add details in order to illustrate what's going on, it can actually become really hard. For me, that happend when I was going to do the graphics for the games powerups. Making something that's suppose to illustrate an effect such as faster ball-speed or smaller brick on a 4x4 pixel space can be really troublesome. Another hard thing was the death animations of the minions. Pretty much all of the bots' death animations are illustrated by them falling over. To make something so small look like it's properly falling over, and not just mushing together in a pile, actually takes a bit of time and effort.
The same thing goes for the color pallet. The gameboy really only has 4 colors to work with, where the shades of the two brightest are actually really close to each other. This mean that I had to use one color for the background (I chose the brightest to make it easier on the eyes) leaving only three for the objects on top. As I said though, the two brightest colors are very close to each other in shades, so in order for the player to properly spot the object, I could really only use two out of four colors for the object. Also, because of the low resolution, I couldn't really just put a darker outline on everything, simply because there was no space for it.
At the same time though, just as it was with the limitation of the resolution, because there was only these few colors to work with, you don't really have to worry about things being unclear or messy, because there simply isn't enough colors for that. It's also easier to chose what colors to use on a sprite, simply because there aren't that many to chose from.
This was actually the easiest part for me, seeing how I'm originally a composer. Just like with the graphics, I decided to go with the limitations of the Gameboy, using a software synth that recreates the sounds of various gaming systems (such as the GameBoy) called Plouge Chipsounds for the sound effects and music. However, I did not bother with the X-many-channels-playing-at-the-same-time-restriction, simply because in order to make such a system I would have to do a lot of additional programming only to limit the game, which seemed a tad silly to me.
Also, just like the graphics, using the GB chip for sound and music has both its ups and downs. The good part is that as long as you have a good plugin, you don't really have to worry that much about your how each synth should sound, as the plugin will directly give you just how they are supposed to sound. Another good thing is that the simple square-waves of chiptunes actually sound pretty good in a very wide register, so there's not the same worry about how to work the instrumentation in different frequencies as there is in for an example orchestral music. The downside to all this is that many of the synths sound very similar, so if you don't give the different voices proper space in the frequency spectrum, it'll be a bit muddy and the music will sound a bit unclear.
Off course, this also applies to sound effects. Most sound effects are simple noise or square waves, which makes them easy to make. It does however also mean that you can't use very detailed sound effects. In this game I actually have an announcer voice, but in order for it to work with the limitations of the GB I had to lower it's bit depth, meaning that it can be a bit unclear what the speaker says. For an announcer voice, this still works out pretty fine, as he only says shorter frases, such as "Player one wins" or "Round 1". It becomes quite troublesome for longer recordings though, so I wouldn't really recommend doing an entire voice over with these limitations.
Interessted in how it sounds? Well, here's the main theme!
It's been very fun and educational to work on this game. Not only because I've learned how to make games on my own, but also very much because I now have a much greater insight in the other disciplines of game making than just design and music. In all honesty, if you as a developer has the chance to try and make an entire game on your own, I recommend that you try it. I'm confident that it'll make you a better developer over all.
Well then, until next time!
//Pontus, aka SpellingPhailer