I think it might be time to aim for an actual game. I think it's far more sensible to make any improvements to the engine based on what a real game actually needs. That way I've got a clear target I'm aiming for, as well as a proper test case to trial the new features out. The only question is - what type of game should I be making?
To answer this question, I need to briefly review exactly where I want to go. Ideally, I'd like to eventually make something along the same scope as a 2D Zelda, a Metroidvania type game, a quality 2D platformer, an X-COM like strategy game or a 2D RPG; a real solid 2D title. However, I recognise that in order to make a game of that scope without it quickly turning into a total quagmire I'll need to work my way up through a series of games, each of which will either add a small amount of complexity, or at the least refine part of the process as extra practice.
This is (partly) why I'm creating my own code base (I'm also partly doing it for the coding practice, and partly because I love dreaming up algorithms and data structures to solve problems). I've got a particular set of features that I'm aiming for in my final system:
- It needs to be easy and fast for me to code up the sort of games I'd like to make
- It has to be a solid system with decent enough performance and with as few bugs as possible
- It has to be capable of stuffing my games full to the brim with "personality"
The "personality" element is one that I particular would like to work on, as I feel it is key. Ease of creation and solidity of the system are important too, but I feel they'll naturally arise from continued refinement and further learning. The personality element however is something that I can't fudge my way past; it's not something I can learn from an on-line article or textbook. I really need to experiment and practice to get the personality part just right.
The other factor is that, as someone aiming for the "jack of all trades" moniker, I really need to start experimenting with cross-applying those skills. I need to work on animation that involves a fair amount of programming and algorithmic techniques as well as art, as well as dynamically interactive music.
So after some thought, I think I need to work on one of the five target areas that I know I need to add to my repertoire: art practice, animation, scripting, in-game editing and dynamic interactive music.
- Art Practice: Pretty simply, I feel I need a lot more practice in game art. However I also feel this should come naturally as I make more games. Every one of them will need art work done. I'll just have to ensure that I stick to game types that need only a little art for now, and gradually ramp it up as time goes on.
- Animation: More urgent than mere art practice is that of animation. Frankly I haven't done much animation of any type before, and I'm pretty clueless on how it should be done. It's not a topic I see frequently bandied about in the forums here; there's plenty of aspiring beginner programmers, but very few 2D animators asking questions like "how do I start a walk cycle?". I expect my first few attempts will really stink, so I need to get cracking on bad animation so I can refine that up to something tolerable. I also want to experiment with combining programming and animation techniques, such as using multiple sprites to define a game character rather than sticking to traditional animated single sprites.
- Scripting: I know everyone and their pet hamster is integrating a scripting language into their games these days, and I'd like to see what they can do myself. I'd really like to try integrating Lua into system and playing around with what extra functionality and development speed improvements it can give me. With the modular event driven system I've currently got my intuition is that it could work quite well; I might be able to do the bulk of the game specific code in script. But given my lack of experience I really need to give it a go and see.
- In-game editing: If I want to make anything of a magnitude larger than Brixtar, I'm going to need to be able to easily add content to the game. This will require some tool development work, something I haven't done much of myself. I know there are plenty of third-party tools out there that I can use and I'll look into them when I need them. However, eventually I'm going to need something project specific. If possible, ideally I'd like to use the game engine itself as my primary development tool; making the game within the game itself.
- Dynamic Interactive Music: I love this feature in games, and I wish more had it. Music that changes to match the gameplay adds so much to the experience of the game, as well as vice versa (gameplay that matches the music). I'd really love to give this a go myself and see how far I can take it; given I'm using tracker based music I think it's very apt to be used in this way.
So much to be done. Which elements to work on first? Ideally I need something that's not a lot more complex than Brixtar but touches on at least one of those points.
I'm thinking the scripting and in-game editing can wait a while; they'll become much more important in larger games. Dynamic interactive music is something I'll have to work on in stages; that can probably wait a game or two. Art practice is something that applies to every project and something art heavy would imply something too large for project #2. That leaves animation, which is something I feel I really need to work on. However, I'll need to take baby steps with this next project, so it can't be something too animated. Ideally I'd want to work on a very simple game with a handful of simply animated characters as my first step into the complex world of animation.
Thinking it through, I think probably the best project for game number #2 would be a new attempt at Ice Slider. I've already got a fair idea of what the game should be, it's simple enough to be considered the "next step" from Brixtar, it involves a first attempt at a tileset for a puzzle game, and it contains a single character with very simple animation (sliding). It also means my GDNet avatar will once again become relevant.
Seems pretty good to me; Ice Slider it is. Now I can refactor with a target application in mind.
Perhaps a nice alternative would be to build up a small collection of sub-editors. Each one is good at modifying one function for your games. For example, you could have a generic "game objects" database editor which will define various in-game objects and give them attributes that can be used by your games. A "level layout" tool would take the output file from the previous and allow you to place various objects in order to create your levels (define instances of the objects). You could have other small tools that build off the input of each-other to add things like scripting/etc. The challenge is to keep each tool generic enough that the output from it can be reused in a wide variety of game styles.
Of course, all this flexibility would come at a cost.