City Block Builder: DEVLOG 3

Hi there, this is Gary and I’m one of the devs for City Block Builder. As this is my first blog entry, there are probably a lot of things I could talk about -- but what I’d like to start on is what’s fresh on my mind, and that’s the topic of finding a balance between design wants and needs.

Game development is an ever-evolving process. Ideally, most engineers would love to be able to create their systems “correct” the first time, to be able to account for potential future needs, and keep the code clean to try to keep technical debt low. There’s a problem with that though. Unless you are trying to copy a game that’s already been done, there will be changes to design. Many changes. It could come in the form of the designer/game director wanting something different, or it could come in the form of realizing that an already agreed-upon design will simply not mesh together with the new feature that we want. This means that no matter how good your code is, you will probably end up changing it during the early-mid stages of development, and all that extra time you spend making it in tip-top shape will get scrapped anyways.

I’ll give you an example of the latter. The Sims 4 is one of the main inspirations for the build mode side of the game. We wanted a feature where you could select a zone, select a side of it, and stretch the zone to either expand or contract it. We looked to The Sims 4 for how they do it. One aspect of it is there’s a previewing system when attempting to stretch a room that uses translucent walls to indicate where the new walls would land. We thought we could do a similar previewing system. As I started to implement that feature, I realized it could not work within our system because of fundamental design differences between our game and The Sims 4. 

They were allowed to do this translucent previewing system because they have what I would coin as a “bullying” build system, meaning that when building, the thing that is being built is an absolute bully to everything and just simply overwrites anything it encounters. In The Sims 4, this isn’t a problem. A room could stretching into another room, splitting that existing room in half. It could also completely overwrite a smaller room. The reason is because in The Sims 4 you can put anything anywhere and there are no build requirements.

In City Block Builder, we do have multiple requirements and limitations. We have to have validation to make sure we never split a zone in half or overwrite one. Every business has zone requirements, zones which must exist, and must connect in certain ways. Walls also had a lot of data associated with it which was related to zone ownership, prop ownership, and so on. 

If we had a translucent previewing system, we would have to store all of the validation done, then have a way to revert it for every step of the stretch. It was going to create a lot of unnecessary bloat for a minimal design feature, so we decided to simply update walls on the fly as they were being stretched. If there were any collisions with props and walls, the props would be sold as you stretched. Of course, this meant that stretching walls is not reversible by hand, so that’s why the undo command is mandatory to make our build mode flexible.

We had this translucent previewing system queued up as a feature for quite some time, but I wasn’t able to test it until a lot of other systems were in place. Sure we wanted this feature, but it was directly contradictory to the core of the build game flow. To put it in the game would have been a lot of work for little payoff. We managed to find a design that ended up working in the end anyways, even if it was different from what was initially desired. My point is that as you develop a game and certain features become solidified in the game, you must always be willing to have the flexibility to change subsequent features as to not compromise your game’s core design. You can’t have it all, and a lot of features that look like it’d be “nice to have” may have a very real reason why it can and does exist in a game.

Gary Chao - Sr. Developer