It’s that time of the lunar calendar again! We’re going to be putting out a major monthly patch in a few days, more info to come toward the end of the week.

As for game development news, this blog post was really tough to write because I haven’t actually been working directly on the game code in probably a couple of months now, barring my brief work enabling a new biome.

#1 Management Tip? Condition.

Most of the work that I’ve been doing has been the rather inglorious work of preparing revenue reports for our financial partner (Canada), preparing for taxes, product management, and other typical things that business owners need to do. Nothing glamorous or interesting as game development blog material.

Between “Early Access” and “Shipped”

One of the things I have been doing for the last few weeks, though, is quantifying the details that separate our game as it exists now from the level of polish people expect from finished games. There’s a gulf between a nearly completed game and a completed game that comes down to all the tiny details that aren’t absolutely necessary for the game to function, but these are the details that remove the necessity for the player to do detective work to play the game. In a truly great game, among a host of other things, the game will gently encourage players to do the things they wanted to do anyway in all the right ways without them having to puzzle out how. This is what we need to do to get from the bare skeleton of a game to that properly fleshed out experience. Getting there is a little weird.

Prototyping Systems

First, we have many systems that are still in the prototype stage. The important core game framework is essentially done (have a look at our Development Progress report if you haven’t yet), but there are many smaller subsystems that we’re still working on getting right, and about half of the UI systems still live in prototype land. Prototypes don’t get polish; they get the absolute minimum amount of work that we can invest to decide whether they work or not. Not only is it important not to over-polish these things, it’s equally important not to under-develop them because often we’ll look at an unfinished prototype and start thinking about trashing it right then. But when it’s actually finished, it turns out to be exactly what we wanted. (The building creator was a lot like this.) The key to finding the right amount of done-ness for us seems to be a combination of practice and grinding down our designs until we know exactly why we want to make any changes, what the exact benefit of those changes are, and how little we can change to determine whether that change has a desired result. Often this is super difficult, and it sometimes seems impossible, but in most of those cases we find we’re sort of wading around the problem without knowing exactly what’s bothering us. The key then is to figure out exactly what we’re trying to do rather than flailing around.

We need to know exactly what happens when you click anywhere on this screen after clicking anywhere else on this screen.

Then once a system is out of the prototyping stage, we have to polish. Usually we have a bunch of tasks that we wanted to complete for a prototype, all the little sub-features that make a feature feel really nice and complete, but they were hacked off and set aside for later as they’re unnecessary for a minimum viable prototype. We go over that list to make sure it’s all still relevant, and then we do as much of that as we can.

Once we have gone through the backlog, we start seeing how people are interacting with the new system. We look for places that people give up on a UI, or where they don’t notice the things that we feel they should notice. The creepy “watch someone else play your game” style of feedback is the best method, because it’s surprisingly clear when a design isn’t getting across the right idea to a player. They often try to click (seemingly) random things, and when that doesn’t work, they shrug and move on. This feedback is really, really great, but also pretty expensive because you only really get good data from any one tester once.

Interpreting Feedback

We also start listening to feedback from all of you about these systems. Some of it is extremely detailed (and extremely helpful), but most often this feedback is pretty high-level. We get a lot of vague comments like “this feels weird” or “I don’t like X”. These aren’t specific enough for us to act on directly, but they do serve to let us know that some area of the game deserves a bit of scrutiny. If we receive enough mentions about a system that we can’t pin down we might specifically do a sit-down playtest with a friend that hasn’t played the game yet (which is getting harder).

When Not To Innovate

With Clockwork Empires we’ve made very specific decisions about how the game diverges from traditional management simulations or settlement builders. But there are  many smaller systems – anything from menu behaviors to expected control schemes – which we specifically aren’t trying to be innovative with, instead leveraging the learning that players have done with games in these genres for years, or even the expectations built up from simply using a graphical operating system like Windows or MacOS. In these cases, we can go click by click through a series of interactions to make sure that what is happening on the screen is what the players will be familiar with. It’s frankly staggering how many cases there are for interactions with a game (Example: if a player is in module placement mode, if they have a module selected from the UI, what happens when they right-click vs. left-click?). Often we overlook one or two cases and this causes the game to feel unresponsive, frustrating, and somehow indefinably un-polished. We now have long lists of “when in this UI mode, button X should do thing Y if state Z is true”. There’s a very similar process for attaching visual and audible cues to interactions: “when you click this button, make this noise, display this animation”.

Just walk away.

When we start this process, it seems like a never-ending list of tiny, almost totally inconsequential tasks. But when it’s over, the game feels like a Real Game. There’s really nothing like it. It’s a strange process, and it’s extremely rewarding in the long run.