I thought I may as well post an update on the progress of Retrograde Online. If nothing else, it helps me keep track of what I’ve actually been doing, as sometimes it feels like an awful lot of work has gone into achieving very little.
The most obvious thing to report on is the tech stack. I’ve decided to write the server in .NET 8 and C# 12 and the client in React v18.2. After all I am primarily a .NET developer, and I’ve wanted to get involved in React for a while. However I fear I may have underestimated the learning curve for React, and progress on the front-end is much slower than on the back-end.
For the database I’m likely to stick with SQL, or maybe Postgres, depending on which I find easier to work with, and cheapest to use. I will be hosting the game in Azure when it ever reaches a stage where a hosted application is required.
What has been achieved?
Well, I have taken a Domain Driven Design approach to this project, as that was something else I wanted to have a go at. Did I mention this is a personal project for me to have a go at something a bit different? Granted, I am not leaving my comfort zone entirely, as I am using C# and .NET - I needed to have something familiar to build on.
As a result of that design decision I have implemented the following layers: API, Application, Infrastructure, Domain.
API- For the Web API controllers, with Swagger for the endpoints.
Application- Where the services and mappings between web and domain live.
Infrastructure- Containing the repositories and the database models and migrations.
Domain- Holds the domain models, encapsulating all the business rules required, as well as interfaces for the repositories
This is a different way of working for me, as I am used to having the business logic in what here is the application layer, and working with the data models themselves in the infrastructure / data layer. I would not normally have a domain layer at all.
I’ll see how it works out. I am not tied to Domain Driven Design, and at this stage I am not even sure what the benefits are, other than to say I have tried it out.
Yeah, but what has actually been achieved?
I started with a City entity. This is the player’s starting colony. It needed a Player entity so it could belong to a player, rather than being detached and belonging to no one.
Cities are also able to construct buildings that will give the player the ability to do things, so I created a Construction entity. But a construction, for example a farm, can be built by any city (within reason).
I’ve also added Research for players. By researching new technology players can unlock new constructions and units. Research take time to complete. Players will start off with some initial research completed, allowing some constructions and units to be built from the beginning. This includes the ability to construct buildings that enable food and mineral accrual.
Resources are the final thing I have a basic implementation of. The initial types of resources are minerals, crystals, food, gas, and motes. I have not decided on whether I will keep these names, but they are useful as a starting point. A resource bar appears at the top of the screen and displays the current stock of each of the resources for a city. These values will increase every server tick, and decrease when a player consumes the resources by constructing new buildings.
Server Ticks are currently set at one minute. A tick is a time at which the game updates its state. At each minute the server rolls over to a new tick, and all resources are updated. Well, almost. To save on the processing that would require should anybody actually play this game, the database is only updated when a user action takes place to request that latest resources for a city. If a player logs in and views a city’s details, the resources are calculated and saved to the DB, and displayed in the client. This calculation and DB update will not take place again until the user requests the city details again, which can be at any time in the future. The game does not update the city state automatically.
I won’t list out the details of every single model, as there are a lot, but I have managed to get a working version of the client and server that allows some basic functionality. A city can construct buildings, but these cost resources. Resources are acquired from constructions, such as a mine. The city’s resources will accrue over time, and this is linked to a rate per resource that is augmented by the effects of constructions.
For example, a city can accrue minerals at a rate of 10 per server tick if they have built a mine. This is because a mineral base rate of 10 exists, and the Core Mine acts as a multiplier of 1 on this rate. 10 minerals per tick * 1 = 10 minerals per tick. Simple stuff. If a more advanced mine was to be built, not that one exists yet, it could have a rate 1.5, and therefore the accrual rate would be 10 minerals per tick * 1 (Core Mine) * 1.5 (Advanced Core Mine) = 15 minerals per tick. You get the idea.
There is still a ton of stuff to implement before I can even call this an alpha version. This is still very early proof of concept stuff.
A non-exhastive list off the top of my head of things that need implementing is:
- User login and authentication.
- Unit production.
- The world itself (possibly a connected node graph representing tiles on a map).
- Combat.
- Trade.
- Colony Management.
- A good UX.
I am planning on getting the game to a stage where all the core functionality is in place and some rigourous testing is done, both unit and integration, before attempting to get anybody interested.
And that’s probably it for a first dev update.
3rd January 2024
