I'm out of my sling finally and my hand brace came off last week, but my motion is extremely limited in my right arm yet, and it's taken to hurting fairly often. All that said, I am finally able to do a little limited typing, not for long periods, but enough to keep me from going crazy. And I've been putting that ability, however limited, to good use. I've actually gotten some programming done.Of course, there's groundwork to do before I get too far. I'm planning to use a Component-Entity-System paradigm, rather than a traditional inheritance model. Fortunately (I guess), I'm not a great programmer, so I'm not too tied to the usual OO way of doing things. I've read a fair amount about CES engines, so I think I'm more excited about the challenge than I am daunted. Right now, I'm planning to follow Randy Gaul's excellent notes on the topic. His approach appeals to my engineer side, as it considers the way the iron handles the memory accesses.
To that end, I hit a major milestone with TD the other day, checked in at revision 110 (though several of the last revisions were changes to the blog, I'll discuss those in a bit.) I added a third dimension to my StageMaps. It didn't require too much in the way of course changes, but it's at least conceptually significant. I wanted the ability to allow players to move around -- above and below -- obstacles, and have the chance to get high ground advantage over opponents. Plus this starts roughing in the framework for parallax elements. At present, the editor is locked to the bottom Z level, but all I needed was multi-Z support to start building test StageMap files. Now I can finally start working on the actual game!
Before I Get Too Excited About Writing a Game
Essentially, it's a very "pure" CES approach: Entities (or game objects) are little but a handle and a list of handles to Components. They live in a big std::vector (or something similar, but I'm going with a std::vector) inside of some sort of an object factory (all of that's going to be pretty new to me). The Components are pure data, and they live in std::vectors (or whatever) inside of the Systems that actually operate on them. The slightly weird separation and use of vectors are to help with memory locality. When a System wakes up, be it procedurally or in a thread, and it fetches everything it needs from memory, this way it'll get everything it needs to work on (or at least most of it) at one time without needing to search around memory for associated bits and pieces. That's the theory anyway. I've got to figure out how various Systems can easily reference the same Components -- Physics and Rendering both need "position" and Rendering and Animation both need to reference "sprites" and "textures," for instance, but I'll tackle that when I come to it. I'm also going to have to consider how I render "non-object" stuff -- the StageMap being a good example. I don't feel like the physical space the characters occupy really rates as an actual Entity (at least not in the same way as other game elements), but I'm still hashing out how I'm going to deal with it.
At least I can finally do something instead of just sit uselessly around the house; even if I can't do it for very long.