A big shift
In this post i wanted to talk about one of the major shifts that we are currently working on, why we are doing it and a bit about our development philosophy.
The shift
The big shift we are working on is that we are moving from the web-page based UI to a unified game world UI. What that means is that the tabs and web layout that we currently use is replaced by a more organic view where navigation and actions happen by interacting with the actual entities of the game.
Want to train troops? Go to the barracks. Want to deal with alliance business? The guild hall is the place to do it.
This has always been the goal for us, but it has been a big shift. We are happy with the progress so far however.
Consequences
One consequence of this shift is that it means we are also taking a step towards another of our design goals which is that the estate view and the world view are unified. Currently they are completely decoupled, placing your estate close to a coast or a forest has no consequence for how the estate map is generated. We want that to change so that placing your estate close to a forest or hills, intuitively, means that there will probably be a higher yield of trees and hills in the estate. Makes sense.
Building placement and estate sim
Another change we are making is that we are taking the next step towards the true city simulation that we always wanted it to be.
Currently, a player has little control over their estate and building placement has no game play impact. The only system that care about placement is the adore system (if you take the time to build a pretty estate).
With the next update this changes completely.
Cart system
Echoing the current caravan system, estates now have carts that ferry resources between locations. This is true for construction, refinement and training troops.
For example, when placing a new building (or upgrading an existing one) the construction doesn't actually start until some of the resources required have been delivered to the location by cart.
This not only will make the estate feel more alive, it also makes placement matter more. Picking up, delivering and processing resources now has a distance parameter to take into account. Buildings far from the city center will take longer to manage.
Building storage buffer
Tied to this change, buildings now does not automatically dump their produced resources into the players total pool of resources at every tick. Instead they fill up an internal buffer and can be manually collected to the estate by the player.
At the same time we understand that a city with 80+ buildings quickly will feel like a choir to manage if every building need to be clicked to collect their resources. That is why we are also introducing building extensions.
Building extensions
Each resource generating building can be customized with extensions. One of these extensions is an auto-pickup extension that will automatically send a cart to pick up resources when it is available. This is part of a larger automation push that we are working on but is a good natural step to take on its own.
There are more extensions that a player can construct, but you will have to find them out on your own once the update is live.
Yield
Similar to how the world map functions, we are also introducing yield maps to the estate view. Simply put this means that some locations are better for certain buildings than others. A heavily forested area would, naturally, produce more lumber than a barren plain or a stony field.
The hope is that this will tie into the cart system nicely, forcing the player to reason about where to place buildings and to optimize their estate layout based on available resources. And because the terrain of the estate is tied to the placement on the world map, a player that places their estate near a forest on the world map can expect more trees in their estate map.
Development philosophy
The way we develop games, and Imperia in particular, is very much an iterative approach. We have many long term design goals that we want to reach, but instead of developing all of the pieces for that goal in one big push, we instead break it down into smaller MVPs that are shippable as is. The UI is a good example. The goal was always to have a "in-game UI", not a html-tab based UI. But building that required a lot of other features to be implemented. Instead of waiting to ship anything, we started out with a fully functioning UI that helped us prove our ideas, fully aware that it would later be replaced.
This way of working also helps us get feedback from players and to get a feeling for what works and what doesnt as early as possible.
The same goes for art, balance and pretty much everything in the game.
Express the goal, find the MVP, push it live as soon as possible, get feedback and iterate.
A secondary benefit of this is that we also identify our bottlenecks very quickly. What is currently stopping us from deploying the next update? Usually the issue is art, so what can we do to speed up that part of the process? Can we re-use existing art? Can we use temporary art or icons? Can we improve the workflow for art such that new art can be more easily integrated once completed?
With the 3 months release cadence of Imperia Borealis, the development process needs to be solid and quick. Something that could be done in a week, can then not take three weeks to do because of something that is preventable with foresight.
End
If you liked this post and want to try out the current season of Imperia Borealis (The Hanseatic league) hop on over to Imperia Borealis and register an account for free.