UV Mapping a Sphere
After another couple of hours I’ve figured out what UV coordinates are and have managed to texture my rotating sphere with earth.
I’ve been reading that the best way to texture a sphere is with a Cube Map, so that’s the next thing to learn now. For example, if I move the camera to get a good look at the south pole (of my sphere) and then move my texture a bit, you can see how the UV mapping leaves a lot to be desired.
Understandably it pinches in the 2D texture. The best way I read this described was that it’s like trying to wrap a piece of paper around a basketball.
Thinking about a simulated economy
One of the things that I’ve definitely wanted to have in The Last Boundary is a simulated economy. As your mighty space empire grows the various sectors of the economy would produce supply and demand which would naturally result in the cost of your fleet and other projects rising and falling. Different government models would probably affect this in different ways.
I was talking to a friend who is studying accounting and he was telling me about something called Double-Entry Bookkeeping and this got me to thinking about how it could be used in my game. I don’t know if I can get the economic simulation down to an agent level as small as a company; but then I thought, why not? Understandably simulating every citizen would be essentially impossible; I would treat each as a “household” in a sense that it would be it’s own company that owes and is owed monies.
Then thinking about the Octree method to solve N-body Simulations got me thinking about how I could use a similar method to simulate billions of individuals buying and selling in an empire. The various leaves of the tree would be each planet, space-station, moon etc. At the level of space sector, the simulation would run between each of these. At the level of the empire, it would run between each of the sectors. At the planet level; well, I’m unsure if the potentially 30 billion inhabitants would be a small enough size to simulate; but perhaps I could merely split this into manageable chunks.
As the game runs, it would simulate just one of these lowest levels, incorporating the passage of time since it was last run. This could result in sudden jumps in simulated output, which means I would just use the last results to smooth it out some. Then at say the sector level (if it’s the next one up) it would simulate just one sector; then the entire empire. So each frame only does three simulations; but eventually it would sort of catch up with itself.
Then I remembered that I definitely wanted to investigate multi-threading my game as it’s something I’ve never really done and it just seems so cool. So, why not throw each of these into it’s own thread? There’s probably an upper limit of threads which might cause a problem; I think I could do something like a task manager to queue up simulations into the number of available threads. Each just runs and when it returns it’s queued up to run again.