Make Games, Not Engines

16 Oct 2010

It’s true. Anyone who has ever started venturing to make a game has probably come across the classic Make Games, Not Engines article. And what it’s trying to say is that you need to accomplish your task, not create an abstract representation of what you think you’re going to need when you start the task. I’ve already fallen victim to, what at its core, is this same issue - I chose an engine that I wanted to work with without knowing exactly what I was going to need from it. The first problem I had with IceCream is that it wasn’t on the bleeding edge - I am going to be using XNA 4.0, so I need technologies that are compatible with it. I tried to get a newer version of the DLL, but with the issues in its development environment, as well as the fact that I was going to be unable to use certain techniques (this became clear quite quickly after starting) I decided that to use an XNA engine was only going to limit me in the long run.

There are plenty of technologies that I want to use. First off is the Farseer Physics Engine, which yesterday I spent about an hour or so compiling and integrating into a new XNA 4.0 project. I was lucky that the engine’s source control contained XNA 4.0 compatible stuff - I effectively created a “World” object and had a dynamic ball bouncing on a static rectangle, complete with Farseer’s debug view that shows you your objects and what is happening. I haven’t yet figured out how to enable the actual text and number debug output which shows detailed information about what is happening, but hopefully today I’ll be able to figure it out.

The Mercury Particle Engine is a project that I only became aware of yesterday, but already it shows great promise - I’ve got the required DLLs and played with the editor less than a minute after downloading it, and this is the kind of thing that is truly valuable - quick, easy, painless usage of a streamlined, effective product. I don’t blame the Farseer engine for being hard to set up, because I am using an unofficial release of it to work with XNA 4.0. Luckily, the particle engine is also XNA 4.0 compatible, and while I haven’t yet integrated it to start creating effects (which are going to be a large part of Ne+), I don’t foresee any mind-numbing issues.

Today, I hope to get the physics engine doing more of the things I want it to do, and specifically, I would like to have an anti-gravity light set up so that when I activate it, anything the light touches starts moving upwards. I am not sure yet what the best way to handle this is, because with Farseer the first thing you do is pass your world a gravity vector.

I am very happy with the progress I made yesterday - I wiped out my IceCream repository and started fresh with a classic XNA 4.0 project, compiled and integrated a “Hello Farseer” example, and am on my way to having a great physics debugging environment. I think that one of my primary goals for today should be NUnit integration into my project, so that I can start writing some unit tests. I am so new to all of this subject matter that they should be quite helpful.

One of the things that has been on my mind since I started pulling down all these projects is the matter of dependencies. I feel good about it in a way, because I am utilizing open-source software to its fullest, and hopefully my code will be of use to at least someone - I have decided absolutely that I want it to be available, based on how helpful it is for me to see the code of others. For example, when looking for a solution to 2D lighting (it is hard to immediately start thinking about how that would work), I asked a question on the Game Development StackExchange site and received an excellent answer linking me to a fantastic example of dynamic, and highly effective lighting. I downloaded the example and it compiled beautifully, and also provides a fantastic lighting effect. I’m very excited about what this is going to bring to my project, but the goal of my first “Sprint” is not to get lighting going, which is a graphical effect that is not absolutely essential to gameplay, but instead to have my light objects working, which does not require anything other than the simplest graphical presentation for me to confirm the results.

I feel very good about my choice to not use an engine - there is a huge element of freedom, as well as the knowledge that there are a million projects I can plug into my own without limitation, because I am the one creating the limitations. I also am not exactly attached to what the “engine” turns out to look like, because it’s not going to be entirely applicable to other projects, and it would only weigh down my code to strive toward that goal. XNA is not the platform that I want to create the rest of my work in, either, so it’s not that big of a deal.

So, today I will try to integrate more and see if I can get some anti-gravity action going, attempting to test out NUnit and add a project to my solution.