I feel it is necessary to take a step back and define what it is I am doing, and what my development process has been so far.

Objective

Mystic Dave is a game project designed primarily as a means of bettering my understanding of C++ and overall programming prowess. This project will be both an entertaining game and a reasonable personal challenge.

I intend to release Mystic Dave within a year of my beginning the project, which sets the deadline at August 2014. Hopefully I get it done well before then!

Technology / Dev Tools / Dev Team

This project will be entirely written in C++ on Microsoft Visual Studio 2010. I will run on Windows / Windows emulators from an executable for Win32.

I am using Allegro 5 to act as my framework and prevent having me roll out a ton of stuff on my own. No need to re-invent the wheel. I actually just upgraded from version 5.0.8 to 5.0.10. The fact that I am using Allegro shouldn’t affect the end-user, as the libraries will be bundled with the executable.

All graphics will be created by myself in Gimp or taken from the internet. I will primarily use a png format, because it supports z-buffer and loss-less compression. I tried gif for a while but don’t like having to deal with the limited color pallet in Gimp. Posts on graphics will come later once I make more of my own.

All audio will most likely come from the Internet and be heavily Zelda-themed. There are plenty of good sound editors out there. I’ll let you know once I get to implementing audio into my game.

The data format of choice is JSON, mainly because I need a human-readable way of getting data into and out of the game. This lets me, again, get things done without having to roll my own code. I am using jsoncons.

My text editor of choice is Sublime Text 3. Check it out if you haven’t already. (Code happens in MSVC, JSON editing happens in Sublime)

This is a solo project, so no dev team besides myself to speak of.

Development Outline

I have become very interested in game development in the last one or two years. Sites like gamedevtuts+ and shows like Extra Credits are excellent resources. Most of these resources recommend approaching game development in a somewhat more thoughtful process than just sitting down and pushing out a bunch of code. Unfortunately, this is how I approached Pong and Asteroids (for the most part), and that has to change. So, here is my game development process for Mystic Dave:

1. Reflect on Asteroids and see what I need to improve on
2. Create a Design Document for Mystic Dave
3. Code up the game, implementing one feature at a time & saving / backing it up after every feature implementation

Pretty simple.

Thankfully, I am already on step 3.

Reflection On Asteroids

So the first step is to look back and see what needs improving.

I was fortunate enough to have a good friend of mine (who works at MS) to look over my code base for Asteroids and critique it. Boy, was he thorough! I have a huge document full of things I need to change for the next time around. I’ll list a few of the most important / non-obvious:

• Make a design document
• Get rid of the “tw” prefix. A reader should be able to know that you wrote it by seeing your name in the source code
• Stick to strictly spaces instead of tabs & spaces
• Use namespaces
• Instance variables should almost always be private
• Try not to duplicate code

Obviously I have some work to do!

So, with these goals in mind I set towards creating my design document.

Design Document

The design document is a document which thoroughly describes the game, including the mechanics, the look & feel, the class structure, and how things interact. It is vital to understand where you want to go before you just start mindlessly coding. Making changes early on, before code happens, is much easier and far more effective than trying to hack in changes later on.

The biggest thing I noticed with Asteroids is that I was not following a design document and that 50% of the code happened in the last two days before release, making things more messy than they should have been. I had started by writing the singleton “manager” classes. From there I had implemented one thing at a time as I thought them up. That was not as efficient as it could have been, and having a good idea of where the game was going would have helped.

It took me a good while to come up with everything in my design document, most of that time spent not actively working on it but more letting things mull around in my head. So far having said document has been extremely helpful, and even though things inevitably change during development, I still have a really good idea of how everything fits together, what features I will restrict myself to in the final game, and how I want it to behave.

Progress

Here is what I got done in the last week:

• Upgraded from Allegro 5.0.8 to 5.0.10
• Implemented entity triggers, so events can be triggered when an entity enters or exits a block
• Created a transition entity that allows for chamber transitions
• Fixed misc errors and rearranged some stuff in the background