The Great Building Creator Rewriting

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.

Interior furniture concepts.

Interior furniture concepts, once interiors become A Thing.

The project I’ve been meaning to tackle for awhile now has been the process by which buildings and modules are placed in game. In the original version of Clockwork Empires, buildings were not intended to be placed by dragging and dropping rectangles. Rather, they were placed by tracing an outline with line segments. While this let you create interesting buildings and all manner of terrifying Euclidean geometry, this also introduced problems: you could only attach a module to a building at a 90 degree angle, so it would be possible for players to create buildings that they couldn’t attach a module to, etc., etc. At a different junction, modules were only ever placed *outside* of buildings. At some point in development – I think in the middle of 2013 – we collectively decided that we needed to be able to have characters go inside of buildings and interact with the contents directly, which is something we originally didn’t want to do because it opened up many cans of worms. After several rather painful iterations, we ended up with the system that we currently have today.

Very old module concepts, exterior modules only.

Very old module concepts, exterior modules only.

The system that we shipped had a number of problems. The following is a short list, off the top of my head:

  1. Various things could cause buildings to explode or not render correctly, such as putting ovens in corners in various configurations; alternately, occult roofs could be generated by various Forbidden Configurations of modules. (These have, by and large, been fixed.)
  2. Snapping was, and still is, a mess. Very often modules will snap to somewhere where you don’t want them to go, violating a UI principle called “The Principle of Least Astonishment.”
  3. Module placement, by and large, never felt “right”. There is an expectation that the module in game will be as centered around your mouse as it can get, and that was never really satisfied because we would center things, as much as we could, around the current… vertex? Square? What? And then snapping happened and that got weird too.
  4. No visible feedback to the player about where they were dragging their building tile to, and building tiles corresponding to vertices and not to tiles during the selection process.
  5. Various other issues involving creating a module, and having that module move from the rendering thread, to the gameplay thread, back to the rendering thread. In particular, this could create a very laggy and unresponsive module placer.
  6. Various issues where you could place buildings next to each other and not have A Good Time, or have modules placed into other modules, or putting farms under modules, or various other sorts of Forbidden Configurations.
  7. A recurring crash when placing multiple modules.
  8. Footprints extrude from buildings too far, and don’t match the footprint of the module.
  9. General other problems with moving and deleting modules consistently.

There were also the following technical problems, and a lot of these technical problems prevented us from addressing the UX/UI problems identified above:

  1. “Who the heck owns the blueprint data?” A lack of clear ownership semantics in the codebase meant that the relationship between a building, its modules, and the footprint was never clear. This is because the code was originally written for a system where buildings had modules attached to them, and stockpiles were also always building attachments, and then stuff kept getting shoehorned in and refactored and so on and so forth. What a mess. This, in particular, was causing the recurring crash when placing multiple modules, where various “child modules” would never be correctly linked, or de-linked, from their “parent” module, but sorting this out meant a journey through data structures that humankind was not meant to probe;
  2. When we rebuild something, say after moving a module, we don’t do a good job of propagating the changes downstream, because – well, we don’t know who owns the blueprint data. So things like footprints don’t regenerate themselves cleanly after you move them or delete them.
  3. Orientation of modules was… well, complicated to work out, because all orientations were defined relative to the center, and the center of a module would be ambiguous for something like a 2 x 3 module (where is it centered in game? Where is it centered on the renderer? Help!) This ended up in a mass of sign-juggling, across two different systems (the spatial dictionary, which stores all game positions and tracks all entities in game)
  4. General legacy code and various stinks and messes.
  5. No good support for standalone modules, which are not attached to a building; this blocks various things like conduit generators, bunkers, and turrets.
  6. How the heck are we actually going to add conduit inputs and outputs to this thing, anyhow?
The first CE concept art for building interiors -- this is when we decided it was possible.

The first CE concept art for building interiors — this is when we decided it was possible.

I have sort of known that a full scale rewriting campaign would be necessary to get these things dealt with in order for us to ship Clockwork Empires, but the time had never been right until the start of this month when I finally snapped and decided to start rewriting things from the ground up. I made a few key architectural changes:

  1. Module templates can now exist free from buildings, and don’t have any common ancestry with them. (Previously modules and buildings were both shoehorned into the same class structure, which is one of those decisions that made sense back in 2012 but right now is just a bad thing.) Because all of this is now clean and separated, things like “adding things to the right scene graph” and “removing things from the render tree when you switch into, and out of blueprint and regular mode” are now much easier to work with and debug. No more trying to figure out why the access points disappeared on a model.
  2. All rotations for modules are all calculated relative to the upper left hand corner of the module model (which is how it’s actually set up in the actual model.) We still want things to feel like they are centered with respect to the mouse, but we now just translate *once* instead of *all over the place*; a clear win.
  3. Module templates and building templates now have a local ID and a local player ID. This means that we can re-link a building and a module with the templates you created across threads, whereas if you get a building or a module over the network (or in a replay) we will recreate them for you.
  4. Zone templates (stockpiles, farms, graveyards, roads) are now their own things.
    One major issue we’ve had in the past is that it is very hard to visually debug obstructions and the like; the spatial dictionary lives on the game thread and the renderer lives on the render thread, and they don’t really talk directly. Consequently, the game lets you dump out all the obstructions in the game to a SVG file for debugging purposes, which is fine but you have to load the SVG in an appropriate viewer and then figure out which way is up on the screen etc. I threw a wobbly fit and added code to display the spatial dictionary obstruction data directly on top of the terrain, a code change made possible by a previous cleanup pass I made to fix some rendering issues with the grid flickering in and out on AMD cards. That turned out to be very helpful, especially in trying to rewrite the portion of the spatial dictionary code that computed obstruction information for modules. Without a visual aid, that would have been impossible; as it was, it took me a day of cursing and swearing.

