I’m going to write about digital painting today (edit: actually, marketing and project management, but let’s pretend it’s still about art) because everyone else is too weak and sickly to stop me. Are you happy? This is what happens!
Category Archives: Clockwork Empires
It’s instructive to just sit down for a quick, relaxing game of Clockwork Empires and then make a note of all of the little things that one finds frustrating or otherwise demanding improvement. As a result of this particular exercise, gabions are now built in assignments in the upcoming experimental build, rather than as individual elements. (Once certain graphics code is made to work again, we can also leverage this code to do things like brick walls and fences, so that at long last we may be Perfectly Safe.) I think we still need to do some more UI work on the gabion line placer tool in order to make it something you would actually want to use, though; however, large walls are now a thing you can have. Following the same line of thought – “does this annoy me? YES” – I finally fixed the overseer counter so that it only displays overseers and not artisan workers (including but not limited to vicars, artisans, naturalists, barbers, and basically anybody not in Her Majesty’s 5th Regiment of Swole); artisans now get their own idle counter. (We probably need to change the term “artisan” soon as well, as it doesn’t make a whole lot of sense anymore.) This way, you can see how many people are doing the base work of resource mangling, and how many people need to get new stockpile jobs assigned to them. Management!
I have also spent a certain amount of time this week rewriting the stockpile code, which I’m hoping to have rolled out in the next experimental. There are two parts to this.
A Clockwork Empires update has been discovered scuttling around our freshly cleaned floor! We present for you:
This update will go live to every Clockwork Empires player using Windows via Steam! The MacOS build will be delayed for a couple days because our mac hardware blew up. We’ve ordered a new one and shall inform you when the MacOS build is released.
We have also updated our Clockwork Empires: Development Progress Report!
Want to hear about all sorts of updates via email plus receive silly images from development? Sign up for the newsletter here.
Patch Notes for alpha 42:
- agriculture update: crop choice is really important now!
- a massively improved Work Crew UI
- added the Barracks to conscript & train military
- and we fixed a million things!
We added a first implementation of barracks to Clockwork Empires in experimental revision 41D (as teased in the last blog post). This is the start of giving the military mechanics more depth, providing the player with more feedback about the status of their squads, and providing the start of a structure to give more control to players over how their military operates.
The basic pieces of the Clockwork Empires game (relevant to this topic at least) are the character, the work crew, and the building. Up ’til 41D colonial military had only the first two. Giving them a building means military work crews an on-map home base, an anchor, and gives the player an on-world access point to see what the squad is up. And in terms of gameplay, it makes a proper functioning military require investment of resources! (From a game design perspective, we’re always looking for opportunities for the player to dump resources at potential problems to reward economic success.)
So how’s this work?
With Clockwork Empires becoming significantly more stable over the course of the last few patches, we are seeing a lot of people playing the game for much longer, which means that – in turn – when a bug happens, it’s the sort of thing that gets at you rather than just being something to be ignored. The pain threshold has, shall we say, shifted.
I’m trying to deal with a few long-standing issues this week, which mainly means dealing with small annoyances that detract from the quality of life of a Clockwork Empires player.
For instance, we have now fixed the work crew window slowing the game down when you are faced with > 100 citizens (and Daniel is busy doing Experiments on the work crew window anyway, so who even knows what it will look like after we’re done.) Similarly, the code base now correctly picks a random object from the list of items that can fulfill a job instead of just the last one; this has the nice and useful effect of making it so that citizens randomly distribute themselves in buildings to sleep in at nap time, instead of just choosing the last building chosen. David is in the process of sorting out the problem of citizens getting stuck in an infinite loop of burial, which occurs when a bandit corpse somehow thinks it’s at (0,0) on the game map which is usually stuck in a mountain. There is some work going on to make things more consistent, like ensuring that you can consistently cancel jobs and assignments in consistent places with consistent interfaces, that sort of thing.
And then there is the problem of people dropping meat onto forest meat.
Systems are interesting in sandbox games because they connect to each other. You can have a system that talks to another system, and then emergent gameplay what happens when the systems interact in interesting and novel ways. Re-usable, data-driven gameplay code is also cool, because it gives you a way to leverage work you’ve previously done on one system to make another system more powerful. Case in point: personal property.
One of the TODOs on my task list for awhile has been personal property. While you can build lower/middle/upper-class houses and beds, you can’t necessarily assign those beds to people, nor do people want a bed assigned to them. Instead, people just sleep wherever, whenever. This is going to change.