GSDC 2011 Progress Log 1: How Not To Get It Done

ID:113322
 
May 15 2011, 2:47 pm (Edited on May 15 2011, 6:01 pm)
Keywords: gsdc2011
Four days in now, I've had a good look at my old GSDC 2010 code and immediately set about doing the exact opposite of getting something done by deciding to make a number of radical revisions.
  • 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.
I was about halfway through doing all this when I realized that I would be changing so much code that I could be served well by taking this thing completely back to the drawing board and reconsidering if this is really what I want to make. Otherwise, I'll just have to come back and make radical changes again.

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.
May 15 2011, 5:31 pm
You are correct. Throwing out old code is considered an antipattern, though I can't find a link to my favorite article on the subject at the moment. It's probably on "Joel on Software" somewhere.

New code or not, you should be considering, at this time, what features will not be possible given the time frame, and what features are both necessary and possible. Plan to include only half of those in the first release, and then you may make it on time.
May 15 2011, 6:50 pm
I'm terrible at throwing out old code. Time to bury that habit.

I think I've got enough time to add some weapons and crude AI opponents. That should be enough.

There's also a major feature to ditch: I initially had the idea to have the players do some base building and they'd get some base building contribution credit for this, but that's a whole other barrel of fish that I don't need to put in when "Get It Done" is the goal.

I was thinking I might even ditch the level of mecha customization I have and just put in some default chassis that have specific attributes on them... but that's not necessary because the core mecha customization is already complete and working.
May 15 2011, 8:50 pm (Edited on May 15 2011, 9:27 pm)
Antipattern is now my favorite word of the day.

Reading up a bit on on them, funny enough there is no actual antipattern against the idea of going in and making heavy revisions with the aims of making the code easier to maintain and use. On the contrary, the less obfuscated the code is, the better.

The closest I could see my tendency to go back and re-write the code fall in into from that list on Wikipedia are premature optimization (although that's more related to making code run more efficiently before it's needed) or reinventing the wheel (although that has more to do with avoiding the tried and true unnecessarily).

I think my very largest problem is Analysis Paralysis. Unfortunately, it's not an simple one to solve. These "agile programming methodologies" appear to be so sophisticated as to be delegated across a team. My personal hangups that lead to analysis paralysis require experience and cognitive restructuring to overcome.
May 16 2011, 1:55 am
They actually require you to first and foremost not care for your code, but care for your project's meeting of a deadline.

In my experience, people who suck at agile techniques either 1. follow them too rigidly or 2. care too much for their code.

As you are the kind not to throw code away, you're definitely 2, and maybe 1. as well.

You're not perfect, and nor will your code be. Better still, your code does not need to be perfect in order to meet it's deadline and be a good game.

Your code is not your baby, stop treating it as such. We don't get to see it and it's state ultimately does not matter currently, so long as there is a good game out the end of it.
May 16 2011, 2:41 am
What I took away from agile programming (which isn't something that's strictly from agile programming) is the emphasis on getting things to a functioning state. Build a prototype, get something working, see how you like it, and fix it up later. If you overthink an idea and scrap it before you've even made it, you didn't get any practice at anything. If you make a prototype to demonstrate a gameplay mechanic then, after seeing it in action, decide it's not what you want, at least you have the experience of making the prototype (and if you do like the prototype, you're that much closer to having a working game).

You have to think things through to some extent before making anything, it sounds like you just need to find a better balance. At some point you have to realize or admit to yourself that the theoretical realm won't cut it and you need to see things in action. If you think enough about any game (even your favorite game) in a theoretical sense you will be able to find a flaw (a theoretical flaw), but in actuality the game would be a lot of fun.