The Cepheus Project

[Inveteratus]

I've had in mind a little side project for a while; in fact it's something that has been knocking around my head for many years. I suspect that it may well knock around for a few more unless I solve all the interesting problems.

Rather than explain what it is I thought I may write up the process of creating it from scratch; and try to explain the reasoning behind the relevant components.

It is potentially a long-winded process for some, but I reckon having a working, documented plan as well as a full test suite; using unit, feature and acceptance testing as well as a decent level of static analysis in place, I think the code can be something to be proud of, and something that can be shared with people further down the line.

I would like to have the code peer-reviewed as well, so I'll be asking a couple of friends to look into the code, see if I've missed anything important.

As for the code itself, yes, I will be making it available, and better yet, it will be open-source. I've seen a lot of smaller browser-based games fail badly because they have not opened themselves up to other people, and in fact those games have rapidly become stale, often badly managed and sometimes very toxic environments. Github, or Bitbucket? Not sure; I'll probably just host it myself using gitweb as it's an easy option.

There's a tremendous amount of stuff to get through before a game can be launched, and a fair bit of maths to create and check formulas, nothing overly difficult but time-consuming. Some processes, I'll probably skip for brevity, and in order to make things easier for people following along, I will release code at key stages and try to move reusable features out to modules or components where possible.

Wrapping up

As a side-project, it is not a small thing, but equally it's unlikely to permit me to retire early; money may be possible to make from it, but that's not why I'm doing this. It's a bit of fun, a chance to learn some new concepts, and broaden my skills. After all, why else do we write programs?

 

You can follow the progress at The Cepheus Project and from time to time I'll no doubt pop a post in here.

Warning: It's early days yet, I'm still finalising some of he pages so url's may change.

 

As a preliminary, and to copy in those people who don't wish to visit an external site; this is my thoughts on choosing the stack:

 

Choosing the stack

I'm not a fan of these so-called game "engines"; the term is, I feel, misused too often doesn't really reflect the nature of the product. So, I'll start with a language, add a framework for speed and efficiency, then add the remainder of the code components.

PHP

Everybody loves PHP, but let's make sure we use an up-to-date version. As of writing, this is PHP 8.1 and since I have PHP 8.1.7 installed on my development box, this is an ideal starting point. I don't know as yet what mods will be needed, but a plain install of 8.1 should be sufficient for now.

The Framework

I considered a number of options here, but Laravel seems to be the best choice as it comes with a lot of features out of the box that are going to save a lot of time. Yes I probably could have written my own, using any number of Symfony components, but that would have probably ended up very similar to a Laravel framework without the bells and whistles, so I'll just settle for Laravel and save a lot of unnecessary work for myself.

CSS

There's a number of different CSS frameworks these days, some people like the batteries included approach, while I've grown rather fond of Tailwind, which allows for rapid prototyping and equally allows me to create simple reusable components with all the relevant classes defined properly in CSS leaving the HTML nice and clean.

Better yet, by adding in support for SASS, we can make the CSS a little more friendly with a hierarchical flow.

Fonts

Normally, I'd use Google Fonts to provide these, but being privacy conscious, I'm going to host some fonts locally which ensures Google doesn't perform any tracking. Overkill? perhaps, but I know a lot of people who are not keen on Google watching everything they do.

JavaScript

As for JavaScript, this caused me some problems. These days I think I like pretty much vanilla JS, so I'm going to use Alpine.js as it provides a very lightweight system and will hopefully help reduce the complexity when writing components, since I've no doubt there will be a lot of replication in the code.

Databases

MySQL will be ideal as it's well proven, well-rounded, and most people are fairly comfortable with it.

I'm also going to add Redis for caching and later on: session storage.

Node

For the build process, I'm going to need Node.js. I have v16.14.0 installed on my development box and of course you will need Node's package manager: npm. Again I have this installed; version 8.3.1; on my box.

Wrapping up

Finally, I'll be using Docker for development to encapsulate everything into nice clean containers and to make the whole system portable between developers. Production-wise, I'll be using native services rather than Docker at least until the natives cause a problem!

 

Edited July 20, 2022 by Lacuna

[SRB]

Laravel, Tailwind and Alpine - getting no critique from me. That's my daily development stack.

Noticed you plan to use docker though - are you a windows/linux user?

