First off, I'm a bit curious as to how my work was distributed between the game itself ("Downwash") and the engine. If almost all the work was invested in the engine I'd be danged pleased and proud, but I fear that that is not going to be a reality. Although the game only turned out to be 4052 lines of code and 2274 lines of game object configuration (in all fairness, it's a very simple and dumb game, but it's still half the amount of code in my previous game which was equally bad), I'm pretty sure that a lot of the tinkering went into the game itself as the engine evolved. So how did I manage?
Aha. Ok, most of the "other apps" is a big refactoring I started with, before creating the Downwash stub. So in terms of work, I'd say it's an even split between game engine and game. If we lay it out over time and stomp the initial app/engine refactoring we get:
So approximately 2.5 months engine development and 2.5 months game development. This game helped the game engine mature, and it really improved the APIs and definition of what goes into the game and what goes into the engine. 2.5 months isn't very good for a boring game like this with ugly... everything. But I'd say about half of that time was spent tinkering with the interface and other dumb crap like having to port all code to C++11 (apart from some iOS 4.3 support, which still is on C++03 for some inexplicable reason).
The split between application and engine is a fairly good one now, and it works for my various other projects, both released and not-yet-released. The interface is portable and allows a well-defined server/client split, support for building the server into the client as well as creating a dedicated server (intended for Quake/Minecraft style games). It's easy to add split-screen rendering, each using a different network client towards a local or remote server. Each local client has it's own configuration environment, camera and mic, but share a common physics engine (currently ODE) for performance. (When the console makers open up for indie, I'm ready for some split-screen stuff!)
Especially the multi-threaded code for running rendering, scripting and physics in parallel is poorly designed and only yields a small performance gain while at the same time being very unstable. But I think I'll keep it that way. I can always fix most of the stability issues, but re-designing it is too boring and too much work. Also the core of the system is a monolith, but while the main "manager" is a big goo in the middle, it also centralizes data and code in a way that makes most things very straight-forward. I won't be re-writing that either any time soon.
This time I feel very confident that making a simple physics game would be very fast and easy to do. But nah... too easy+boring! Hm... but wait a second... I could create 10 simple games in a year, and at least one or two would be pretty fun. Now I'm thinking that maybe I'll learn more from that than I'll ever do if I just push on to the next big hurdle - adding skinning to the tooling, adding animations to both tooling and engine (gulp), adding landscape/city/dungeon generators, improving rendering...
Ok then. I'll create a few simple 3D physics games. Do they need to be 3D? Do they need to have physics? I can't compete with 2D. At all. 2D is all over App Store, and they do it so well it hurts. So it needs to be in 3D; that's my niche. Regarding physics, I'm pretty sure I could skip that part. But when you've built a nuclear plant, you don't want to power a bedside lamp with it. And apart from physics I don't have much; the rendering is... well... pretty lousy. I'm bad at art, sound, music and game design. That doesn't leave too much, does it? But alas, I'll make one or two tap-and-swipe pointless type of games without physics in them. And surely the mob will think that those games are the best ones. Morons! (Mm-mm, this must be how Allah feels. I just need to learn how to set bushes ablaze. Does he too burn bushes when he wants attention?)
No time for post mortem this time. Next post.
