Let The Programming Begin

I love this part. It does not matter whether I'm building a game or some dull office software, I always really love to start a new project! Off course I have fear of missing the motivation to finish what I started and I always think about this quote when starting something new:

"A man's worth is measured not by the projects he starts, but by the way he finishes them." - Unknown

A big downer. More so because most of the programming projects I started never have seen the light of day. I want to finish my projects (most of the time), I really do, I just don't ... Gone... My happiness of starting a new project vaporized, vanished even before starting to program my first line of code. It is not really gone off course, it just transformed into a gas. After I cool down I'm sure that water droplets of love will condensate on my face.

I should probably tone down my imagination a little bit, this is getting weird. There is nothing wrong with a vivid imagination but not to the point where we lose all coherency. Focus. Focus. Just rotate the shield frequencies and let your thoughts stabilize.

Versioning

As any software developer will tell you, we need to think about version numbering. It would be lame to start with v1.0 and the next v2.0 just to decide it is that it is better to use versions like v3.0.2.1.20120818 from here on out. Software engineers are totally obsessed with versions. It must be done right, or it isn't worth doing at all. Somehow deviating from our initial system for version numbers is almost as bad as dividing 0 by 0 (which should be 1, right?). To us, software engineers, it is utterly unacceptable that the marketing department changes AwesomeProduct v0.3.12 to AwesomeProduct 2012. We are not stupid, we know that something like "v0.3.12" doesn't sell as good, but how dare they touch or precious version numbers! They probably don't even know what each number stands for! True software engineers talk about MS Word v12.0.6607.1000 or Java v1.5.0. That being said, there is some truth in what those silly little marketeers are saying. Any version starting with a zero is thought of as an unfinished product full with bugs and unimplemented features. So I will just start with v2.7.1.8.2818 (If you want to know why: I think π is overrated, but am too afraid to use τ as substitute). The next important question is whether we allow numbers to overflow to use more decimals, it must be done right! For example, do we allow to go from v1.9 to v1.10? This is arguably the most difficult problem we need to solve. This system will break a lot of sorting algorithms. If we sort these versions by name it will look like v.1.9 is the most recent version!

Grmbl .. stupid ... sorting .. .grmbl. If we do not allow overflow of than we are limited to only 10 different versions. What if I want to have 12 omega-versions before I release the next alpha? I think I'll just allow versions numbers to use more digits if the need arises. Screw those sorting algorithms. Oh oow, I'm getting that urge to optimize sorting algorithms all over again. This is not one of those problems quicksort can solve... FOCUS!

So what do these numbers in the version stand for? This calls for numbered bullet points! Let break up v2.7.1.8.2818

2.The major version. This will be increased when hell freezes over.
7.The minor version. This will be increased on the day I collected over 1 million unique unicorn drawings.
1.The alpha version. This will be increased at the 'end' of a development iteration, when I finished all short-term goals I intended to do.
8.The omega version. This will be increased each time I've written a page on what I've been up to and released a new demo.
2818.The build number. This will be increased just when I feel like it or when I need to quick-fix some bug and don't intend to write about it.

Okay this sounds all nice and dandy, lets move on. I don't have to mention that all inferior numbers will be set to 0 when one of the superior numbers is increased, right?

Creating a project, adding an installer

Most games that try to go for quick-prototyping and release their projects it in the wild simply create a zip file of the executable and resources. Sometimes you may find other executables to play with and sometimes you'll find a readme text file that you are actually expected to read. The author knows that you have read at least 50% of the blog-posts so you should know exactly what the (partial) game is all about. There is simply no other reason you would have downloaded the zip-file, so the logic is sound. If the project gets successful it is always possible to add some installer to it. I though about this for a while and wanted to try something a little different. I'm not sure if I'm right, but I suspect there may exist a couple of people that are 'only' interested in the binary releases, even when it's in omega-stage. I must admit that I sometimes do the same thing. The first thing I do is download the zip-file, looks if it is interesting and only then read the blog. If other people are doing this too, than we might need to change our tactics. If it's the program that attracts people to the blog instead of the other way around than we need to make the demo releases look more representative. My intuition has a hard time believing me and nags me with question such as "Do we really need to put effort into 'nice' installers for omega releases? Doesn't that go against you quick-prototyping ideas?". The only way to prevent this is to put your fingers in your ear and scream 'LALALALA...'. It's not a black-and-white world after all, we are looking for a nice middle ground on the niche called indie. We need to make compromises that's what indie is all about. Some people say that array-indices should start with 0, others say it should start with 1 so why not compromise and start at 0.5? Then everybody is happy! My intuition calls me hypocritical and ignorant, but I'm just going to release zipped installers. Making an installer isn't really that difficult. We don't even need third-party tools because Visual Studio can do all that stuff for us (the payed version that is).

Directory Structure

If a new version is installed the DRM should be kept intact, but if I use the registry it will make it more difficult to make a port to another operating system. Using the registry also hurts our chances at making a portable version. If the directory is copy-pasted to another computer I think the application should not crash, but the DRM should detect that another unicorn-drawing is needed. I also like the idea that it is possible to have two versions of the game on your computer at one time. For these features we need to come up with a decent directory structure.

[InstalDir]

  • [v2.7.1.8.2818]
  • [v2.7.1.9.12]
  • [v2.7.1.10.3]
  • [v2.7.2.0.9]
  • [v2.7.2.1.4]
  • [DRM]
  • Launcher.exe

Launcher.exe is the application that looks at all directories starting with "v2.", picks the most recent one and runs the game stored in that specific directory. A "v2." directory will have a directory structure like:

[v2.7.2.1.4]

  • [Content]
  • [Savegames]
  • Game.exe

Unlike DRM, save games need to be stored per version. It is likely that save games will not be backwards-compatible with older version, so they need to be converted if a new version is installed. When Game.exe is executed, it will check the DRM directory of its parent directory to check if nagging is required.

Code Signing

Codes signing is not a fool-proof system that prevents tampering with your binaries, but it helps a little bit. If I sign the executables with a private key, its possible to make a distinction between a binaries released by Slapware and binaries from people that have build the source for themselves. I'm not sure if I ever need this, but it is nice to have when I do want to make that distinction. This will also help me to see if some virus has added a couple of bytes. It may be too late the moment I detect it, but at least it gives me the possibility to warn the user.

Plans For The First Omega

The first omega will probably contain the Launcher and the Game (an empty XNA project). The first steps of the DRM will be done and everything will be nicely packaged in an installer. I'm still not sure if I should make the DRM opensource, I'm leaning towards 'yes', but don't be angry if it isn't.

DRMMy First Omega

line