If you use a Mac, valet (https://laravel.com/docs/9.x/valet) is decent. Combine it with homebrew for installing packages, and it's a breeze to work with.  If Linux, there's even Valet Linux (https://cpriego.github.io/valet-linux/) which works similar, but without homebrew as you can just load in packages as its... well, linux.

If you're on windows... I don't envy you! 😄

[Inveteratus]

I'm a Linux user mainly and have been for a while. Laravel's Sail seems the fastest and simplest way forward for most users as I've briefly tried it on a Mac and it works nicely, though not had the opportunity to try it on Windows. I'd guess with Laravel's attention to detail it will work as anticipated.

My primary aim with the Docker is to minimise the potential differences in environments and to use something that I know is easy to migrate to native services on production servers.

Valet I've never tried; as I was under the impression it required some of virtual system: VirtualBox, Qemu. Parallels and/or Hyper-V. Maybe it's worth visiting. Thanks for the pointer.

[Zaalah]

I use Laravel Sail on a regular basis across all my projects and it's amazing.

If you don't use VSCode, I would also recommend that. There's a feature in VSCode called "Remote Containers" that lets you basically write code inside your dev container. That means the integrated terminal is also automatically inside the container, which is super useful for stuff like running tests and all that.

It's definitely a bit more to set up than something like PHPStorm, but I definitely enjoy the practicality of having everything neatly tied into their own containers.

Edit I also see your blog isn't secured, I'd recommend slapping a cert on that bad boy. Even if you're not doing anything sensitive, it adds to the legitimacy of the project.

Edited July 21, 2022 by Zaalah

[Inveteratus]

Yes, I saw an article recently about VSCode's remote containers; not tried it yet as I'm fairly tuned into PHPStorm and have a number of plugins that I'd be lost without. Still worth a go.

As for the SSL cert, well the blog is pure HTML, so no need for it, however I am hoping to bring up the git repo tonight, so I'll be apply certs in due course. As always, it's been a rush to try to clean up some of the posts, to rustle some some tools to help generate bit of code, write demos etc. Time is not my friend especially with a full-time job to contend with!

[Inveteratus]

Revision 0.1.1 released; full authentication, with tests across the board.

It's not a big release per-say, however it does provide you with a working system, a full authentication layer and tests for all controllers. As a starting point, this has the potential to be used in many projects.

Did I mention it's free?

The next stage is to start to develop the game itself; though I must admit, part me of thinks I should look towards the building of an in-game communication system encompassing mail, and chat.

[Inveteratus]

Designing the game

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 back-end 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.

Edited July 29, 2022 by Lacuna

[Script47]

From time to time I peak on MWG and I'll be honest, it's been a while since a project has piqued my interest - especially with the tech stack. I'm very much also enjoying your dev blogs.

P.S.: I recently started using Inertia and it's been a blast and would definitely recomend it as it makes life infinitely easier.

 

[Inveteratus]

Well, it's taking me a little longer than I expected to get the next point release done. Sadly work and family come first and I've had a bit of rush on at work of late.

As for Inertia, I'll take a look; it's always useful to discover new technologies.

Had a little time to think about the flow, it's a bit unstructured but for the sake of completeness I'll pop it in.

Looking at tables:

Users: [id, name, email, password, ... etc]
Players: [id, user_id, ... etc]
Systems: [id, ?player_id, x, y, ... etc
Habitats: [id, world_id, resource_xxx_level, storage_xxx_level, ... etc]
Buildings: [id, name, resource_xxx_consumption, resource_xxx_production, resource_xxx_storage, ... etc]
Sites: [id, system_id, x, y, building_id, level, ... etc]

See the blog for a better view of this!

There's something gathering momentum in my head regarding combat, but it's a while of; I need to try to balance the resource production side of things first.

Anyway, I think this architecture works; of course I need to update all the resources in the background without crons or queued jobs, but that's easy enough. There are some concerns with the structure, which I suspect will be taken care of with a little cheating on the normalisation front, but I'll leave that until such times as I get the updating mechanism in play and see how it works in real-time.

Had a quick look at Inertia; looks interesting, but I'm not a fan of Vue and I'm ashamed to admit I've never touched React. Svelte might be an option as it looks interesting though I'll need to fire up a few test projects to get to grips with it properly. Regardless, good pointer @Script47, gave me some interesting reading material on the train.

Edited August 11, 2022 by Lacuna

[Script47]

Ah, I absolutely adore Vue, have an intense dislike for React, and never used Svelte. I'm glad it made your train ride more interesting though.

[Ishraq]

On 8/9/2022 at 7:55 PM, Script47 said:

From time to time I peak on MWG and I'll be honest, it's been a while since a project has piqued my interest - especially with the tech stack. I'm very much also enjoying your dev blogs.

P.S.: I recently started using Inertia and it's been a blast and would definitely recomend it as it makes life infinitely easier.

 

I too feel the same about this, I am new to all these new frameworks and terminology. My mind predates to PHP, HTML, CSS, JS. Upload zip run install and build. I'll be using this project to get upto to speed with everything.

Looking forward to this