Amberspire News

See the other design diaries, wishlist the game, or subscribe to our newsletter.

So far the design diaries are still very much in the pre-production phase, where I am trying to sort out my thoughts on what kind of game I want to make, before actually figuring out all the various details. Today I put together my thinking about the incentives games put on players to make decisions and seek goals.

A lot of game design is about applying pressure on the player to create an interesting end state for a game. In a competitive game, the end is important and the pressure is typically another player who is competing against you. For a single player game however, both pressure and end state become important factors that have to be manually shaped. Early on in thinking through Amberspire's design, the question was simple enough - what is pushing the player forward?

My design tendency is to make anything the player is doing important and relevant to the system overall as a whole. I find it very rewarding for the player when all the threads of a design are pulling their strongest towards a single goal, but this can feel overwhelming if every decision has a great importance. Certainly The Banished Vault has this, for better and worse. For Amberspire I don't want decisions to feel pointless but I do want to encourage 'messing around', for lack of a better term.

[h3]Pressure[/h3]
Pressure can be vague so I’ll be specific - essentially I see it as a reason the player should do something, to actively choose one action over another. You take a move to advance a position in chess, because the other player will gain territory if you make a ‘useless’ move. The pressure is in doing one specific action over another, or suffer some penalty. In The Banished Vault, you visit planets with the resources you need, because you have a limited time in the solar system. The ultimate end conditions for a game directly drive these pressures, but as I'll elaborate below, not all of them! Chess is sufficiently interesting with the sole threat of your opponent winning.

For Amberspire, my goal is to have these end state pressures be relatively minimal, to reduce that "every move must count" feeling. This is partly because the game is so dice driven - the consequence of most rolls are fairly mild, and resolving those consequences is not complex or time-consuming. My goal is for a lighter city-builder instead of an intense strategy game where every action has multiple and immediate consequences.

[h3]Messing Around[/h3]
This affords the messing around. I highly value messing around in games of all kinds, and I think the majority of players do too. Messing around in our context is simply taking actions that do not further the player's position in the game towards an end point. This is very straightforward in open world videogames or crpgs - a sidequest. In something like a tabletop rpg, one could argue the entire goal is to mess around. For a board game, which typically has more specific end points and competitors, messing around can be exploring the design space to see what might be possible.

By making dice such a central factor in Amberspire, I am actively embracing messing around. The dice are meant to nudge you around in your pursuit of your goals, and add unpredictability to how your city grows. Even so, because of the generally light pressures on the player, messing around is encouraged. Rolling a bunch of dice and seeing what happens is a perfectly valid way to play the game, and will still result in interesting outcomes. The goal in this early phase of the design was to construct a system that encourages this without feeling like actions are pointless or meant nothing at all.

[h3]End States[/h3]
So, what are the end states and what goals do they give the player? In some ways these are nebulous. There’s certainly a version of this game that is more run-based, where cities fail and the player should try again with better luck and/or strategy. Or, as city builders typically do, there is no strictly defined end goal. Big simulationist city builders end when the player no longer has interest in running this particular city, or eventually the homeostatic processes fail and the city falls to ruin, or both.

Neither of these felt particularly right for Amberspire. I wasn’t making a simulationist game, but I also didn’t want to impose a strong loss condition. I also want to explore a kind of ‘maintenance’ play, where the city does not grow or shrink but still provides challenge and drama for the player. As it stands now, the game does have a demarcated end state, but it's both optional and somewhere between 'totally start over' and 'play forever'.

Without a strong win/loss condition, as a designer I want to be aware of the goals the player will approach the game with. In my notes I outlined what I thought those goals might be, mostly to keep them in mind for myself. Those goals are:

• Expression - designing and organizing the city in a specific manner
  
• Growth - making as large a city as they can imagine or the game will allow
  
• Storytelling - narratively interesting events arising from the systems or player actions
  
• Stability - Creating a city that can handle unexpected events or bad dice rolls
  
• Luck & Drama - creating a plan that hinges on lucky dice rolls, or generally exploring the dice system
  
• Efficiency - using only the dice and resources necessary (or a small city) for maximum achievement of other values listed here
  

Not all of these are equally supported by the game, or given a full suite of tools to explore to the fullest. Nor is this probably a complete list! But early on to give a design some direction or some metric to judge ideas upon, it's a pretty good start.

