- The greater bulk of this code was written before I was good at using MouseDrag(), call(), reassigning the players between mobs, and verb manipulation. Consequently, the control scheme features a number of cumbersome code workarounds that makes it a whole lot more difficult to work with than it needs to be.
- The greater bulk of this code was written before I was as good at modularizing my code as I am now. Consequently, I find the need to shift it around to greatly simplify it and make it easier to work with.
- I didn't like how I did the GUI. I had this really obfuscated mecha customization mechanism that really wasn't necessary.
In what time I could get away from visiting familial obligations over the weekend, I spent the greater majority of my time so far doing exactly that: pondering and turning over exactly what my goal was here, what I really wanted to make, to at least visualize the end result and see if it's satisfactory to me.
My GSDC2010 challenge was originally conceived in mind of being Lode Wars except with 4.0x skin controls and the players piloting vehicles. In fact, I already have the necessary code in place to generate a symmetrical map of dirt to dig with minerals, to do the actual diging and recovery, even the scoring.
The only thing that was really lacking from my GSDC'10 was conflict and resolution. If I had called it something other than "Mech Game Framework" and told Iain Peregrine that it was a game all about digging, I probably could have got away with it with a little balance work: there's a game there in simply moving the ore back to your base better than the other teams.
However, something always bothered me about it, causing me to lose motivation. I think I figured out what that was: it didn't meet my second goal of having "vehicular combat" in it. For reference, take a look at footage from a 2D vehicular combat game that did it right, Autoduel:
The biggest thing I see missing from my project to bring about a "vehicular combat" exception is having acceleration and velocity. My current game just doesn't have it, instead having a space-by-space queued step mechanism I originally designed for a game that involved walking around on a personal-level.
So, if I plan to keep the vehicular angle, I think a redesign of the control system is necessary. Forum_Account's rather impressive pixel movement library would be an excellent choice for a vehicular combat game. The only potential issue there is that I'm not sure how many players can be handled at once with BYOND running that fast. However, at the very least it would make for an outstanding single player experience.
At this point, it should be clear that, if the goal is just to "Get It Done," I'm doing the exact wrong thing. Getting it done would entail taking my existing code and GUI, no matter how much I hate it, and simply filling in the missing pieces that would make for a complete game. Because, even though the code would be a lot easier to work with when revised, that can technically wait until after I've got something playable. Whether I choose to make these radical revisions or not has a great deal to do with whether or not I feel I could get them done within a two and a half weeks.