As IÂ amÂ gainfully employed, my time workingÂ on AutoFire is mostly relegated to mornings before work plus weekends. Â I don’t have any pretty pictures for you from this past week because I’ve been ripping outÂ the guts of the game,Â getting it into a smoother-running and more manageable shape.
In programming there is a phenomenonÂ commonly referred to asÂ “technical debt”. Â In short, it meansÂ if youÂ take shortcuts Â and the “easy way” for quick results, you usuallyÂ pay the price down the road. Â Those temporary fixes and band-aids that youÂ appliedÂ in lieu ofÂ carefully planning and documenting your work gets built upon again and again… Â Eventually that foundationÂ of toothpicks and dried spit can’t bear the weight, and you realize that your work cannot be maintained. Â You throw up your hands and say “This has toÂ be completely redone!” ThisÂ is the day your technical debt comes due.
In game development technical debt is common… Â Early in a project you want to prototype all the gameplay quickly to give everyone a sense of how something works. Â You try things, youÂ iterate on an idea to make it better, you try to “fail quickly”… Â You doÂ all those things that the best game companies hold up as their credo, which means youÂ have to focus on speed and agility. Â Try that crazy new control scheme, add a strategy component to your FPS,Â see what all the goats look like with hats, or whatever the team comes up with. Â This behavior does not encourage proper architecture, and oftenÂ involves what a programmer calls “a hack”.
BUUUUUTÂ game makingÂ also is a business, and there is always pressure to move forward because the last problem is in the rear-view mirror… Â This comes fromÂ folks like producers and publishers, but isn’t just about the folks in ties and suits: Â a lot of people on the team can get antsy if they don’t see new things on a weekly basis, becauseÂ morale is everything in a creative endeavor. Â Programmers get tremendous pressure to move on to the next big issue, and frequently they will warn the powersÂ that be of the technical debt that is being accrued.
Of course,Â when the day comes that the debt must be paid off,Â it will involve days and days (sometimes weeks!) of time when nothingÂ changes… in fact, the goal of this cleanup is that everything should work identically as when you started. Â It’s very hard for an outsider to understand… Â One day long ago I witnessed a manager straight-up ask “But can’t you just hack the entire game?” Â No… not if you want something that won’t fall apart when thousands of eyeballs and eager mouse clicks are set upon it.
Nonetheless, “hack the entire game” is precisely what the 7DRLÂ is about… Â You need results nowÂ and you don’tÂ apologize for it later. Â You’ve got 168 hours to get to the finish line and you don’t care if you trampleÂ over every “Write Smarter Code” author who ever was. Â And I certainly did that.
For AutoFire my control and world update system was my cross to bear… Â I piled my inputs and the control of my entities in Unity’s “Update” system, where each object gets called every frame. Â I cobbled together some bullshit traffic-cop system to move things in the right order, except Unity plays it pretty fast and loose… Â There isn’tÂ really a great wayÂ to guarantee that, say, the function that tells a car where to go would run before the function that actually moves it. Â Frankly, I started to not fully understand how the damn thing worked at all.
I knew the debt was coming due… Â Players didn’t always feel their commandsÂ were registered. Â 10% of the time the smooth movement of an entity would inexplicablyÂ twitch. Â The enemy vehicles just spontaneously stopped working. Â But I knew fixing it would be a slog, which is why I procrastinated by workingÂ on some pretty terrainÂ last weekend instead of doing what I should have been doing.
WhenÂ you have to rewrite someone else’s code, you can get prettyÂ grumpy about that person. Â But when you have to rewrite your own code, you decide that months-ago you was either an idiot orÂ a complete dick. Â “What was I thinking?” getsÂ uttered out loud several times, as well as “What the crap is this?” and the classic “How the hell did this ever work?!?”
But a week later and all is well. Â The code to control everything is about 25% of its original size. Â Everything is carefully managed. Â Your input is now queued up and doled out to your vehicle on demand. Â Now I can get back to the fun part of making things blow up.
3 thoughts on “Auto Fire: Technical Debt”
An interesting look into a programming phenomenon I’ve never heard of. AutoFire’s evolution from a 2 dimensional 7 Day Roguelike into a 3 dimensional behemoth of a personal project is startling. I’m increasingly excited for its next release and applaud your dedication to such a niche concept.
Thanks! I get more excited about it as each day passes.