ID:89375
 
Keywords: game, motivation
It's a little after 7am PST and, from the perspective of somebody who's been waking up at 10:30am or later for the past 3 weeks, that's a small slice of personal hell. However, like it or not, I've got a new semester at the university starting up on 3 days, and so when my body pulled a "it's 6:30am and you're wide awake" move, I decided to take the initiative on getting my schedule adjusted.

So far today, my early bird initiative has been rewarded by slipping in the shower and cutting my chin while shaving, but lets get down to the important question: how has progress been on Project Shock over the past 4 days?

In a word: phenomenal. I decided to follow up on my New Year's resolution to log everything I was doing every day while I was doing it. The goal was to simply find out where all the time went, but this has had an unexpected side effect that a life examined spends very little time procrastinating. Often because keeping tabs on what I'm doing gives me a second chance to assess the value of doing it.

Project Shock Jan 7th 2010

On the surface, you won't notice much difference from this screenshot versus two weeks ago. Beneath the surface, I essentially completely rewrote the code that governed nearly everything.

Much of this Project Shock code was pretty old, predating my Vehicle Wars project, and I had learned a thing or two about writing more elegant code since then. Among the things I can remember doing this week:
  • The movement queue was running off a simple 4-variable action datum that instructed a queue handler to activate individual procs. Basically, the code was being routed all over the place unnecessary. So I changed the action object to have children that represent actual actions and include all the necessary code to intelligently perform actions of that action type. I even included a proc which generates images representing what the action is doing to the client, if requested, and remembers these images so it can be conveniently removed from the screen.
  • I used to have an object with a blank name that functions as grid control because that was a necessary accommodation prior to the introduction of the "show names on grid" toggle. That was no longer necessary, so I rolled that into my ability objects.
  • Speaking of ability objects, they used to house the actual code that allowed abilities to function. Now Action datums do that, and ability objects are used as GUI elements that spawn them as well as track uses and upgrade level of that ability.
  • Each projectile object had completely separate code for much of the same behavior. Now, they have much the same code as children of the projectile object, with overridden procs for wherever their behavior differs. It's now a lot cleaner and easier to make new types of projectiles.
  • Device objects received much the same treatment of code consolidation as the projectile objects did, but were also revamped to not require a constant heartbeat function be executed. Instead, they only update when something happens to them.
  • Respawning has been revamped so the necessary code exists on the appropriate objects.
A lot of these improvements were because I had since learned how BYOND nests custom procs in the object oriented architecture. I had made a false assumption that the "duplicate definition" error of trying to override a proc was because BYOND only allowed overriding of built-in procs, but actually you just need to leave the proc keyword off the children. Having overcome that brought about the ease of managing code and the resulting flexibility.

Looking forward

Since I spent the majority of the week rewriting what I had, in terms of how close Project Shock is to being a released, playable game, I'm both no closer in terms of what you could play and considerably closer in terms of how organized the code is and, consequently, how much easier it will be to see the game through to a finished product.

More importantly, not all time was spent coding, a significant fraction of it was spent designing. I came up with what I feel should be a pretty darn compelling focus behind the game and have a much better idea of what I'm shooting for now. What is that focus? It's a surprise. Suffice to say, this game will be a multiplayer Sci-Fi roguelike with more than a few twists and mysteries.

How long until you can try out this game? Well, I would like to have a playable unfinished prototype up, with a static map and without a save function, before I return to school on Monday. That way I can get a bit of feedback on it. I can imagine this would happen. However, will reality match my imagination? Only time will tell.