Designing the game

Lacuna • July 29, 2022

Well it's taken me a little longer than anticipated to work out the rough details, however I think I'm now in a position to start drafting up the initial stages. Obviously, there is going to be a number of changes made over time as I perfect the concept and play-test it, but it should be possibly to get the vary basic draft up and running over the next few days.

The concept

I started with the simple idea of a resource management game and that's where I'm going to end up. There will be a number of different resources, a number of different buildings creating and using the resources, and at a later stage, some special buildings that may change the levels of resource production / consumption.

Looking at this, it should be possible to design a system that has, for example, 6 resources:

production_1..6 (ie wood, stone, food)
consumption_1..6
storage_1..6
time (for building, upgrading etc)

By using these as field names I can hopefully make quite a generic template for other types of games.

The next problem is in creating the buildings. Obviously I need production buildings of each of the resources and getting those levels correct is a case of firing up a spreadsheet and playing with some numbers.

First I want some method of controlling the overall "inflation", that is the cost increase per level of the various resources be it in time, in production, in consumption etc. By varying this figure between 1.3 and 1.5 it looks like that is a passable start.

Next I want the costs for building and/or upgrading certain buildings to be simple to calculate, all based on some initial values and the rate of inflation.

Level Resource 1 Resource 2 Resource 3
1 85 100 10
2 110 130 13
3 143 169 16
4 186 219 21
5 242 285 28
6 315 371 37
7 410 482 48
8 533 627 62
9 693 815 81
10 901 1,060 106

This assumes an inflation rate of 1.3 and the simple formula:

floor(starting_value * inflation ^ (level - 1))

The starting_value I've set in the above to 85, 100, and 10 respectively.

If I add in an efficiency value for each resource, one for production, one for consumption and one for storage, I can manipulate this by adding new buildings.

As an example, if I have a base efficiency of 50% - I may be producing 121 units of resource 1 at level 5. If I build a refinery for example, that efficiency may increase to 60% pushing the production up to 145.2. Building more refineries or rather increasing the level of the refinery would increase the efficiency up may beyond 100% and of course I'd need a limit on the maximum level of refinery. This can be done with a simple max_level or maybe just by making it prohibitively expensive to upgrade.

Putting it all into practice.

I can envisage a number of plots of land - each of which can contain one building. There needs to a limit on the number of plots to prevent runaway planets, and there needs to be a limit on the number of buildings of any one type; in some cases 1, in most, as many plots as there are.

Now since I don't want to use crons, it would make sens for the backend to pass a timestamp as ell as the inflation value, the efficiency, production, storage and consumption values to javascript on every page load in probably a simple JSON block.

Javascript can then be used to increase the global counters; or rather only the display of the counters, every second or every few seconds. If the user refreshes the page, or clicks on any link, then a little middleware can easily update the values stored in the database again based on the last update. No crons, no horrible updates without where clauses which means I can reduce the page locking in the database allowing for more simultaneous players.

Wrapping up

The ideas are in place, however I now have to translate those into code. From what I can see, this is not going to be too complex, though like all of these things, once you start writing code, you quickly discover unanticipated problems. Still, hopefully I'll be able to get something in play fairly quickly though I suspect I'll not be overly concerned about the UI at this stage, and just make sure I can get a working proof of concept.