Game thoughts

Thing is, I don't really want a 'game' with winners and losers. I want an interesting simulation of something like a world that I can watch develop, and maybe influence (and maybe see what ifs? for).

I've got techniques (in the sense of "I know what they're called, and roughly what the limits are) to generate landscape ("Diamond/Square" for large scale, simulated erosion for smaller). I can populate the world with agents that have goals and behaviours, and that interact with each other. I think it just feels weird to build it as art.

I'm also not sure what to write it in. JavaScript gives me the browser (although don't forget QuickJS). C# gives me a server. C gives speed (theoretically). Loxish gives me control.

I think I should stay very much focused on writing for myself, rather than for what I think other people might want. Yes, it would be cool to make a world that other people want to play in, but I'd far rather build a world that I want to play in.

I very much want a clean separation between the display and the rest of the code so I can e.g. start using OpenGL later (or sooner).

I've got a fuzzy picture in my head of writing code for agents in a way that allows me to tweak (or rewrite completely) without stopping the main engine. I also want to be running lots of agents, so that stuff is happening all over the map even if the player isn't looking.

Game components

Display

Takes the state of the game and shows it to someone. Could be graphical, drawing the terrain and agents, or could be textural, describing the game state and events.

Engine

Takes the game state at tn and ptoduces the state at tn+1

Terrain Generator

Makes a new world

Store terrain as a single linear array of longs, and use masks/shifts to store data.

Start with terrain being read only after generation, and maybe do something like a piece table later for changes (e.g., roads, landscaping).

Call the surface a torus, with the top/bottom linked and the two sides linked.

I'm assuming some kind of grid here, do I want to use hexes? Do I want to tie actors to the grid, or is it just for terrain?

square grid, tied actors is most simple and therefore least realistic. (Although the grid can be much finer than the actors, which helps hide the simplicity).

Hex grid solves some of the square grid problems (diagonal movement, mostly), but has a chunk of extra work, and ongoing integration/understand issues (plus, most algorithms assume a square grid).

Disconnecting actors from the grid gives them much more freedom, but then we have to handle "what if an actor straddles a border" issues. (Same as the fine grid option above, I guess)

Hmm.