Picking a genre

Lacuna • July 16, 2022

There's so many good browser-based games out there, but there seems to be more crime/mafia/yakuza style games. Since I'm not really a fan of those so that's one big group off the list immediately.

Now I have to say, I'm a bit of a Star Trek nerd. Not in the "wear's Spock ears to Trek-con's" type of way, lets just say, I've enjoyed watching most of the series, and in fact space has always fascinated me so there's a starting point.

Looking at the games by GameForge, they are mostly simple text-based games, with excellent graphics, but if you were to break those games down, they become simple resource management games with some extras thrown in here and there.

Now don't get me wrong, I like those games, but my graphics work is poor, so I'd have difficulty in creating something of that ilk, however I can create the text-based component. Resource management, space-opera style of game it is then!

Fleshing this out, I can envisage players starting on a planet at random, building up their resources, trading with their neighbours and perhaps joining coalitions to try and gain supremacy over their little part of the galaxy.

From an initial point of view, there's some potential problems; for example 3D maps become difficult to draw and visualise, the time to travel between locations becomes enormous and technology is probably going to cause all manner of problems. But, taking a leaf out of science fiction, we can negate travel times, technology can be glossed over, and changing how we present the maps can convert complex 3D views into 2D relatively simply.

There's some interesting problems to solve here, not least of which is:

World generation

How do I generate sufficient differences between worlds to make them interesting? If you've ever come across the game Traveller RPG, it has a potentially a usable world-generation facility. By using something like that, extending it where necessary, ignoring the bad bits, we should be able to generate a vast number of different worlds.

Size of playing field

100 worlds? 10,000 worlds? 1,000,000 worlds? Pick a number! As player would probably be able to "see" a number of worlds around them, we need to generate at least a decent number f potential worlds, but they can't be evenly spaced.

And how do we deal with the 3D problem? Hexagonal maps seem to be the answer here and to save generating all the worlds beforehand, perhaps we just generate worlds on a need bases.

I'm thinking of an ever-growing spiral on a hex map here. The player is allocated their initial location somewhere along this spiral, and we ensure all the worlds within the player's "jump range" are created.

Name generation

With all these worlds, I'm going to need some way of naming them. That suggests Markov Chains with a decent set of sample data.

Trade prices

Prices are going to need to change for the various commodities. Perhaps this is a place for Perlin Noise. We should be able to vary the prices apparently randomly yet retaining a level of realism.


Players need to gain abilities over time, by learning from experience or simple training. Ideally I'd like a full hierarchical system of training each element of which would have some costs associated with it; cash of whatever our currency is, time and maybe commodities for the higher level courses.


To chat or not to chat? With a large number of players, Ajax becomes a bad idea, so if I do implement this, then I'll probably go Websockets though that will take a bit of thinking about to get 100% right.

Inter-player mail is easy enough, just need to make sure that private communications are encrypted to prevent anybody including myself gaining access to these. I seem to remember a couple of games where the moderators/staff insisted that players wrote their in-game messages to each other in English!


Tricky one this. I'd like combat to be enabled only if you want it so players are free to explore on their own, safely, while others can construct vast fleets if ships to attack opposing forces. This will probably need some sort of external scheduling system, and potentially need worker processes written in high level languages and compiled for speed.

Wrapping up

There's a lot of problems here, some small, some large, some complex, and I've not really thought through many of them yet, but hopefully I'll be able to keep the ideas roughly on track as I start ot build the system up.