Lunar Division · Bithell Games
Fixed supply line displays for buildings affected by the Shipyard. Fixed a hang when opening the rulebook while holding a die. Allowed a left mouse click interaction on the dice tray to release a held die. Thanks for playing Amberspire!
Thanks for playing Amberspire!
Corrected the swapped tooltips of influence and residents. Fixed the interaction between Shipyard and certain terrain buildings. Thanks for playing Amberspire!
Thanks for playing Amberspire!
The key thing to know about Amberspire is that it isn't a city-builder in the SimCity sense, but a turn-based boardgame puzzler in which you don't so much 'build' a city as you do manage a tumult of unpredictable, city-flavoured agencies. Created by Lunar Division, developers of
The key thing to know about Amberspire is that it isn't a city-builder in the SimCity sense, but a turn-based boardgame puzzler in which you don't so much 'build' a city as you do manage a tumult of unpredictable, city-flavoured agencies. Created by Lunar Division, developers of The Banished Vault, it takes place on the surface of a moon-sized mausoleum - a vast Venetian graveworld whose fractured isometric crust reveals level after level of archways and catacombs, sinking beyond sight.
The all-pervading presence of the crypt reminds me of London's old church cemeteries, crushed like dandelions between mishappen skyscrapers, refusing to be written out of the tale. It also immediately undercuts your primary objective of building a city populous and advanced enough to win recognition from other planets. However high your towers rise, your city is just another layer of debris and pollution applied to a strangely fruitful necropolis. This isn't a lesson in humility. It's an invitation to enjoy city-building as the act of dancing with a deathly ecology.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
Today's design diary is written by the other writer on the game: historian, academic, and game developer Holly Nielsen. Holly was brought on to the game to bring a historian's eye to the writing and worldbuilding, but in a way to make sure things stay believably vague and contradictory, and in my biased opinion you're in for a treat.
Hello! I’m Holly Nielsen, a historian, writer and narrative designer. I’m lucky enough to be working on Amberspire, and Nic has kindly offered this space to let me discuss our approach to narrative..
Being a historian shapes the way I approach narrative and worldbuilding for games in numerous ways, far too many for one post. So for this piece I am limiting myself to talk about one particular aspect- macrohistory and microhistory and the interaction between the two. Macro are the large scale and long term aspects: the big events, wars, eras, the exceptional moments with far reaching consequences, etc. While the micro are the smaller scale: intricacies of everyday life, a community, an individual, a building. Both of these are interesting in their own ways, but it’s where they interact that I often find the most potential for storytelling.
An example of how the macro relates to the micro in Amberspire is the mausoleum. As Nic examined in an earlier post, the city you build is on top of a giant mausoleum where the ground can crumble revealing the dark arched chasm beneath. At first it felt intimidating to try and place something that seems so terrifying in the everyday lives of those in a city. But quickly I realised that we do it every single day, and that people are very adaptable to living with a constant potential threat. A combination of going back to the early inspiration of Venice, and also a trip to Isle of Wight and seeing a pub I visited now tumbling into the sea, made me look to the ocean and water more generally. Large bodies of water are both something that sustains life and also can threaten it. We are constantly trying to fight erosion, and even the most impressive structures can fall to it. This also gives an excellent reason for why if a building is abandoned it potentially will collapse into the mausoleum- because to keep the ground from crumbling requires constant upkeep- just as Venice does against the water.
Inspired by this, a note on how the mausoleum is generally perceived and understood was added to worldbuilding documents. The mausoleum: “people relate to it similarly to how societies have thought of the sea- it's both potentially dangerous, and therefore scary, but also provides resources and therefore gives/enables life, it's beautiful but also horrifying, it can be awe inspiring but also is the backdrop to everyday life, it's also a potential encroaching threat, one that is unstoppable. So it is common and known, but also its depths and true nature are unknown.”
The contradictions offered by the mausoleum felt incredibly grounding. It also led to questions around if residents would gain anything from the mausoleum, as societies and communities do from the sea. This led to a particularly fun message to send to Nic asking if the mausoleum had a fish equivalent. The practical considerations are important to consider when untangling the more ephemeral issues such as perception and emotion. This is an aspect I personally think makes for great worldbuilding documents- not just saying what is in the world, but saying how those things are perceived and felt.
It also leans into an area of academic research I find particularly interesting; environmental and geographical histories. I’m perhaps biased as she was one of my PhD supervisors but the work of historical geographer Professor Veronica della Dora, especially her work on mountains and their role in culture, was a large inspiration. This area of research feels particularly relevant to Amberspire considering how much of the game is about environment, ecology and interaction; allowing the player to reflect on their interaction with the landscape as well as with the city they’ve built. It was also an excellent excuse to spend some more time in an area of research that personally interests me. Always a bonus.
Building off this then allowed me to understand how the micro and macro relate in this instance. The macro is that the moon you develop your city on was built as a giant mausoleum. It looms large both in size, culturally and socially, and in the game’s own mythology. In Amberspire, the micro is largely explored in events. Here are some examples of event outlines with a brief explainer as to what they highlight.
A resident falls into the mausoleum after believing they could see a glint of the entombed sovereign’s armor in the darkness below - this shows that the mausoleum is something that can be seen by some as potentially holding immediate material opportunity on an individual level, while also holding potential “answers” to historical and spiritual questions. The exact motivation and intention of the resident is left ambiguous and up to the player to interpret.
A faction’s underling uncovering an item of disputed provenance while gathering resources - displays a wider interest in the mausoleum by this faction, that interpretations of the mausoleum are disputed, and also gives insight into faction structure and power dynamics.
A community unwilling to vacate when the ground shows signs of weakness, believing they can hold it together - tells the player that physical interactions (and how to deal) with the mausoleum are not homogenous, and although losing structures is commonplace does not necessarily lessen the emotion of communities and individuals to the loss.
My historical background also informs how I interpret these. As a thought experiment I like to imagine that I am an in-world historian, and if I came across these events in the archive and treated them as microhistory studies- what would they tell me about the culture/society/environment/politics. These are the smaller moments that give life to the city. The macro informs the micro, and the micro reveals more about- and gives meaning to- the macro.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
From a design perspective, the factions and events form the third major element of the game, alongside the dice and the environment. The goal is to create a narrative quality to the game and city that is missing from the other two parts.
The dice and environment provide a large and detailed systemic representation of the city. There's many little stories that come out of them, but they represent the city and environment as a series of processes with relatively fixed inputs and outputs.
The factions and events represent the people, communities, and ideologies in the world, and they are weird! The events are meant to depict what the systems can't - strange occurrences, people being goofy or aggressive or helpful. The events also describe much of what happens beyond the city, in other settlements in the solar system and in systems beyond. This layer is something that narratively you are aware of as you control the city, but do not have direct control of.
Designing the event system was tricky, and a lot of ideas came and went. I wanted to keep events and factions simple so that the focus remained on the city building, and so that it did not feel like the factions were playing a game without the player. A typical 4X or strategy game has the player and AI on (roughly) equal footing mechanically to simulate the idea that everyone is at the same table playing the game, which was not the goal here.
Skipping over the dozen discarded ideas, the factions came down to being represented by two values: strength and disposition. If a faction is strong enough and has a disposition towards you, a mechanical effect is applied to the entire city at once. These can be positive or negative, but greatly alter the various rules of the game like weather, terrain, dice, and more. Events are now closely tied with factions and change strength or disposition of that faction, or others.
The ultimate benefit of the simplicity of this system is communicating it to the player. To take a discarded idea of factions owning buildings and the you interacting with them: how is the state of the building's owner communicated to the player? Floating icons, art tinting, custom art, all have pros and cons that for the moment ruled out these ideas.
So factions have strength and disposition, events tell little stories to adjust those values and affect the game elsewhere. A few different ideas on how to incorporate dice came and went, with the resulting idea feeling very obvious in retrospect. If you can afford to you can choose to pay influence to select an event option, otherwise a die is rolled.
A few other options here were interesting, like a special faction die to choose a type of event, or the player paying to change the faces of die to better guarantee the outcome they wanted. Ultimately simplicity won out, similar for reasons above.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
Factions are the last major component of Amberspire I've yet to go in detail in, until now! They are a vital component to the game, and the backbone of the event system.
In Amberspire you're fundamentally playing a dice game to build a city, but I wanted the overall experience to have narrative beats and events. These events are a light touch, and reflect things happening in your city and the solar system beyond.
The factions are special groups of people with political and material power in the world and are greatly affected by the events. They have special Favor and Penalty rules which can dramatically adjust the rules of the game, and these values are modified only through events.
An event is a special dice roll with outcomes, but you can spend influence to bypass the roll and choose one of the outcomes outright. In some cases this will be extremely advantageous, since events can roll multiple dice and result in multiple outcomes being chosen.
This overall sums up the events and factions. They are not the primary concern of the game, but more represent the world above and beyond what you can directly control. Just like how the city is built in a context of history and environment, so does the present provide a larger context with the various events happening around you. You can affect these and in turn are affected by them, but you cannot directly control factions or shape the direction of the entire solar system and the powers beyond it.
All this is to reinforce the ideas I've touched on in previous design diaries, that you as the player and the game together create this semi-random narrative of a city. Just like how terrain can influence the growth of areas in your city, factions providing favors and penalties add a certain texture to how the game plays and your city grows.
When factions favor you, everything comes easy. Dice go further, you have more rerolls, events are cheaper to manage. When factions turn away from you, the situation is flipped: everything is steeper and more costly. Naturally these mix together, and having a mixture of favor and penalties will create unique situations that will require creative solutions.
Further still, not every faction will be present in every game of Amberspire. On average you'll have two to four present at once. Below are all the factions in the game and a short description.
top: Chroan, Coral, Dais; bottom: Void, Gardeners, Frame, Lantern
art by Gryme
A secretive collective of archivists, librarians, and time travellers. In impregnable vaults they store the memories of millions of beings, in small vials that can later be consumed to view them once again.
Hidden away in the folds of deep space resides a magnificent colony of creatures, held together as one entity. Throughout known space it expands its influence with shards of itself known as courtiers.
A small military order united in their belief of a long dead god, and bound to a lifelong search for its fragments.
Clans of spacers, who take on courier, transport, and mercenary functions. Highly insular, they hold to a rigid familial structure that can be traced through several previous eras.
Wherever people go in the stars, their bodies must be adapted to the environment. Over the millennia, the Gardeners have perfected the art of genetic manipulation and organic restructuring, and they charge a high price for their services.
Travel through deep space is complex, perilous, and expensive. Frame are a small but extremely powerful organization, able to maintain the dimensional networks required through economic incentives and trade across solar systems.
In the deep cloud layers of Amber lives a society of sentient creatures, thin translucent membranes surrounding huge volumes of gases, floating among the clouds. Eras past, a colony of humans grew within one of these creatures, and later grew into Lantern. The symbiotic lifeforms care for Amber and the wider system.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
I wish city builders had more friction. I enjoy playing city builders tremendously, and as far as the extremely broad genre of management games go it is my favorite kind within that. But management games take on many forms, and unfortunately I think city builders are sometimes are not focused enough.
There's many reasons, and that's also not to say they are badly designed! The kinds of friction in these homeostatic management games are fun, and there are many experimentations with the form.
I want more friction from history in my city builders. I can understand why they don't typically have this: preventing players from correcting mistakes, or adjusting streets & services would require a radical alteration in the fundamental concept of a city builder. It's a short walk from city builder to Permit Petitioner 2025, and that's not fun (yet).
Still, I wish cities had a sense of history to them. Looking at a screenshot of a city in Cities Skylines or Sim City, I can appreciate the size and maybe guess that the middle-ish part was built first, but I don't get a sense of history. There are no annoyingly winding streets sprouting inconvenient dead ends, areas without transit access, regions rebuilt after a natural disaster, &c.
That said, in a typical city builder, the player is not constantly rebuilding the entire city to suit her goals in every moment. The player builds the city, it gets larger and larger, and the game continues.
Importantly, the player is given the tools to rebuild the city if desired. The primary cost (generally) is the time commitment required to do this from the player. I've written about player time as cost before, although I don't believe it is a factor here. The important aspect is that the player is given these tools to be able to adjust their city without a cost - removing buildings, destroying streets, rebuilding tunnels!, are all open to easy adjusting. This creates a small but persistent cycle of self correction, but without any entropy to that correction. The player builds their city, makes some mistakes or is introduced to new systems, and erases and improves small areas of their city continuously as they play. Without entropy however, there is no real long term penalty to doing this, only upside. Cities do this in real life all the time, but the costs are enormous and fiercely contested over years and decades. My desire (and goal for Amberspire) is for city builders to somehow incorporate long term tradeoffs to the goal of improvement.
These tradeoffs can be anything! For better and worse, one of the most engaging elements of a city is the inertia of real world physics, bureaucracy, and the people living there. Hong Kong is bound to its island, Florence has no highrises, Baghdad bears thousands of years of history. These are lofty ideals for any game, including Amberspire, to reach. But I wish while playing city builders I could feel the weight of my own previous actions reflected in the character of the city.
I wanted to capture this feeling in the game, but how exactly was extremely elusive. My end goal was clear: I wanted the player, while showing their city to another person, explain the various decisions and processes that led to the current layout. And not just “this area is where I put all these buildings and laid out the streets in this manner” but more more multivariable: “here’s this section of the city, because some buildings got removed it hasn’t been able to to fully regrow into the new space, and the floodplains are a problem so the resident population is sparser than I’d like.”
The combination of the player’s decisions and the game’s random processes, in my view, is what would characterize a truly interesting neighborhood of a city. No city in the real world is under complete control of one person or process, insulated from nature and politics.
I am wary of being lost down a very deep rabbit hole here with feeding so many inputs into a system that the output becomes oatmeal. The terrain system discussed in a previous design diary gives the feeling of weather impacting the city and topography, so really what I was looking for was a lingering effect of the player’s decisions. Most importantly, I wanted players to look at different areas of their city and have a visual and mechanical representation of the age of that part of the city.
A few fun ideas came about to reflect this: the moon the player is building a city on is in fact a giant mausoleum, mostly hollow. And the other is punching holes into the ground.
The game in fact starts you near a large spire, a chasm into the darkness. You can’t build into the open space, but are otherwise free to build and remove buildings elsewhere on the landscape. When a building is removed however, either voluntarily or through other means, a small hole is created in the surface. That hole can spread, creating larger holes or even joining with the original spire.
My intent is not to punish the player or make their lives difficult, but to reflect their decisions into the landscape. Removing buildings will begin to limit how many new buildings can take their place. Aggressive terrain destroying your buildings damages the landscape. After a long enough time you’ll be able to look at your city and see the history crowding the present.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
The past several design diaries have been a tour of all the big ideas in the game. Once those start to feel mostly right, the next step is to flesh all of it out. Frequently in this phase you invalidate some of those ideas or find better versions, so it's an important step in the process. Often the game will feel suddenly much closer to being complete, even with a lot more to do.
I started with resources and buildings, which is naturally a very circular pair of ideas. What were the actual resources the game concerns the player with? That depended on the buildings in the game and what they produced, which asks what buildings naturally arise out of those resources. It feels like hand carving a sphere out of a larger sphere - doable, very iterative, and you have a lumpen mistake for the majority of the time.
My overall guideline for the resources is they should move away from material goods pretty quickly and smoothly transition into abstract concepts. Things like brick, metal, and energy are important concepts for a city builder to have, but I wanted them to feel like a small segment in the kaleidoscope of things cities could 'make'. Cities are not just buildings and streets, they are what people do in the negative spaces.
It’s at this point I settled on ideas like glow, horizon, insight, and ritual. These are resources that can be produced and manipulated by the player just like brick or metal, they don’t necessarily have a fixed definition. How the game produces and consumes them gives clues to how I conceive of them, but there’s more than enough room for players to bring their own interpretations. The goal is also not to represent every possible concept as a resource from a building. The game takes a certain point of view within the fictional world of Amberspire as to what this city can produce, and for example influence is a broader idea that is not a distinct item coming out of one building.
So figuring the buildings and resources was a tandem process. The buildings should represent the wide variety of things people might do in a city, but like any game there has to be limitations, so there are some omissions that might be restored later. Buildings are more concrete than the resources, but the pairings do a lot to describe what happens there. An Amphitheater produces music, gathering, and starlight; the Salon produces intrigue, shadow, and ash. The Temple can provide influence in exchange for ritual, music, ash, and shadow.
More buildings: Library, Garden, Salon, Creche, Necropolis, Palace, Chapel, Hideout, Scrapyard; all are dice rolling buildings that produce resources. Temple, Fort, Arena, and the Bazaar provide influence for resources.
Beyond which resources buildings can exchange for influence, how many resources should a building be able to trade for influence? Actually, how many resources should there be altogether?
In various design diaries I've talked about 'scaffold' designs, simplistic rules and mechanisms that do a functional job moving inputs and outputs around for the player while other ideas are being worked on. This is the moment that the earliest scaffolds start to come down. To explain a bit more: the game has been designed with a vague sketch that there will be 'a lot of resources' produced by 'a lot of buildings', and used for 'a currency-like number', and so on. Ideas like dice rolling can be worked on knowing that the resources will be used somehow. Then the later ideas are developed, knowing that there will be lots of resources produced by dice.
Now the process is to actually define all those buildings and resources. In this first step, I just wrote down all the unique and interesting resources I could think of, and which came to a list of about 36 ideas. Coincidentally, the number of buildings was about the same, though neither of these are final yet.
Because this process is so circular, this first number is sort of a shot in the dark. It might be too high or too low, but the carnival ride is spinning and you just have to pick a spot to hop on. Testing and iteration will lead you to the ideal spot eventually. Reading this you might also compare it to other city builders and think that's not all that much, but there is a key element to Amberspire: no building is a straight upgrade to any other building. Each one is unique in its output, construction, and utility; once you reach the final tier and unlock every building, all of them have their uses. This creates a huge variety in strategy, and in this case there might be too many buildings.
That's it for now! This is just the first impulse on a long and iterative process that is extending into today, so there's plenty to come on this front.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
Alongside working on the art style of the game was figuring out how to render buildings so they would sort correctly and maintain performance with hundreds of buildings and layers on screen.
The first step is establishing some constraints. The first and biggest was a building always had a square footprint on the grid. This simplified many things, and left height open for art to establish unique silhouettes. Without any patterns or convexity to worry about, the game could have buildings of varying size and ease my headaches on rendering.
Varying size is a key detail here, because while we wanted to evoke a classic city builder feel of sprites and a grid, having all buildings be one or two grid spaces wide would deflate a lot of potential in depicting a science fantasy city. Most other constraints followed with standardized sizes of grid spaces, doors and windows, and opacity (more on that below).
For a feature that I was not able to implement and am going to keep secret in case I can figure it out, I wanted every building to have a kind of awareness of how much space it took up in the world. This necessitates slicing up the building image into various parts so they can be rendered at different depths. While the ultimate goal was never quite reached, it did ensure a very reliable method to sort buildings on the grid.
Typically in an isometric game, sprites are sorted by how close they are to the camera, which typically means how close they are to the bottom of the screen. This is only the starting point however, since buildings of different sizes might be positioned lower on the screen but will require to be behind other parts of buildings.
Further complicating matters is height. A tall building needs to reach over other buildings, even in edge cases like when it is off screen. But not all of the building is at the same height, so you’ll have to factor in which parts of the building are on the ground and which are high up.
Each ground tile in the game is one slice, a sprite of width and length but no height. A building that is 1x1x1 (Residents and terrain tiles) has two slices – not quite the ‘ground’ exactly but the bottom and the top. A 2x2x1 building (the smallest of the kind the player can build) has five slices - a top and bottom, and four slices to cover the full width and breadth. These do overlap, but for technical reasons it will make sense. It does add a subtle constraint to the art: it can only display full on or off opacity, no transparency.
On screen is a static field of grid spaces that never moves. A camera points at them, which also doesn’t move. Each space holds a position for a sprite, and when the view of the game moves, all the spaces update which sprite is being displayed, giving the illusion of movement.
Each building slice corresponds to one of these grid spaces. Our 1x1x1 building occupies its position and the space above it, and the 2x2x1 building spreads out on the grid occupying some of the left and right offset spaces.
Of course, each building has some height to it. A 1x1 building occupies the sprite behind it, but in that grid position could occupy another building, so the top sprite of the front building needs to be offset so the behind building can draw behind it.
This gets more complex for 2x1 buildings, as you can see here:
0.75f,
0.75f, 0.75f,
0.00f, 0.00f,
0.00f,
the bottom three sprites do not get an offset since they are ‘on the ground’ and the top three sprites are ‘higher up’ and so get some height offset. Note here that height offset in a 2D isometric game corresponds to vertical position and forward offset together, like any other isometric game.
You can see the progression on a 2x2 building
1.50f,
1.50f, 1.50f,
0.75f, 0.75f,
0.00f, 0.00f,
0.00f,
as the building gets taller. At first I tried to figure out some algorithmic way to derive these values, for every width and step of height, each part would get some offset. This turned out to be a silly waste of time, since with my constraints there were only a few possible building shapes across the whole game. Given the various sizes of building there are only eight patterns in the game (not counting simple 1x0 and 1x1) so it was way easier to just define these offsets myself to make sure the sorting worked instead of finding some all purpose algorithm.
This became especially useful once I realized how weird things get for large and tall patterns like 4x2:
1.50f,
1.75f, 1.50f, 1.50f, 1.75f,
1.50f, 1.50f, 1.50f, 1.50f,
0.75f, 0.75f, 0.75f, 0.75f,
0.00f, 0.75f, 0.75f, 0.00f,
-.25f, 0.00f, 0.00f, -.25f,
0.00f,
I can’t now remember why those negative values are necessary, but they are!
A few remaining details are the ground and street layers, which use a mix of wave function collapse and 9-sliced tiling to draw correct shapes and patterns; and the moon structure tiles which are alternating patterns of left and right halves of the arches to give a sense of scale to the space beneath the city.
Anyway, that’s how the Amberspire rendering works! A bit overkill but once I got it figured out it hasn’t given me any problems since.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
It was initially difficult for me to define what I wanted Amberspire to look like. Science fantasy encompasses so much, it’s hard to clearly define what is right for your setting – Star Wars, Book of the New Sun, Viriconium – all are validly described as science fantasy. It's partially useful to describe what you don't want, but you need to define positive aspects to really go far.
My initial thinking started off with the world and city should feel like a science fantasy Venice. Not a literal Venice in space, but as a reference for various ideas: architecture, density, and the overall character of the city both literally and culturally. And further, Venice in the pre-renaissance, early medieval period - more on that below.
This was led by technical concerns for the visual identity of the game. I knew it wouldn’t have cars or car-equivalent vehicles moving around the city, and I also wanted the city to be large. Even buildings bounded by streets are not a necessity, many buildings are clumped together and the player can imagine residents moving between them without a direct depiction. I saw the city in the game and Venice as naturally sharing similar qualities, so I wanted the layout to reflect that. The city is also built on an artificial moon constructed as a mausoleum, and as you play the game more of the moon’s substructure is revealed. This constrains how you play the game, and also shapes your city into something unique.
The city of Amberspire should also feel old, built over layers of history, and have a somewhat fated quality to it. Even though the player builds the city in a mechanical sense, I still wanted it to feel old. Metaphorically, the game is also asking if the player is building a city or telling a story about the city from a remove?
This process really forced me to consider the science fantasy of the game from a different angle, from the inside out. How does it feel to be a person in this world? What does their day to day life look like, how is food prepared, children cared for, material needs met; how is social, political, and economic life organized? Through this period we also worked with the concept artists Simon Krieg and Rob Turpin, which helped push these ideas forward in my head and solidify our direction.
In some ways I’ve used the Medieval period of Venetian, Byzantine, and Persian history to reflect the outlook of the world in Amberspire. How does one person, or city-state, fit into a larger community of people and nations? Despite the huge advancement in scientific understanding, what remains unknown about the planet and cosmos? I won’t answer all these questions I asked myelf here, because the game answers them as much as I want it to.
All of these come together to develop the art style of the game. YueTong Tsenis the incredibly talented artist who conceptualized and drew all of the buildings in the game, and was a joy to work with. While I had a lot of ideas in my head, her realization of how buildings are shaped speaks to how the people in the world interact with them.
Eventually the style consisted of these ideas, with some rules occasionally broken:
A hand drawn outline of consistent weight, both to impart a rough and old feel to the buildings and reinforce that they are 2D images.
A generally warm color palette for the city, and cool for the surrounding moon.
Lots of gradients, but no shadows. Because the game is in 2D, it would be impossible for buildings to cast shadows on each other, so they don't cast any at all (minus one key exception of a floating building). Gradients are heavily used to ground buildings and give some color and value variation.
A future blog post will go into detail on the game's visualization of people and props, but initially the buildings were drawn with the expectation that no people would be visible. This meant generally obscuring and simplifying doors and paths, to not draw attention to this detail. The game does show people, but this was done after this direction was established.
The game doesn't let you rotate your view, so each building has a strong silhouette to distinguish itself from other buildings.
Most buildings do not take up their full footprint, allowing the streets or other buildings to abut them more naturally and feel less grid-like.
The art style is a result of all this thinking, our preferences and quirks, and Yue's rendering style all working together. Aside from the color palette of the city skewing warm and vibrant, and a rough inspiration of Venetian/Mediterranean architecture, we didn't start with any specifically hard and fast aesthetic rules. The result is the product of iteration and vibes, and better reflects the game's flavor of science fantasy: expansive, bright, and unusual. A warm day at a rocky beach, bioluminescent algae visible beneath the slow waves, a planet low on the horizon.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
The path to solving these issues started with a new question I hadn’t previously considered and that the game wasn’t answering clearly: are dice and their resources representing constraints on the players actions, or progress to specific goals the player has?
At first this sounds like a distinction without a difference, but it was illuminating to try to find an answer. Amberspire doesn’t have a concrete set of 'actions’ that you choose, but of course every game has a set of actions no matter how fluid or obfuscated they might be. Considering those actions the resources available to the player after a given roll could be seen as constraints on what actions the player could take - if they roll XYZ resources then they can perform XYZ actions.
While this is a common pattern in boardgames, where a lot of interesting tactical/strategic noise can be generated like this, it’s less common in videogames. It’s possible to constrain the player heavily this way, but the entirety of the game needs to be very focused on accommodating this pattern, and as it stood the design wasn’t supporting that. As a quick example to illustrate what I mean, a roll of the dice could give the players hammers to build with, or money to go to the market, etc.
So it made more sense here to say that resources are a measure of progressto a player’s goal. The player could generally take any of the actions the game offered, and the resources rolled on the dice offered different ways or speeds to achieve those goals. Almost instantly this made me realize what the problem with the original system was!
At this point in the design, constructing a building involved providing a precise set of resources to that building. So for example a Furnace would require two metal and two brick. Once all the resources are provided, the building is constructed. Metal and brick are available from other buildings, and so you’d roll those dice and provide the resource.
Take a step back and analyze this system in a very formal or abstract sense: by measuring progress to a goal, the only results of a die roll are either +0 to your goal or +1. My goal is to get metal and brick for my building; I roll a die that can produce metal and scrap; if I roll scrap, that roll effectively was ‘+0’ to my goal of ‘getting metal to construct the Furnace’. If I do get the metal result from the roll, the roll is worth ‘+1’ to my goal. Great! Is that not absolutely terrible?
This is precisely why the dice rolling had this nebulously bad feeling I described in the previous design diary. Whether dice had a small or large variety of results, whether building recipes required few or many resources, or if the player had many distractions to their goal – none of that mattered. What mattered was a die result was either standing still or taking small incremental steps forward, and both feel pretty bad!
With the problem now clearly defined, the solution is quite straightforward: imbue the resource results with varying value to the player. A building now requires 6 ‘points’ to be constructed, and a Furnace values brick as 3 and dust as 2.
Rolling a die result now has a pleasing variability to it. If my goals is to build a Bazaar, daylight counts for 3, canvas for 2, dye is 1. When I roll the dice that have these resources, a single daylight gives me three of the six points I need to construct it, while a dye only moves me a little bit towards that goal. The dye likely has a much higher value somewhere else in my city, as opposed to just ‘+1 somewhere else’ in the old system.
At long last (now only two months into full production, about January 2024) the dice system seemed to be producing the right effect for the player in regards to generating resources and giving the player a nice decision space even with only a few goals.
What remained was a slightly more straightforward problem that is best described with this question: why should the player desire to both roll more and fewer dice? Basically I want the dice system to have a simple risk and reward for rolling more dice, so that there is no fundamentally right answer of how many dice to roll in a given situation.
Creating a system with these opposing drives is vitally important for strategy games, and arguably is at the heart of every strategy game ever made. You have to decide where to deploy your troops, how to spend your resources, to prioritize attack or defence, etc. It’s not as often you see these pitted in the exact same system but it’s sometimes necessary. My favorite example is probably Reiner Knizia’s High Society, a very simple game of bidding on items with various numerical values. At the end of the game the player with the highest value of items wins, but only after the player with the least amount of money is eliminated from the game. So you have to spend money buy items to win, but the more you spend the closer you are to losing. In my view it is an ingenious design.
If these tradeoffs aren’t present, entire systems or the game itself starts to feel meaningless. The right option becomes apparent quickly and the game devolves into simply executing the same strategy as everyone else. Fundamentally a game needs some kind of mystery in which strategy to employ so that players can be variably successful or not. Without a penalty for spending all your money in High Society, there really is no game to play.
Amberspire doesn't have money as such, a quick end state, or other players even, so creating this risk and reward can be tricky. The reward for rolling a lot of die is straightforward, in that you get a lot of resources to play the game with. The risk has to be carefully balanced so it's not outweighing that reward, but is still present in the player's mind.
Since I had a decent idea of how the terrain might work, it made a natural first step to tie the terrain as the risk factor to rolling dice. Narratively, the dice are buildings and residents doing things in your city, and them doing things in turn affects the environment.
How exactly to link these mechanically was initially quite difficult. Should activating the terrain be a roll result on a building die? This might work, but would cut into the resources being produced, and it would be restoring those annoying ‘+0’ results I just spent so long trying to identify and strip out. Likewise, pairing terrain-activating results with resources produced violated my arbitrary ‘one resource per dice result’ constraint. The atomization process continued with many different alternatives explored.
Many of these ideas did not tap into push-your-luck patterns either. If I roll so many dice, you are likely to get a fixed amount of terrain activation results, following a pretty standard bell curve. A push your luck system ideally has an upward curve, the more I risk the higher and faster the penalties are.
At this point the atomization process started to run aground. I couldn’t quite identify the problem nor think of solutions that felt exciting. So I turned to a tried and true method: rubber ducking. Enlisting the help of friends and coworkers I just rambled about all the problems and ideas I had tried that didn't work. Along the way, a detail jumped out at me: everyone asked “does Amberspire have a concept of time passing?” My response was “no, but not for any particular reason” and the discussion would move on.
That did get me to thinking, well if everyone is asking this, maybe the game should have it? It’s a common design pattern in city/simulation games, but the only reason I didn’t have it is I just didn't have a good reason to add it in yet – until now.
The resulting ideas fell together very quickly, and in hindsight seems perfectly obvious. In Amberspire, time is measured in cycles, split up into phases. Each phase is rolling a group of dice of any amount. It stands to reason that after a number of rolls, something has to happen, and in this case it felt obvious that the world should have a turn to activate the terrain tiles. The terrain phase uses its own dice, which also make sense to be weather dice. This gives them a strong identity and doesn't collide with the building dice that produce resources. Lastly, how many terrain dice are rolled during the world phase? Well that could be easy - some results of a building die add a die to the next weather roll.
It seems like almost too subtle a reorganization of the inputs and outputs of these elements, but suddenly everything worked great. The player wants to roll more dice in one pool per phase, but the larger the pool the more terrain dice they are likely to accrue for the next weather roll. And while the average amount of terrain activations is about the same as any other method, grouping them together in one big lump is nicely dramatic for the player.
It also prevents you from making any adjustments to the terrain in between the previously smaller effects, if you have a big pool of weather dice you have to deal with huge changes to the environment. The accelerating risk comes in that amount a terrain can change or damage your city in one big pool is many times more unpredictable than a smaller pool.
The last few bonuses to this system also can’t be ignored: the original “get penalized if you don’t place a resource” idea is fully dead, and for the better. And now building dice have a second axis of probability, which is a simple series of yes/no on the dice faces as to whether they add terrain dice in the world phase. This, separately from the resources provided by a building, add some lovely theme and design texture. In the best sign of things, I actually found myself playing and enjoying the game, which is a rare treat.
This wraps up part 2 of this dice design series, but part won't actually come for a while. That will sum up the rest of the work on the dice design over the rest of the game, some of which is still in flux. Thank you for reading!
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
Up until now in these design diaries I have only loosely described how the resources and dice work, but not in full detail. That's because, simply put, up until this moment (in the design process, not when you're reading this) it wasn't particularly good, and this only became clearer once the game had other things going on.
I had initially designed the dice system to function with a simple tradeoff to provide friction for the player: you can roll as many dice as you want, but any resources you don't use add to a Fatigue value, which incurred some penalty and involved some other process to reduce. Buildings required a specific recipe of resources to construct them. This loop is what the core of Amberspire was at a fundamental level.
As a sidebar, the vagueness of 'Fatigue' in the paragraph above is not me editing this diary down to stay focused on the dice and resources, this is how I think about system design. In somewhat algebraic way, you can declare a system like an undefined variable to figure out later. Obviously the clearer your ideas are the better, but sometimes you have to focus on one thing and keep the rest as a loose sketch. I typically sketch by defining inputs and outputs, so this system adds Fatigue and then at some point Fatigue is removed. A system has to be strong enough to justify establishing a Fatigue system, which can ideally tie in to other systems as well. All this is done purely on paper.
Pretty quickly this system just felt bad. The goals were achieved, in that it provided an incentive for players not to roll every die they could because the Fatigue penalty would be high. But even in 'reasonable' play, trying to hedge which die would be used was not interesting. It just felt too penalizing. More often than not I would assemble a handful of dice, roll them, use what resources I could to build new buildings with, and proceed without much excitement. Sometimes I got the resources I needed and sometimes I didn’t, but neither way did the game feel like it was engaging me and drawing me into making meaningful decisions.
So I began a process that I’ve done somewhat automatically for every game I've designed, but did very deliberately for The Banished Vault and will do very intently in the future. This process I call design atomization, and is essentially ripping apart every portion of the design at the every seam, following it through from start to end, and hopefully looking for the source of a very vague issue.
The rough procedure I use for the atomization process is to examine every element of the game, write out how it works, and alternatives to how it could work. This kind of abstract ‘wiggling’ is helpful to explore alternatives to the current design elements, but also discover what things I want to keep fixed in place and what is open for change. For example, I feel pretty strongly that each building can only roll one die at a time, not several, and that I want each face of the dice to have only one resource on it, not several. These two elements could be different, but they were constraints that I had other reasons for and wanted to keep in place. Another new constraint, emerging from the initial design that felt bad, is that not using a rolled die incurs no penalty.
A specific example, considering the dice and resources: at a basic level, buildings would roll dice to produce resources, and the player would then use to construct more buildings. Sometimes it would feel like when rolling a die and not getting the resource you want, the game simply shrugged and said “well, roll again”. This outcome is to some degree inevitable, but it should be very rare. My goal was a very fine balance between the game providing a few options for how to use a resource or occasionally none at all; also a gentle encouragement to not roll the maximum amount each turn.
A question on my atomization process that highlights my process and how tricky it is to find a solution: generally how many different resources should be on a die?
The first step is exploring a low amount, down to 2 or 3 resources per die. But this just felt wrong in that intangible way – if every building produces only 2 or 3 things, why even roll dice? The point of dice is to have lots of variety and drama in the result, not just flipping a coin. So, following the atomization process, I consider the alternative: how would it feel if every dice had lots of variety, 5 or 6 results? More dramatic and unpredictable, sure, but the problem of ‘not getting a usable result’ is now worsened. If a 50% chance to get what you want feels bad, 16% is pretty miserable.
Perhaps the issue was in the number of destinations for resources, or stuff the player can do with a result of a roll. A frequent issue with designing strategy games is they don’t fully click together until the player has enough plates to spin, so it’s hard to judge if a design is right when the player can easily spin one plate without distractions.
I did have other systems that I wanted players to commit resources to, like gaining influence, or upgrading buildings, and managing the algorithmic terrain. These are interesting, but I did not want to rely on them to patch over a fundamentally weak design at the center. The key here is that no matter how many different systems the game might present to the player, ultimately there’s nothing to stop them focusing on just constructing buildings. Put the other way around, the game should be inherently interesting even if the player is focused on constructing exactly one building at a time. I believe this is also a good heuristic for the perceived difficulty of the game, if the player can comfortably ignore everything else and focus on understanding (and being engaged by) the core system, the game will feel easier.
As a treat for reading this far, here is very early screenshot of the game, at about the time I was doing this process.
So this atomization process continued. I compared and contrasted what I had with a city builder and a dice game, and experimented with bending this design to resemble those two games more to see what ideas might shake out.
The first model we’ll compare to the Anno games. I thought of a new model where once the player rolls dice the resources rolled are added to a global storage system of some kind. At any point the player could construct buildings if they had the required resources in storage and proceed forward. This made rolling dice at least feel like it was always moving something forward for the player, and not just leaving them with a null result with no value. At the logical conclusion of this path, however, was simply Anno again but with the dice fully removed. Even with infusing some kind of risk or push-your-luck element, the player is still just rolling until they get what they need without much nuance or specific goal.
The next game I thought about was Citizen Sleeper, a game that uses dice to great effect. I kept Citizen Sleeper in mind throughout this entire process, because I felt like it captured the feeling I wanted – immediately after the dice roll the player's mind is alive with the possibilities of what you can do with that roll. Whether the roll is great, or terrible, or a mix, you are engaged and thinking about what to do next. In comparison to my system where after rolling dice you rather automatically assigned the dice to where they should go and moved on.
To recast the design to the Citizen Sleeper system, I thought about the dice pool forgoing resources completely and just rolling numerical values. Buildings would then have operations they could perform, to a quality determined by the value on the die. On an immediate level this felt more interesting than what I had. Like Citizen Sleeper, the range of possibilities was great, and the player has a big set of options to proceed with.
Where it this falls apart however is in the details - for the player it’s hard to easily answer ‘how do I construct a building with two 3s and one 5’ as opposed to with ‘1 metal and 1 crystal’. Also I was quite attached to the resources, they greatly add to the overall theme and aesthetic of the game and I did not want to lose them. But at least as a design exercise, it was curious how much more engaging the game felt when I looked at it through this lens.
Eventually I did find an answer to these issues and am very happy with where the dice system is now, but this diary is already quite long! Next time I go very deep on formal questions like player constraints, goals, and mathematical progress in a system. This very clearly describes the problem and a solution, and will eventually lead to another solution to the dice penalty issue further beyond.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
City builders invoke friction for the player in various ways. Many have systemic values like happiness or pollution that, through the actions of the player and system, go up and down. The player needs to balance whatever goals they have with maintaining these values. Other common sources are geographic features and terrain, both elevation but also water features or natural resources.
This kind of friction was at the front of my mind at the early stages of Amberspire's design, simply because I wasn't exactly sure what I wanted to represent in the game. Put differently, the game didn’t really give the player a reason to place buildings in any specific location or otherwise engage with the 'building' part of the city. Up until this point I was focused on the dice rules primarily and overall technical aspects of getting the game functional.
Anyway, the design needed an active pressure on the player; a reason to build a building in one spot or another. My goals were for a system to do that, provide a little friction so the player had some decisions to make, and provide little seeds for a narrative they could tell about their city. This narrative was a key goal for me, as I wanted the city to feel like it had a history that the player could see come to life as they played.
The solution to these goals that I arrived at was an evolution of the auto-houses and cellular automata, which I started calling algorithmic terrain.
In Amberspire, the ecology and wildlife of the moon is represented with these terrain tiles, which take up space on the grid. They are giant blooms of rust, pockets of viscous floodplains, patches of silica grass, and dense fog. All together they represent the organic elements of the world that would respond to the player by growing, moving around, and generally operating on the map around the player’s city.
These are driven by weather dice, which cue the behaviors of the terrain tiles in the world by growing and spawning in specific patterns. The auto-houses are an expression of population for the city, the algorithmic terrain is an expression of the world around the city. It is a semi-random, ecological environment that sometimes is out of your way and sometimes disruptive.
They are not fully cellular automata driven, but closer to an [L-system]https://en.wikipedia.org/wiki/L-system). The game has stored patterns for how each terrain moves, and patterns are applied over existing terrain, so a balance is struck between random growth in predictable patterns. More exciting, when terrains touch one another, they 'explode' into large and unique patterns.
The terrain also tie together in how they are cued up by the game, in that providing resources to buildings can increase your population or reduce nearby terrain tiles. Instead of having more abstract systemic values the player has to balance, these are represented in the world, as population and ecology. How your city 'is doing' is visually apparent, and responding to problems to achieving goals is limited by the buildings and resources you have nearby. The game does not allow you to buy your way out of a situation, and the inertia of your past decisions is strongly felt.
This sounds hard and imposing, but it's not! The outcome of these situations is not failure, but an interesting history for a neighborhood in your city.
My goal is to make a citybuilder that places your city in an environment that is alive and not totally frozen in time I want your city in Amberspire to feel like a real city, shaped by people but also chance and the environment.
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not c
Note: these design diaries were originally published in spring/summer of 2025. The design, and definitely the screenshots, have changed a lot since then! I hope you'll find them an interesting look in the design and development process, and an insight into what does or does not change over the course of development. - nic
I've been playing and thinking about city builders for a long time, and along the way I realized I wanted to do my own spin on houses and population. This was partly born out of thinking about cellular automata, but also realizing that typically in city builders I am not engaged by placing houses or residential districts. Unless I am giving myself a very specific external motivation for doing so (a visual appeal or extra challenge) I'll just do the bare minimum the game requires and nothing more. In a sense, I'd like the population to be either something I think about a lot less or a lot more.
City builders use population as a kind of overall set of buckets for the systems the game is modeling: happiness, wealth, education etc, of which Amberspire does not have any. One reason for this is that the focus of the game is broader, the city in Amberspire can grow to be a massive metropolis, the interactions with the world around it are more political in nature, so we didn't want the design to be so complex as to track individual people. Another is that typically these systems heavy city builders are built on the assumptions of the 20th century, and typically in industrialized areas. Even with a displaced time period or location, I feel like the assumptions are still present. Which, in itself is neither here nor there, but I want Amberspire to feel like a science fantasy city builder, beyond just unusual names and architecture.
Given other production constraints, I did not have the capability to design and implement the ideas I had for how a city several millennia in our future might operate – though those ideas are present in the writing and art.
All that to say, I wanted the representation of labor, population, and people in Amberspire to be relatively simple, out of the player's control, and reinforce the science fantasy theme.
Initially I was very confounded with how to represent labor in Amberspire. A typical city builder will track workers or some kind of value within a building, and modulate the building's output based on skill or morale or whatever else the game is concerned with. Since the focus of Amberspire is not that fine-grained, and building output is already variable with dice, how to should the game represent labor?
Some ideas that didn't go anywhere, to start things off: dice themselves could change, with faces becoming blank or have some penalty modifier if rolled. Or when the resource is used in another building, its effectiveness is modified somehow.
These probably could have worked, but didn't feel right and clashed with other plans I had. I didn't want the dice themselves to be overloaded with complexity or be so variable that the player couldn't guarantee what the die would be – before it's even rolled! This kind of 'double uncertainty' can very quickly go awry.
Another promising idea: houses were buildings that rolled a ‘labor’ die, and to construct buildings you’d need to supply labor resources from house die. This somewhat works, but not at the range of scales I wanted to operate with. For a huge space fantasy metropolis, a building could be the neighborhood market or an entire spaceport. If a few ‘labor’ resources can build a market, then dozens would build a spaceport. Rolling dozens of dice was out of the question, a firm constraint for the game.
My solution is to both of these issues is first to remove the house building from the player’s toolkit altogether. As a player you will never just ‘build houses’. Residents, as houses, grow in the city as a function of you operating other buildings or various other events. Residents also don’t roll dice at all. When you construct a building, it must be able to reach a certain number of residents within a range of that building. While that building is under construction, those residents are reserved and unable to be used for constructing another building.
Removing house building removes a key interaction for the player (which is the part I typically find unengaging) but adds a distinct texture to the game. Like cellular automata, residents grow semi-randomly, sometimes filling in gaps and sometimes creating unusual shapes. Buildings you construct as a player will affect an appeal value for spaces in the world, so the player does have some general direction, but not totally.
The unusual shapes created by the residents will force you to build in odd and unconventional ways, working how you can with the residents. My goal here is to feel like the city has truly interesting districts and neighborhoods, arising both out of whim and chance and your desires as a player.
The restriction for constructing a building addresses both the representation of labor and nice limitation on player construction together. It’s also an idea that is easily and immediately communicated to the player: you have strong but clear limitations about where buildings can go, and how many you can place. Buildings can also vary a lot in their needs, the aforementioned market only reserving a few adjacent houses while a spaceport requires dozens over a huge area of land.
The population and neighborhoods will take on a life of their own exactly because the player didn’t place them, but watched them grow out of the city. My hope is that cities will have truly unique and unexpected designs because of this feature, and I’m very excited for it.
From a design perspective, the factions and events form the third major element of the game, alongside the dice and the environment. The goal is to create a narrative quality to the game and city that is missing from the other two parts. The dice and environment provide a large a
From a design perspective, the factions and events form the third major element of the game, alongside the dice and the environment. The goal is to create a narrative quality to the game and city that is missing from the other two parts.
The dice and environment provide a large and detailed systemic representation of the city. There's many little stories that come out of them, but they represent the city and environment as a series of processes with relatively fixed inputs and outputs.
The factions and events represent the people, communities, and ideologies in the world, and they are weird! The events are meant to depict what the systems can't - strange occurrences, people being goofy or aggressive or helpful. The events also describe much of what happens beyond the city, in other settlements in the solar system and in systems beyond. This layer is something that narratively you are aware of as you control the city, but do not have direct control of.
Designing the event system was tricky, and a lot of ideas came and went. I wanted to keep events and factions simple so that the focus remained on the city building, and so that it did not feel like the factions were playing a game without the player. A typical 4X or strategy game has the player and AI on (roughly) equal footing mechanically to simulate the idea that everyone is at the same table playing the game, which was not the goal here.
Skipping over the dozen discarded ideas, the factions came down to being represented by two values: strength and disposition. If a faction is strong enough and has a disposition towards you, a mechanical effect is applied to the entire city at once. These can be positive or negative, but greatly alter the various rules of the game like weather, terrain, dice, and more. Events are now closely tied with factions and change strength or disposition of that faction, or others.
The ultimate benefit of the simplicity of this system is communicating it to the player. To take a discarded idea of factions owning buildings and the you interacting with them: how is the state of the building's owner communicated to the player? Floating icons, art tinting, custom art, all have pros and cons that for the moment ruled out these ideas.
So factions have strength and disposition, events tell little stories to adjust those values and affect the game elsewhere. A few different ideas on how to incorporate dice came and went, with the resulting idea feeling very obvious in retrospect. If you can afford to you can choose to pay influence to select an event option, otherwise a die is rolled.
A few other options here were interesting, like a special faction die to choose a type of event, or the player paying to change the faces of die to better guarantee the outcome they wanted. Ultimately simplicity won out, similar for reasons above.
The first production decision made for Amberspire was choosing to render the game in 2D or 3D. By training and experience I am a 3D artist and comfortable with 3D games, so this seemed like a natural starting point. Once I actually got started on the prototype however, we decided
The first production decision made for Amberspire was choosing to render the game in 2D or 3D. By training and experience I am a 3D artist and comfortable with 3D games, so this seemed like a natural starting point. Once I actually got started on the prototype however, we decided to do the exact opposite: go full 2D and isometric.
Bazaar
Cities are dense and detailed environments, and producing detailed 3D art is a lot of work. You need to conceptualize and model walls, roofs, windows props, domes, arches, tunnels, plants, – everything you want to see. Then unwrap and texture all those objects, before creating shaders for all the materials to render them. I have experience doing all of these things, but our goal was to keep the team size and production close to The Banished Vault - which had comparatively few small and simple models. Amberspire would need a few dozen unique buildings, all detailed and intricate.
All this to say 2D art is not by any means easy, but it does have many fewer steps. It solves a lot of production problems all at once: once an artist draws the image, it just has to be placed on screen.
More subtly, however, is an expected level of detail when comparing 2D and 3D. I did not want the city to feel like it was being represented abstractly, like buildings in The Banished Vault. With a space fantasy setting, specific details are important to communicate the setting and world to the player. My worry would be that with a setting so unusual that alienates the player a bit, art that is further removed from the 'accurate' depiction of the setting would be hard to understand and engage with.
One small bonus here as well: 2D art is more iconic. Everything in a game is an interface the player, and which building is which is an important piece of information for the player. Making a 3D building recognizable is doable, but just that extra step harder than in 2D.
Clockworks
The science fantasy mode that Amberspire is in is communicated through the art, and it looks best in 2D. Hand drawn, irregular, illogical, equally playful and sinister – I could go on. When our artist Yue started on the project one of the first things I said to her was “don’t worry about making the buildings perfectly logical”.
There is a je ne sais quoi to 3D art that implies some kind of underlying logic. To make a closed shape, vertices have to be connected in a mathematical space and be rendered by the engine. Of course you can make illogical 3D art, but that comes with other tradeoffs.
In Amberspire, the buildings are fully realized. They explain exactly as much of themselves as Yue and I want them to. The setting overall has many magical and fundamentally impossible aspects, and the art style and rendering are vital in communicating that.
Temple
We've been quietly working away on Amberspire for a little while, and it's finally ready to be shared with everyone soon. Amberspire will launch on Steam on May 6th 2026 ! We'll be posting a whole lot of sneak peeks and previews on our socials (@BithellGames on everything) betwee
We've been quietly working away on Amberspire for a little while, and it's finally ready to be shared with everyone soon.
Amberspire will launch on Steam on May 6th 2026!
We'll be posting a whole lot of sneak peeks and previews on our socials (@BithellGames on everything) between now and launch, so be sure to check those out in the meantime.
We're so excited to get Amberspire into your hands. Wishlist, tell a friend, and we'll see you soon!
Cellular automata have fascinated me from the moment I learned about them. How can simple rules and constraints can produce astounding complexity and unpredictability? Or even a simple recurring equation like the logistic map producing random noise, when tuned to the right value.
Cellular automata have fascinated me from the moment I learned about them. How can simple rules and constraints can produce astounding complexity and unpredictability? Or even a simple recurring equation like the logistic map producing random noise, when tuned to the right value. It feels clipping through a wall in a game and seeing the underside of reality. A decade ago these ideas lodged in my brain and fused with the overwhelming desire to move from the suburbs and to a city, and I've been thinking about the two together ever since.
So over the years I’d try experimenting with cellular automata to create a city builder, somewhere between a game, toy, and visualizer. I tried to hold on to a powerful idea that would eventually prove impossible, that the player could adjust the rules of the automata system to change how the city would grow. If a player wants more farms, they can tweak the conditions under which farms grow, or denser/sparser street networks, and so on. It's easy enough to experiment with how this might work (1) using Conway's Game of Life (GoL), adjusting the thresholds for a cell's birth and death.
If you experiment with GoL you'll start to notice an issue: frequently a ruleset will set every cell in the system to alive or dead. Some rulesets won't do that, but after a few generations will stabilize in a random but completely static pattern, no longer exhibiting the intriguing fluctuations of Conway's specific rules.
From the point of view of making a game that someone can play, the variants on Life’s ruleset are not qualitatively equal. Conway’s ruleset is the optimal one that produces interesting results. What took me a long time was realizing how common this problem was across many types of cellular automata.
The appeal of a cellular automata system is its downfall when trying to put it into a game like how I imagined. That appeal - that a small set of deterministic rules can unexpectedly produce anywhere from structure, chaos, nothing or everything - is distinctly unappealing when applied to traditional game design and structure. This is the shared unsolvable problem (2) that I found, at least for me, my style of design, and my goals.
Generally speaking, players want the outcomes of their actions to be predictable, with some margin for uncertainty. Maybe the uncertainty is large but its effects are limited (a to-hit dice roll) or a small uncertainty not realized for a long time (several moves in Chess).
Broadly, types of cellular automata systems might be more or less predictable. I was exploring and designing various systems, trying to find one that allowed the player to adjust rulesets within them to be variously interesting and function as a game. While each ruleset had benefits and drawbacks, it was very hard to find one with a wide variety of qualitatively interesting rulesets. Many would respond like GoL does, just shutting down entirely.
If the player is fiddling with the rules, they might create something that has too much immediate uncertainty, or not enough. Or something that only starts producing random results after 1000 steps of iteration. Effectively, the result of adjusting rulesets in itself becomes too randomized. The outcomes don't fall within that narrow band of uncertainty that makes games interesting.
The appeal of decision spaces in games is that players can slowly grow to understand most if not all of the possibilities within it; the appeal of cellular automata is that a system can sometimes produce nothing, gibberish, or structure.
Now, you might be thinking, hey I can name a few games that use CA, so learn from them! And you’re right! Everything above is a historical realization I had maybe five years ago now, and only really applicable to me and a very specific goal of a certain kind of city builder. At some point I just had to set this idea down and move on.
What's funny is I do still think about games as non-linear systems and frequently try to analyze and design games with this method. Chess (or Go, etc) as a system is almost purely deterministic (the random elements are the players themselves) and produce highly random outputs. Solved games like tic-tac-toe do not interest people – we're interested in games (3) where we don't know the outcome.
This provides some key background to my thinking as I approach Amberspire. Cellular automata, chaos, and nonlinear systems have influenced me tremendously, and there are ideas in the game that are downstream of these. They are not quite true cellular automata, but there is chaos arising from order and player input. In future design diaries I'll be talking about the population and terrain tiles where these ideas are strongly represented.
- - - -
1 An online tool for experimenting with Game of Life (this can produce flashing images, increase the round delay value to mitigate this).
2 Or cursed.
3 Extend me some grace here about the definition of 'game', I am pretty aware of edge-case definitions and take them seriously!
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
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.
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.
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.
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:
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
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.