Rules of Independent Game Development
There are several commonly cited cardinal rules in indie game development:
- Keep it simple.
- Maintain a schedule.
- Avoid feature creep.
- Don’t make an MMORPG.
- Don’t reinvent the wheel.
- Market your game heavily.
- Take risks that bigger studios can’t.
- Don’t be in it for the money.
There is another rule which I think is cited more often than any of the others: “Don’t make a game engine.” It’s good advice. You don’t want to get caught up in technical details if all you’re trying to do is make a stinking game. It’s also one of the hardest pills to swallow, which is the reason it’s so heavily cited. Most indie game developers are independent precisely because they feel that they want to control their own destiny instead of being reliant on other powers in the industry, and using an existing game engine is, in a sense, voluntarily relinquishing yourself to the chains of another studio’s design. There’s also a factor of ego in this; writing a game “from scratch” is more impressive and yields a greater sense of accomplishment than making a game on top of thousands or millions of lines of existing code you didn’t write, and of course you can write a better game engine than they can, anyway, right?
Another common excuse that indies use for writing their own game engine is that they can better tune the engine for their specific game. This is usually a poor reason; if your independent game is going to unacceptably stress the best commercial game engines available today, your game is probably already doomed. If you just scale your idea down a bit, it’s probably possible with an existing engine, albeit with a little work, and if you’re just trying to avoid that extra work in an existing engine by writing your own engine, you might want to reconsider which choice is actually less work.
Probably the best reason I’ve heard for writing your own engine is because it’s fun. The best counterargument to that I can come up with is that the people that make game engines for the fun of it are not trying to make games any more than compiler writers are trying to make web browsers. That is, making a game engine is a very distinct task from making a game, and those who enjoy making game engines often don’t see them through to final games, preferring instead to make technical demos to show off what they’ve done.
Breaking the Rules
Despite the above excellent advice, I have chosen to write a new game engine from the ground up for Dystortia. I would like to control my own destiny, feel that sense of accomplishment of writing it from scratch, tune the engine for my game, and experience of fun of making a game engine, but while the above excuses all hold some appeal to me the same way they, secretly or not, hold appeal to most game developers, I have a better reason. There is a very particular graphical style I’m going for which, after extensive research, I have decided is not accessible to me with conventional graphics engines, and I want one of the main “hooks” for Dystortia to be its style and mood.
Those following the Dystortia twitter feed have probably noticed that I’ve linked to a few things relating to modernized pixel art. This video of an in-progress XNA RPG 2.5D game engine is probably the most relevant. The idea is that the game is fairly normal 2D, but the sprites and backgrounds also store the depth and normal for each pixel, allowing the engine to post-process everything with real-time lighting and other nice effects. The character sprites in the video are simply flat, but most of the other things in the video store this pseudo-3D information, and the developer behind it has managed to do some fairly impressive things. My plan is to take this rendering technique and apply it to the charm of hand-drawn pixel art. To make the process more bearable, I might take some ideas from the King of Fighters XII workflow: create a 3D model, render each frame of the animations, then create hand-made sprites based on those renderings. By using the depth and normal information directly from the renderer, we can save a lot of the work normally required when creating the final sprites by hand, avoiding anything having to do with shape and shadows which can be deferred to the game engine. We can also include extra channels for diffusion and specularity factors for each pixel of each sprite, giving the engine even more flexibility regarding lighting.
So, the plan is to write a deferred rendering graphics engine for 2D, which would give me tons of freedom with lighting. Is this really something that conventional engines can’t already handle well? If you find one that can do it and supports the platforms I’m targetting (Linux, Mac, Windows), I’m all ears, but my searching so far has been fruitless.
Is a graphical style worth writing the entire engine? Why don’t I just modify an existing 2D game engine to use this technique? This is a question I might have more difficulty answering to a skeptic’s satisfaction, but in short, I don’t think the other parts of the game engine will be very difficult to reinvent relative to the graphics engine, and since I’m already writing a new graphics engine, I might as well just write the rest as well.
Is it that Important?
I want Dystortia to have a certain style and charm. Style is important, arguably as important than the gameplay itself (I don’t think I support this view, but that’s not the point). Plain pixel art can be pretty charming, but it’s at the cost of other things that can be very expressive and mood-setting, such as lighting. 3D engines can pull off the lighting, but 3D game engines are unable to render the raw detail that 2D sprites can have. Conventional graphics engines are apparently a hindrance to my critical artistic decisions, and the only way I know of to be able to make the game I want to make is to write the game engine myself. It may be uncommon to associate high levels of detail with 2D graphics engines, but that is precisely what you get when you remove polygon limits. The main limitation of 2D is movement, but that’s often an intentional design choice for gameplay reasons anyway; the other main perceived limitation is that 2D usually lacks certain graphical freedoms which rely on information about 3D space, but that’s precisely what I’m partially solving by writing this new engine. I not so much interested in pushing boundaries as I am in making this game; I don’t feel like I’m falling for “the game engine trap.”