The Great Journey – Interlude 1

So the first leg of the Great Journey came to a grinding halt with the Galactic Map course plotting going a lot squiffy. Slightly annoying – as I wasn’t expecting it at all. The last time I’d used it, all was well!

I was – too be honest – expecting to be thwarted elsewhere. But, hey ho – that’s games dev 🙂

Having dug into the cause, I found an optimisation to make the map work with stars in an Octree had caused the problem. And the irony is that the optimisation was to improve things 🙂 In particular, this one is a dynamic Octree, which subdivides as each container node exceeds a threshold count of the items within it. In this case, 500 stars. Normally, objects manage themselves within the Octree as they move around, so when a node threshold is exceeded, they eventually re-add themselves to the new sub-nodes in the next frame. However stars are static and do not move, or update themselves in the Octree, so when the threshold is exceeded and the node sub-divides (into 8 sub-nodes) all the stars in the original node need relocating in the new sub-nodes there and then. This wasn’t happening, and that blew up the ‘find the nearest star on the route toward my destination’ navigation.

So, that’s now fixed – naturally – and the route finding is working as expected. That lead to the course visualisaiton not really standing out, so some rendering tweaks required there, then I wasn’t happy with the ‘opengl point’ stars, so now they are back to particles, which also needed scaling to stand out… and then I stumbled over the much bigger dilemma that I am presently tackling.

The Economy. Or rather, lack of it. Posts of long ago detailed how I’d created an economic model that is driven by civilisations, supply and demand, the players actions, etc. My solution is to create a database of every star system, and manipulate it as events happen – rather than the more typical ‘generate it procedurally as you need it’ approach. However, as I jumped to a nearby star sporting a station, I found that it had no economy – at all. So I couldn’t sell anything there! Further digging revealed the economic database was rather old, with only 500 star systems in it as opposed to the current test Cluster of 10,000.

It turns out generating 10,000 system economies is taking a rather long time (SQLite is only so good. Also, some bug in the generation code results in it allocating up to 1.8Gb of RAM before it gets halfway through and killing the executable. Hmm.

So, I’m questioning my choices there at the moment, and giving serious thought to a lighter economic model ‘for the time being’. A deterministic algorithm will do, replacing all this setup complexity, and allowing me to move forward – but it doesn’t really deliver what I wanted longer term.

Hmm.

I don’t want to derail this attempt to check over ‘gameplay’ by turning aside so early to work on a major gameplay component, but then, this one really needs to be done properly and is a core component.

Using my ‘Pragmatic Razor’ I have decided to park the economy model and slap in a lightweight deterministic generator. Doing a ‘proper solution’ isn’t going to be trivial, and I don’t want to be distracted from that (or indeed by that) just yet.

Thus, once this interlude is over, the Great Journey will continue!

SHARE THIS POST

  • Facebook
  • Twitter
  • Myspace
  • Google Buzz
  • Reddit
  • Stumnleupon
  • Delicious
  • Digg
  • Technorati
Author: Mak View all posts by

4 Comments on "The Great Journey – Interlude 1"

  1. Cornflakes_91 October 22, 2016 at 1:47 am -

    Couldnt you use a deterministic algorithm to seed the initial economy and start the sim from that known base?

    That would allow the economy sim to be more lazy in its execution and would prevent “planet with no economy” problems.

  2. Mak October 22, 2016 at 6:43 pm -

    That was the original plan, but as Dom was to be an MMO I wanted ‘real’ controllable economies that other players affect, and also can be altered by admins. But, I think I can wave that plan goodbye 😉 so now it’s back to deterministic, which is what I did for Part 2.

  3. Cornflakes_91 October 25, 2016 at 4:34 pm -

    using some deterministic algo to set the “zero-point” doesnt prevent dynamic simulation.

    It just seeds the initial values.

    It would only prevent the awkwardness of there not being any econ when you get to a system that didnt yet get a slice of sim time

  4. Mak October 25, 2016 at 4:37 pm -

    Oh for sure… it just means the Admins couldn’t easily step in when needed (planned disasters, etc.) But if I can patch the deterministic data with event based changes, then it’ll be fine.

Subscribe to The Dominium Observer Newsletter!
Subscribe