Here’s a behind-the-scenes look at how we developed the game CEV-1!
I’ve always loved reading through how other games are developed, so we’re excited to share our development process with you!
Brainstorming
Over the past few months, a couple of friends and I got together to create a game. We weren’t sure what kind game we were going to create yet, so we started off with some brainstorming.
We thought of games we really liked and attempted to mash and merge ideas together to create some brand-new game. We really liked Civilization V and Plague Inc. and wanted to do some sort of resource management game, and write a great story to go along with it.
With all games, the player needs to have some sort of action. In most resource management games, there are two types of actions:
1. An investment that increases resources generated
2. An action that gets the player closer to the goal
Initial Ideas
Design Phase – Round 1
After the initial brainstorming session, we needed to actually make the game. We decided as a group to go with the CEV 1 idea over the Machine Learning Simulator, as it seemed more interesting and had more varied gameplay/interesting to play.
Testing
We created a spreadsheet on Google Sheets with the costs/benefits of each region and kept track of the player’s resources as they played the game. Initially, our game balancing was terrible (on our first playtest, a loss was guaranteed by turn 5), but we tried to change the relative costs to keep it interesting. Game balancing was a very significant challenge for us.
Feedback
Our players did not find the game very fun, partly because our game was unbalanced, but also because they felt like they were waiting for the days to pass by and resources to accumulate, without much opportunity for action. We were worried that players would find the tech tree or number of regions overwhelming, but they did not raise this concern.
- We have a metagame, but no actual stuff to do
- We need more short term goals
- We already have a long term goal
- Idea: have more popups (random events)
- Zoran: but no one will read the popups
- Too much waiting
- Idea: include more options
- Idea: start off with free upgrades
Design Phase – Round 2
With our first design going poorly, we decided to scrap our game idea and start over from scratch. Since a “world” might be too chaotic and overwhelming for the player, we decided to go with a single city.
We also took inspiration from the MegaMan Battle Network 3 Navi Customizer.
Essentially how the Navi Customizer worked is that over the course of the game, you unlocked new “pieces” which you can try to fit into your grid. There are certain limitations on where pieces can go, but it let you choose which upgrades you wanted to apply to MegaMan.
In our case, buildings would be those “upgrade pieces”, which the player would place down on a grid. We can have upgrades which allow buildings to perform better when placed next to other buildings. Basically creating a “soft restriction” on where the player can place buildings, unlike in MegaMan, which would refuse to let you place certain upgrades next to each other.
Premise
The player is an AI in charge of a new Mars colony. The AI’s (and thus the player’s) objective function is to “ensure colonists survive”, and they will do anything to keep people from dying. The player loses if a certain number N of colonists die (hard mode=1, medium=100, easy=∞). The player wins when they create a post-scarcity economy where no humans can die and resource production is greater than resource consumption.
Narrative
The theme is misaligned AI and space colonization. The upgrade tree contains policies and buildings to improve the survivability of the colonists. As the player continues researching through the tree, the policies become more ominous, allowing the AI to genetically modify colonists, impose child limits, and ultimately cryonically freeze colonists or upload them into the Matrix. The player wins when one of the final win-condition upgrades is researched, ushering in a new post-scarcity dystopia.
Game mechanics
Resources
There are eight resources:
- Food
- Water
- Oxygen
- Metal
- Energy
- Science
- Colonists
- Alive colonists
- Dead colonists (trying to minimize)
- (Space)
Each colonist consumes 2 food/turn, 1 water/turn, 1 oxygen/turn. If resource consumption is more than resource production, non-critical buildings (like schools and mines) “fail” (get deactivated) and if resource consumption is still too high, colonists die until consumption < production. The population increases exponentially as turns pass, pressuring the player to constantly increase resource production.
Buildings
There are several types of buildings that consume and produce resources. The player can rotate and place these strangely-shaped buildings on a 15×15 grid. A challenge is choosing and configuring the buildings to fit the available space.
| Building name | Cost | Effects per turn | Shape |
|---|---|---|---|
| Farm |
-20 food |
+25 food |
### #### |
| Oxygenerator |
-80 metal |
+40 oxygen |
# ### # |
| Mine |
-250 oxygen |
+10 metal |
### ##### ### ## |
Upgrade tree
A tech tree allows the player to use science to purchase upgrades that unlock new buildings, make existing buildings more efficient, or reduce resource consumption. Our initial grid was rather complicated, but we reduced the number of upgrades to make it easier to handle.
We spent a lot of time iterating on our tree. Initially, our tree was too wide and too shallow. To encourage a more structured progression through the game, we made the tree deeper and removed many nodes. Live link to upgrade tree visualization
Testing
We used Google Sheets for much of the “paper” prototyping session because our game includes a lot of math that is easier to do with Sheets formulas. We also made a poster grid and cut out buildings on paper because it’s easier than a computer for players to rotate and fit shapes together.
So when playtesters came in, we had them physically place the buildings onto the grid, and then mimic their actions on the spreadsheet, and have it calculate the next turn’s resources. We used Google Sheets in conjunction with Google Apps Script to simulate the game environment.
Feedback
Game Progression Timeline
Here’s a breakdown of what we planned to have happen on each turn.
Turn 1
Introduce mechanics:
- Player can place buildings, and in multiple orientations
- Farms produce food
- Humans eat food (2 food/day)
- Only food and humans are shown on the graph visualization and on the farm visualization. The farm will continue to produce/consume the other resources, except it’s just hidden from the player.
Here is the screen that players would be first presented with:
The player is required to place down 2 farms, so they can see the graph update in real-time.
After placing down the second farm, the player will have a surplus of 1 food.
The city center produces 1 of every resource.
Turn 2
Introduce mechanic:
- Humans produce more humans
(population growth)
1 human will join the colony, making the food income negative. The player will be prompted to build a farm to keep the income positive.
Turn 5
Introduce new building type and mechanic:
- Wells produce water
- Humans drink water
Turn 11
Introduce new mechanic:
- Science
- The player will have 10 science by this point, as the city center generates 1 science/turn
- Upgrades (and Upgrades Tree)
- The player can choose between any of the upgrades that cost 10 science.
We would have a button that takes the player to this upgrades tree screen, where the player can choose an upgrade to buy.
We plan for all a tooltip to be shown when the player hovers over an upgrade. The tooltip will display all of the upgrade’s effects.
Ideas suggested by playtesters:
- Disaster events (such as meteors) that the player as to deal with
-
- Destroy buildings + make tiles unoccupiable
- Player receives warning/heads up of the incoming disaster if they bought some upgrade
Problems with our plan:
- End goal isn’t clear at the beginning of the game
Development
Now that we’ve flushed out a lot of the game’s core mechanics, and we are able to at least keep the playtesters invested in the game for a while, it was time to start actually coding the game. We looked into Unity and HaxeFlixel, but ultimately decided to go with HaxeFlixel as it seemed to be the simpler of the two – and because the Haxe programming language looks a lot like JavaScript, which we were all huge fans of.
We used a Trello Board to keep our tasks organized.
A few days into development, when we started working on the grid and building graphics – and it turned out to be a bit difficult in HaxeFixel, so we ultimately ended up switching to GODOT. Looking back, we should have went with Unity instead, as we have discovered that GODOT was not made to develop this kind of game. There were a lot of challenges we had to overcome with using GODOT. For instance, our buildings are all physics objects to allow for dragging, the resource visualization was really challenging to create, and having to build all of our components like tooltips, and tech tree items from scratch took up a lot of time.
We probably could have gotten away with making our entire game using React, and it probably would have saved us a lot of time. However, we wanted the experience of learning a new language and trying out a game editor.
Visualization Evolution
We started off with a basic bar chart in the Google Sheets mockup of our game.
During the design/prototype phase, we received feedback that it wasn’t clear what buildings were affecting the numbers. So, we decided to try out a stacked bar chart type of visualization.
This was a mockup of the graph design we were thinking of. We made this using Powerpoint.
The design of the graph made the game look too “mathy”, so we decided not to use it. We re-designed the graph so that each resource only took up one bar, and decided to place the reserves for each resource below the bar, and the actual incomes/turn on the bar itself.
Fixing all the labels, and adjusting the colors, we ended up with this as our graph design before releasing to the public:
Working on the Buildings Sidebar
We planned the buildings sidebar to be in a table format. Each row would have the building name, cost, effects, and the actual building which the player can drag onto the grid.
We had all of the buildings data stored in a .json file. We then read the file and turned it into all of these rows:
After making the buildings move onto the correct positions, we ended with this:
Added hand-crafted pixel art for each building:
Finally, we column-aligned all of the text, and also made buildings you were unable to purchase grayed out:
Finally, we added some color to the text.
And this the version the sidebar when we initially released our game to the public.
Working on the Upgrade Tree
Here was our initial implementation of the upgrade tree.
All of our upgrade data is stored in a .json file, so we were working on creating a dynamic upgrade info screen. 
We did change the color scheme to make it look better. We also decided to make a few modifications to our upgrades tree now that we’re able to playtest our game a lot quicker than with the paper cutout version of our game.
Initial Playtesting
After we finished our initial coded version of our game, we hosted it on cev.vishald.com, and sent it off to a few of our friends and roommates for final testing. Note that cev.vishald.com now just redirects you to our released version of the game.
We fixed a couple bugs and made a few QoL changes that our playtesters suggested.
Now that our game didn’t have any more bugs caught by the playtesters, it was time to release this to the public and see what happens.
Analytics Phase
Analysis Round 1
We released our game on itch.io on the evening of May 16, 2022. On the morning of May 19th, itch.io’s analytics said we had:
- 19.1k impressions
- 699 views
- 530 plays
We were pretty shocked that our game made it that far. We even had another game developer tweet about our game! We did not expect to get any type of recognition for this.
CEV-1 is a very simple (yet super engaging) city builder.
— Ludipe (@Ludipe) May 18, 2022
I wish it was a bit more difficult, but I had a great time with it.https://t.co/ubBfA4CnzM pic.twitter.com/uXtMxizJKi
Here’s what our turn retention graph looked like a few days later:
We noticed that we had huge dropoffs on turns 1, 6, and 10, so we looked at those turns and investigated why players are leaving.
Investigating Turn 1
Looking at those turns, we noticed that there was a LOT of text for the player to read through. We hypothesized that players were overwhelmed by the amount of text they had to read through, and got a bad first impression. We attempted to fix this by reducing the amount of text the player has to read through, and removed turn 0. We initially had turn 0 in place in order to split up the amount of text onto two separate screens.
We also made the blue a bit brighter, and also updated the resource visualization.
Some feedback that we received was that players were confused at the amount of reserves they had. So, we changed the bar height to represent the reserves, and we added an arrow to indicate the bar’s height next turn.
Another minor change we made was hiding the “Next Month” button until after the player places down the first well.
Investigating Turn 10
We investigated the amount of players that quit on turn 10, and noticed that many of those that quit did not even click on the Upgrades button to view the upgrade tree!
(We made it so that the player must view the tree before moving onto turn 11.)
Therefore, we made the button animated to make it very obvious that the player should click it.
We updated our game page with these changes (and a few other QoL changes everywhere) in hopes of increasing overall player retention!
- Removed the “placed building requirements” before advancing to the next turn, allowing more freedom in the tutorial
Analysis Round 2
We took a look at the turn retention graph and here’s what we saw:
Note that since we removed turn 0, it’s actually offset by 1 turn. So, iteration 2 should be “shifted over” 1 turn to the right.
We see that the turn 1 dropoff is fixed, however, the turn 6 and 10 dropoffs are still there, and even bigger. We created a replay tool in order to view what our players were doing. We filtered out players who quit on those turns and viewed their replays.
We see that this player sold the mine and all their farms for whatever reason.
It wasn’t just this one single player. Take a look at the buildings demolished chart:
We see that there players overall are selling a ton of buildings being sold on turn 6. There is pretty much no reason to demolish a building during the early turns unless the player is purposefully trying to lose.
Once we realized this, we needed to figure out a way to stop players from softlocking themselves in the early game. We had two ideas:
- Disallow selling up until turn 10.
- Make it so that all selling grants a full refund.
We weren’t sure which one was best. When in doubt, perform an A/B test!
Essentially, we assign every player a random number from 1-3, and do something different based on the number:
- A (1) – Control Group: Selling always enabled, full refund iff selling on same turn
- B (2) – AlwaysRefund Group: Selling always enabled, full refund always
- C (3) – DisableEarlySelling Group: Same rules as Control, no selling until turn 10
With that, we updated our game and waited for the results to come in.
- Also made some more QoL changes such as adding building multi-select, and showed the controls to flip and rotate when dragging buildings around.
- Also updated the color scheme of the upgrades tree for accessibility reasons
Analysis Round 3
Now that the results from round 2 have come in, it’s time to see which of the three groups turned out better:
We see that overall, C (refund iff on the same turn, but no selling until turn 10) performed the best. We attribute the initial drop between minutes 2 and 4 due to noise. We only had 78 players in that sample size. B surprisingly did not perform as bad as we initially thought. We predicted that B would perform the worst, as it would make the game “too easy” and thus, players would finish sooner and quit sooner. The data does not suggest that however.
Taking a look at the turn graph, we see that the turn 6 dropoffs are at least a lot smaller. The turn 10 dropoffs are still present, however. (Note that iterations 2 onwards are offset by 1 turn due to the deletion of turn 0.)
We needed to figure out why players were still leaving on turn 10 despite us making the button animated and visible.
We scratched our heads and handed our game out to more friends until one of them discovered something that we were never going to discover on our own:
Turns out that the button was actually blocked by itch.io’s overlay on some specific screen sizes. That’s why players were still leaving without clicking on the button even though it’s animated and stuff.
We cannot do anything about the overlay unfortunately (it’s an itch.io limitation). So, what we did was just move the Upgrades button to the left.
The other chunk of players that left on this turn viewed the Upgrade Tree, but never purchased anything. Our data showed that none of the players who purchased an upgrade quit on the same turn. So, we just needed a way to get players to actually purchase an upgrade.
Animations for Purchasable Upgrades
We added an animation around the border of the upgrades the player is able to purchase.
Our hypothesis is that by adding in this animation, players would be drawn to look at these upgrades, over the others. It also gives players a way to differentiate between upgrades they can purchase right now.
We actually wanted to do a bit more with the Upgrades Tree, so we decided to run an A/B test to see our new upgrade tree.
- A – Old tree with border animation for purchasable upgrades
- B – Redesigned tree featuring slightly different colors, a legend, larger science display, updated text, different cursor icons when hovering over unpurchaseable upgrades, and more!
Analysis Round 4
Time to see which Upgrade Tree players preferred:
The data suggests that the upgrades tree visuals makes no difference in playtime, which we found really surprising.
Zooming out, it appears to make an impact in the late game. However, it shouldn’t really have an impact there (it should really only impact the early game), so we attribute this to noise.
We did choose to go with Upgrade Tree B because we think it looks nicer, even if it doesn’t make players play longer.
Thus far, all of our efforts have went to making more players get to the mid/late-game stage. Time to focus on the mid/late-game at least a little bit. We wanted to verify that having population growth be %-based is a good idea. So far, the population growth was always %-based. To confirm that this was the best, we performed another A/B test:
- A – Population growth is %-based
- B – Population growth is hard-coded per turn
Our hypothesis is that by having the population growth be %-based, players who struggle in the early game will have an easier time in the late game, and players who excel in the early game will have a harder time in the late game. We figure that this will make the game more enjoyable, and thus, players will play for a longer amount of time.
Analysis Round 5
From our data, we see that in the late game, the adaptive gameplay group (A) held onto players much better than the hard-coded group (B). It’s likely that group B’s players finished more quickly than A’s players on average, as players who excel at these types of games find it too easy, and players who struggled early on find it hard to catch up.
The first 20ish minutes, even though group B performed better than A, we attribute that to noise. The early games are pretty much identical since adaptive triggers have not taken much effect yet. We see in the mid-late game, however, this greatly improved audience retention.
As such, we kept the population scaling percentage-based in order to keep our players engaged longer.
GitHub Repository: https://github.com/sirknightj/CEV-1