..O Deniz's personal pages
/home /about

Epic4x: Devlog #1

February 24, 2017

Being the first development log on this project and having already been working on this for some time, it is going to be a jump in the middle of things. Here is roughly what I have

Player registration

Each person should be able to play in multiple galaxies at the same time, although these will be isolated games. The required that a person is represented by a User object and this person in a galaxy is represented by a Player object. I got to this conclusion after painful trial and errors with the player ending up with ships and resources he had from another galaxy in another galaxy. I’ve left the actual registration process out of scope for the moment and I’m just creating a default user if none exists. Galaxy creation Each galaxy represents a different game, and there are multiple games going on simultaneously. Galaxies are made up of stars systems. The galaxies are in radial form, maybe I might consider adding a spiral form – but not a priority. The different forms of galaxies should affect FTL traveling.

Star systems

The galaxy is filled with star systems that are distributed according to a simple density function so that no 2 systems are within a certain range of each other. Star systems contain planets which the players will exploit and colonize to further their ambitions. Star systems are connected by Warp lanes. No system is isolated, meaning that you can travel to any star from any star.


Planets contain


There are 5 types: Energy, mineral, society, physics, engineering. Energy and minerals can be stockpiled, the research resources cannot. Buildings, ships etc. will cost resources as will researching technologies.

Ships Designs

Ship designs are blueprints for creating ships. Ships consist of 1 to 3 sections called the core, bow, stern section. Each section contains a hull with different slot assignments. Slots may be small, medium or large and contain components. Components contain attributes and a value for that attribute. E.g a power core component contains a power output attribute which a ship will need to generate power for weapons or survey equipment etc.

This is a summary of the current progress. Now let’s talk about some of the things I implemented today. The game progresses in turns, which are automatically incremented at 1 turn per 10 seconds on the server side. Each turn planetary resources of the colonized planets are gathered and the costs are subtracted from these. Initially, I had 5 integers representing the resources on the planets, but this turned out to be cumbersome when tallying the resources so I changed this to a ResourceDeposit object with a type and amount attribute on each planet. This way I can just map the amount for an attribute type for each planet and just reduce them.

Random numbers determine quite a bit of how a galaxy is created, but I needed a stable environment for integration testing so I moved the Random class to a spring service which I can seed with a number so that it generates the same numbers each time.

When a player joins a galaxy some initial processing like creating the template ship designs and assigning a home planet must be done. When assigning a home planet an initial population of half of the tiles with resources is placed on the best tiles. Best tiles are the tiles with the most amount of resources independent of the resource type. So it’s pure chance if you end up on tiles with energy or minerals. You can still relocate a population to another tile at any time but that will have a happiness cost which in turn will reduce their productivity for some time.

Gather resources from a tile only makes sense if there is a population on it. Also the productivity of the population should play a part in what percentage of the resources are gathered per turn, something is waiting to be implemented. Also added some simple client UI to see the summary and the surface tiles of a planet, check the image attachments on the page at the bottom. It’s fun to see how the UI evolves over time. One thing to mention when developing the UI is the importance of persisting the logged in user session, so that you don’t have to login every time you restart the application. I used to use in memory maps to persist session data but after a short while having to login constantly gets annoying so now I default to persisting sessions to the DB or maybe Memcache/Couchbase when running in production.

Here is how all this stuff is linked together in the DB

Tags: #gamedev #epic4x #devlog