Technical Debt is a handy metaphor that has been used in the programming community for awhile now. I sort of think it’s one of those things that probably got coined by somebody in the Lean Startup community, or the Agile community, or something like that. The idea of the metaphor is simple: you incur technical debt at the start of a project for a variety of reasons – getting your software started or out the door, for instance; or meeting a release target. At some point, however, the debt collector comes calling. This week, I seem to be paying my debts off: in the case of Clockwork Empires, we incurred a lot of technical debt getting the game into Early Access, with the knowledge that at some point during the process we would have to pay it off in order to get out of Early Access. Well, the point of paying it off seems to be this week.
I don’t know how many times in the course of development we have used the Sheng-Ji Yang quote from Sid Meier’s Alpha Centauri about how “One does not simply take sand from the beach and produce a Dataprobe.” But, we’ve used it a few times and today is no exception. Game development is an inherently iterative process, especially early access game development: you build systems, you attach other systems, and eventually – at some point – you run out of systems to build and cross over into a territory that consists purely of refining existing systems.
One of the major systems outstanding that I have to finish is the overworld. We have previously added randomly generated overworld maps, which are generated using a standard approach: “take a lot of Perlin noise, generate some Voronoi cells on top of that, fill in various land masses, and off you go.” What has been missing is the code which lets you pick an arbitrary point on that land mass and go exploring.
We have now reached the point in our Dataprobe creation process where we have started adding that.
First off, an announcement: we have decided to suspend development of simultaneous networked multiplayer for Clockwork Empires indefinitely. There are, simply put, technology issues and design issues that we don’t feel we can satisfactorily solve in the foreseeable future. Furthermore, we don’t want to devote time to addressing those issues if that time will detract from the single player experience, which people are currently enjoying and which is the major thrust of the game. Support will exist in engine for round robin “let’s play” games, and we will continue to build that out as we work our way out of Early Access and into a new stage of development, which we are tentatively calling, uh, “Access.” As always, we thank you for your patience and understanding of the harsh realities of game development.
That said, let’s talk about “Access.”
Somebody recently posted on Twitter that polishing a video game was a straight forward process: if it doesn’t move, make it move; if it moves, put a sound effect on it; if it moves and has a sound effect on it, add a particle system. That’s a pretty accurate guide, honestly. In our case, we went into Early Access with a few things that were not in the best of states, and one of the ongoing things that needs to be done in order to transition them from “Early Access” into “Access” is to address the problems that people have with them. In some cases, this is a question of making some changes, watching the feedback, and then continuing to improve the system or re-designing it. Sometimes, such as in the case of cults, or emotions, or what-have-you, we have to take a few swings at this particular issue.
We are still out of the office until January 4th, 2016, at which point the terrifying cogs of progress begin turning once again. Today’s blogpost, therefore, is put together out of whatever images I can find on my computer. Which is okay, because we’re really interested in Trade Depots today, and I took a lot of screenshots of Trade Depots. But first, a little history.
Here is the first version of the Character Info screen for Clockwork Empires, circa January 2013 (right at the point where, maybe, we had little characters running about and doing something.) For those of you who are wondering how much optimization has already gone into the game, we seem to be running at 28 FPS here despite… not rendering much of anything.
Fire! FIRE! FIIIIIIIIIIIIIIIIIIIIIIIIIIIRRRRRRRRRRRREEEEEEEEEEEEE!
Fire! Oh no, fire! Quick! FIRE! FIRE
We almost forgot about the blog post today. There are a few possible explanations here. Either David went off to Thanksgiving-land and took with him a sizable portion of our scheduling acumen, or since we keep finding things that have slightly changed around the office that don’t make sense, we must have lost twenty-four hours of time like in that Star Trek: The Next Generation Episode, “Clues” (where the crew of the USS Enterprise keeps finding things that have slightly changed around the office that don’t make sense, leading them to believe that they have lost twenty-four hours of time).
Anyhow, patch 45 went well. People seem generally pleased with the decision tree code and how it’s working; the military does their job perhaps too efficiently, to the point of starving to death if you leave them rallying for too long. (We’ll fix that.) Building decor has been a hit, and the main source of confusion that we are currently trying to track down involves food production, which seems to be fine for some people and occupying 50% of colonists in a colony for others. (We’re working on figuring out exactly what this second set of individuals is doing. Mr. Triolo is busy consulting a complicated series of charts and muttering “oh dearie dearie me” while nervously fiddling with an astrolabe.)
Today’s blog post, however, also falls in the inconvenient space between “we released a patch with all our new stuff” and “we have new stuff to blog about.” So while we are *just* getting started on new stuff for this month (military features on my plate, Daniel doing some UI stuff that he doesn’t want to talk about yet, Chris taking advantage of the fact that workshop jobs can now accept multiple, disjoint inputs to produce a single output), we don’t actually have any of that
This week’s blog post, therefore, will be “al fresco.”
I’m very happy with a lot of the changes in Alpha 44; a bunch of the seemingly less-consequential AI improvements, such as the stockpile rewrite, seem to have been very well received. I therefore decided to do something fun last week on Thursday and Friday, and start rebuilding the rendering pipeline to support interior and dynamic lighting. On our old development report this was actually the last rendering ticket.
The thing that made me grumpy about the interior rendering is that we don’t want exterior dynamic lights to leak into the interior – if you put an outside light on a building, you don’t want it shining in the interior. Similarly, you don’t want to have a light inside a building reflecting the outside of the building. Finally, it would be nice if we could set the interior and exterior lighting of the world differently.
First off, a status update: we will not be releasing Alpha 44 this week. We will do an Alpha 43C at some point, and will aim to do Alpha 44 next week. This is due to a number of non-work factors, and we apologize for being a little out of sync. Alpha 44 will be better for it.
Last time I wrote a blogpost, I noted that we were redoing the barracks to use a new user interface. Well, the interface code was written, but disabled, because we needed to set the AI to use all the new goodies (and, also, to make sure that we fix some of the long-standing military bugs that make our soldier friends less than effective.) The issue here is that we have a big block of decision tree code which should drive military decisions, as well as your hierarchy of Maslowian needs. Right now, this code doesn’t really have a unified mechanism; there is a big block of code that is hard coded for colonists which evaluates their military tree, and that’s sort of a big ugly mess. There needed to be a mechanism to evaluate a decision tree – a series of requirements and “do I succeed at this requirement or do I fail at this requirement?” decisions, which we can run through consistently and without touching the scripting system. I planned on doing this – and even blogged about it! – a few months ago, but kept putting the rewrite off because I knew it was going to be terrible, and because there we always other things that needed to be done first. Anyhow, I finally ran out of things I could meaningfully do before doing this horrible rewrite, so I finally said “ugh” and started in on it.