Cities are a natural setting in a science fantasy universe. Built over their own ruins, where the past and future mix into a heady kaleidoscope of people and technology. Cities are a microcosm of the world around them, but also with unique details and inertias. Without having to write (or read) tons of lore, just what kinds of buildings are in a city, what people do there, how it engages with the surrounding environment says a lot.

The upside of a modern or medieval theme is it's very easy to communicate what function individual elements of the game serve. For example compare “stone” to something invented like “plastoid”. Everyone knows what stone is, how to get it, and its benefits and downsides. “Plastoid” needs an explanation, and requires more from the game on what it is, what it does, and how to get it.

For a space fantasy setting like Amberspire's, the details are important, and the resources are the most important. Them and the buildings are the first elements of the theme and game the player interacts with, and continues to throughout. What they are, do, and how the player gets them reflects the setting of the city and the world, and is a direct line to the player's mind on what's going on in this world.

That said, communication is still a concern! For Amberspire I’ve tried to mitigate this issue. The first is to use only common words like Metal, Quartz, or Sunlight. A few might bend this rule slightly (they don't have final names as of yet!) but they will be understandable within the broader language of sci fi concepts.

The next big thing is being very loose with the idea of what constitutes a resource. Resources like Shadow, Ritual, or Glow represent ephemeral and abstract concepts but are still treated as other resources: created by buildings and used to make your city function. The game slowly introduces these resources and the player can begin to interpret what they are by how the city uses them. These are in place of fussy, complex, or interchangeable sci-fi/fantasy resources that can fall flat. I don’t expect the player to know what Horizon, Tides, or Gathering are when they start the game, but they do represent things and interpreting what they are is an aspect of the game.

The resources are a primary method of communicating science fantasy to the player, as important as the art and music. If the player is thinking in terms of wood, sheep, or stone, no matter what the aesthetics are telling them, the theme is undercut by how the player thinks about the game in a straight mechanical sense. When playing Amberspire, sentences like

I need the Lighthouse to produce Void to construct a Clockworks.
I'm not sure whether the Silk is better used at the Starport or the Arena.
A nearby Observatory can generate Starlight for both a Necropolis and Arboretum.

will cross the player’s mind. And that brings forth the science fantasy theme that I want, in a way that's inescapable.

Dice are fun. They are probably the oldest game component in human history! As humans we like tactility, we like throwing things, we like winning and losing based on chance. It's fun to give up your control in a game and see what happens. Attaching this to a city builder is nothing profound – it's a fun cycle to collect dice from your city, roll them, and use the results to shape a city.

That is a good entry point, but there are larger ideas that follow. Tactility is about how the dice present to the player; control is simply that dice create random outcomes and what does that do to the idea of a city builder; and design resolution is one way to think about where the overall focus of the player and designer should lie.

[h3]Tactility[/h3]
As the design got started my thinking with tactility were the pitfalls to avoid, in order to keep the dice rolling easy to predict and process. The first is the number of dice: in my view, players can roll up to about eight dice and still process what’s happening. More than that and it's a big jumble of information that might require time or a computer to sort out, which I wanted to avoid. Typically in Amberspire a player rolls two to five dice at a time, and the early design work focused on how the player would naturally arrive at those numbers, which will be discussed at length in a future design diary.

The other thing I set out to avoid was an overload of information on each face of a die. I knew Amberspire would be using a lot of resources unique to city builders generally, so an early constraint was to say that each die face could only have one symbol on it. This is partly a complexity budget concern, but also one of readability. I don't want to demand the player learn a bunch of symbols and be able to tell them apart in a group on the side of a die.

This general simplicity also communicates a lot about the game and where its goals lie, and what it expects of the player. Looking at the game you can infer that there are quite a few resources, but each building only rolls one die, that die always has six faces and can produce at most six resources - usually fewer! You can easily look at a die and evaluate what it can do for you and whether you want to roll it or not. This hopefully tells the player how complex the game is and what they will have to learn in order to play.

[h3]Control[/h3]
Combining dice with a city builder is a statement of intent, that cities are not perfectly ordered creations that immediately respond to one person's whims and desires. The scant few cities in the real world that were under that kind of control were usually only so for a short amount of time or within other constraints. For Amberspire I am not interested in those kinds of cities. I want the player to feel that while they do have a certain amount of control and input on their city, it will not be a complete.

Dice are one of the major components of this effect. For dice that come from buildings to produce resources, the game is telling the player 'you will never be able to perfectly predict what this building will do'. Despite the extreme level of abstraction in ideas like buildings and resources, the dice represent some real-world messiness.

Other portions of the game using dice and randomness are aligned in this. My goal for the player is while they can control a lot in their city, what isn't in their control begins to create something weird and unique that otherwise would not happen. For example: why is this specific area of the city so under-populated, or beset by competing rust blooms and floodplains, or weirdly cut off from the rest? Through a series of your decisions and dice outcomes that pushed residents, buildings, and terrain into that configuration. You will have a sense of your own city's history grounded by both your decisions and environmental forces.

As you play the game and the city expands, those small decisions and outcomes pile up into a city with a history beneath it.

[h3]Design Resolution[/h3]
A city builder could have a limitless amount of detail and complexity. I’ve talked before about the resolution of a simulation, and for me dice are perfect way to put a hard limit on that resolution or complexity. When I say ‘a building rolls a die to produce a resource’, the die producing a random result encapsulates a lot of what a very detailed simulation accomplishes.

For example, a Kiln building might produce a Brick, Earth, or Salt resource when its die is rolled. All the player needs to know is one of those resources got produced, and then decide what to do with it. A complex simulation might have to know how many workers are at the Kiln, what input materials it has, the temperature of the fires, the disposition of the workers, and so on. This is not a judgement on complex games (which I love dearly), simply stating that every game has to draw a line somewhere and I’ve drawn the line for Amberspire to exclude all of those details.

My goal is for the player to focus less on the individual buildings and more on the city as a whole.

I'll have much more to say on dice in future design dairies of course, but this encapsulates where I started with the general ideas of how dice could shape a city building game.

This is the first Amberspire design diary! I'll be posting these roughly every few weeks, going into the backstory, design, and production of the game.

As production on The Banished Vault came to a close, I knew I wanted to make a city builder. I also knew I wanted more dice. Dice are fun to work with and I felt would be a good way to immediately add a lot of interest and variety into a city builder. How exactly that would work was not immediately apparent, however. My goals were not to just make a city builder with dice attached to it, but to think about a city builder in a larger context. Dice produce random outcomes, and how would that affect how you played, or how your city was created? A city also does not grow in a vacuum so I knew I wanted some kind of interaction with the environment, and dice would play a role here. Likewise any other ideas that would present themselves in the future.

In The Banished Vault dice represent one element, your character's faith and their ability to overcome hazards. In Amberspire, what a dice represents changes depending its context. This broad but vague starting point meant working through a lot of different ideas for how they would work.

[h3]What Are Dice[/h3]
My starting point was ‘every building rolls a die’. This leads to an obvious question: what are the faces of the die? They could be resources, or whole new buildings, or different kinds of ‘labor’ (also just a resource in a sense).

More questions: When players roll dice, do they roll every die their city can produce? Depending on the scale of the city this could be fine or so large to be meaningless. I wanted the player to build a large city, but conversely a small set of dice to be rolled, so that each roll and its outcome can be followed by the player.

And more: once a player rolls, can they use everything they rolled? If so, rolling dice might feel perfunctory; if not it might feel punishing. The middle ground here is extremely hard to find, less like finding the solution to one problem but a system that will cover every possible outcome, and remain engaging!

[h3]Tensions[/h3]
I describe this as a tension put upon the player, which is simply giving them mutually exclusive goals or desires. A simple tension for a dice game: it should be appealing to both roll greater or fewer amounts of dice. For the player there's no right answer, just a best guess given their game and personality. Another potential tension: using as many resources as you can while also being efficient and pursuing one goal more directly.

A quick tour of some early ideas that didn’t pan out: dice have a 'quality’ based in a building’s 'morale'; unspent resources affect some kind of fatigue value; dice create groups of ‘labor’ that are combined with resources, etc. At the start of preproduction I didn't know exactly which ideas would work, but these did not express the game I had in mind.

[h3]Every Building Rolls A Die[/h3]
The final version, as the game works now: each building has a die, and each face of that die produces a resource. Resources are used to construct and operate buildings. Some of the die results add a die to the weather roll, which happens every three times you roll a group of dice as the player.

I’ll elaborate on the nuances of this system in a future design diary, but it would end up satisfying the needs of tension, pacing, and approachability. As a pitch, it remains simple: each building rolls a die for resources, and you don’t know what resources you’ll have to build with.