February 1GAM – Color Cube

Here is my second One Game a Month game. It’s called Color Cube which is profoundly unimaginative of me. And also inaccurate as it’s 2d so it should really be Color Square. Anyhow…

It’s a very basic vector based platform game. I had some difficulty due to the combination of it’s vector based nature and floating point numbers as I previously discussed in the dangers of floating point numbers.

The mechanics are simple enough. You’re a bouncing cube that can absorb other cubes, causing you to take on their color. Being the correct color allows you to move through barriers of the same color.

Color Cube is not a super long game. Frankly, it’s dangerously close to being in playable demo territory. I suspect most people could play it through in five minutes or so.

Making it more challenging would require some significant additions. Larger more complex puzzles. A larger more varied set of levels. A range of enemies with differrent behaviours. All things that I’m wary of taking on at this stage. I will attack more of that over time. Right now I’m focussed on shipping lots of different and varied games to accumulate a range of experience even if, individually, they are rather small and lacking polish.

You may notice the total lack of artwork in Color Cube. Everything in the game consists of rectangles of various dimensions. I am a programmer with no experience in producing artwork for games. I am thus unable to produce the art assets typically required by a game. While there are repositories of free-to-use art assets available I chose to embrace this limitation by making a game that is completely art free. I don’t think it’s something I’ll do again but it was an interesting experiment.

The game is available from a github repository at https://github.com/andyjdavis/color-cube

Alternatively, I have now figured out how to create a Color Cube Windows executable.

If you happen to look at the code you’ll possibly notice one fairly large quirk. The levels are in the code. I haven’t yet made the jump to storing the levels somewhere other than in the code itself. Creating levels in Color Cube is done by writing Python code which lives in the same file as the game logic. Yes, it is as painful as it sounds.

Creating a nicer level creation experience is something I’m looking forward to figuring out in the future. I suspect my games will get much larger once creating levels isn’t so agonizingly slow.

Another smaller quirk is code to do with a ball. This was meant to be a bouncy enemy who would pursue you around the level. I didn’t quite get it to a point where I was happy with it. The instantiation of the Ball instance is thus commented out for now. I may come back to. Alternatively, I may not.

Now that I’ve constructed a very basic vector based platform game I’m moving on to something else. For my March game I’ll be building a tile based platform game which I have tentatively named Space Cadet. From the player’s perspective the difference between vector based and tile based is more or less invisible. Internally however, a vector based game and a tile based game are completely different beasts.

I’ve already begun work on Space Cadet and it is far more ambitious than Color Cube.

My list of things to figure out for March:

1) The details of implementing a tile based platform game. This is the big one obviously.

2) Have the screen scroll to keep the player onscreen allowing the level to be bigger than a single screen. Both of my games so far have been limited to a single screen.

3) Create a way to create levels that doesn’t involve writing code by hand for each level.

After March I’m not sure what I’m doing. I recently came across this excellent article about getting into making games. It seems like a pretty reasonable progression so I’ll be drawing on it for ideas if I get stuck.

Leave a Reply