I’m hoping to get the first version of this deployed into the experimental build stream early next week, so that we can bang on it for a couple of weeks and get all the bugs out. As building things is one of the key feedback loops of the game, it’s hugely important that it feels fast, fun and responsive.

More old module concepts!

More old module concepts!


Posted in Clockwork Empires | Tagged , , , ,

14 Responses to “The Great Building Creator Rewriting”

  1. Thomas says:

    2 story tall chimney, eh?
    Is this implying that there might be 2 story tall buildings in the future?
    I can only imagine the nightmare that a workshop with 2 different floors would cause.

    { reply }
    • AdminDavid Baumgart says:

      No, two story buildings are just trouble. Every play the Sims? The problem you can only ever see one floor at once. So do you add a button to switch floors? Do you make the player fiddle with that button whenever they want to see another floor? It makes for an unwieldy interface for little payoff.

      Anyway, in the context of the concept art, that was just a reference to the height of the chimney.

      { reply }
      • Samut says:

        I realize multi-story buildings are not going to happen in CE, but since you asked, how about click and hold the left button on a building, and rotate the mouse wheel to change the displayed floor (or move the mouse up and down if there’s no wheel)?

        What do I win? Nothing? Awesome!

        { reply }
        • AdminDavid Baumgart says:

          That’s actually pretty good.

          Still, I’m generally opposed to hiding entire fields of the game, like the Paradox mapmodes. Even multiple floors in xcomlikes ie. Xenonauts are a bit awkward, especially when you get zapped by an alien hiding on a floor you didn’t bother to re-check when it came into your line of sight; at least that one is turn-based.

          { reply }
  2. Gaz says:

    Would it possible to have a building with lots of different rooms? Or even skybridges and access tunnels if and when multiple stories are implemented?

    { reply }
  3. Menthol_Penguin says:

    You say at the top that multiplayer is on pause indefinitely but later on you mention ” local ID and a local player ID (for the multiplayer stuff, which will still happen.)” Is this id stuff for the Round Robin bit mentioned above?

    { reply }
    • AdminDavid Baumgart says:

      That’s what we call a failure to edit drafts properly; however those IDs still do and will exist in the codebase even if there won’t be multiplayer. They’re not actually necessary for round-robin style game sharing.

      { reply }
  4. Matt says:

    Cant wait to see where this game ends up

    { reply }
  5. Akuma says:

    I’m not surprised you decided to drop the multiplayer aspect. Like many design concepts there really good on paper but an uphill struggle to actually implement.

    Handing over save files makes a lot more sense in the context of what you can do in the game. So I support this decision.

    { reply }
  6. THANK YOU for ditching the pretense of multiplayer. Not only is it not nearly as important in a game focused on inducing psychosis in tons of little virtual people, but it is something you would have had to get working and keep working all along, at absolutely inordinate expense.

    Keep going! Don’t lose hope! I still pine for the day when I can plug an obelisk module into my factory and have people rapidly start going Horribly Wrong all thereabouts.

    { reply }
  7. Merneith says:

    Sounds like you’re making great progress! I’m glad succession game support is still there but multiplayer always sounded unnecessary. I wish SimCity had ditched multiplayer.

    { reply }
  8. “Footprints extrude from buildings too far, and don’t match the footprint of the module.”
    Oh yes. The dreaded furnaces. You place the blueprint, the furnace gets assembled and it turns out it sticks out less than the blueprint indicated. Or the other way.

    { reply }
  9. Stefan Bauer says:

    I’m sad to hear about the multiplayer, but I’m not surprised. It always sounded like a really big job.

    Curiously enough, after thinking about it I’ve realised that what I really want is (shock! horror!) a sort of meta-game multiplayer, similar to how the Simcity reboot did it. I’d love to be able to trade with settlements my mates had set up (and undercut their prices at every turn, and possibly bribe the Stalmarks to trash their stockpiles).

    { reply }
    • MailersMate says:

      what would be cool. Assuming you don’t cripple the player’s ability to build independently like Sim City did.

      Honestly what were they thinking?

      And as others have said regarding network multiplayer, I concur that it always felt like the most optional aspect of the game – round robin works much better for a situation were the main multiplayer draw is community generated madness.

      { reply }

Leave a Reply

Your email address will not be published. Required fields are marked *