The Design Document

[Nique]

Is there any way possible to start with some base coding for the game this weekend?

[tomkeus]

Having the clients determine the simulation speed, and having the server have no concept of it, is a terrible design decision imho.  But I guess I'll do it anyways because I don't have a sufficient argument not to.

That's because I haven't explained in detail what I had in mind when I mentioned client/server method. I'll write down in more detail and post it here. I need input about that, especially from people who know networking. I hope I'll get to do that and some other things by the end of the weekend, but I'm not promising anything. I'm throwing a party tomorrow night so I'll try to do something this evening and tomorrow morning before I'm put out of commission.

[tomkeus]

OK, I'll need to elaborate a bit one thing I haven't been
particularly clear about. That is division between GUI and
simulator.

Let us examine in more detail SC4. Player is unaware what is
happening in the city. What he sees are pictures of buildings,
roads, animations of buildings under construction, cars running
around and so on. Player is not exposed directly to the
simulation. If he wants directly to access data produced by the
simulation he has to query building, graphs or various maps.
Each of this aspects is updated once per game-month. Based on
that appropriate animations and appearance are chosen.

The fact, that player is not directly exposed to the
underlying simulation is in the core of the idea of
GUI/simulation division.

To abstract a little bit. City is a complex system whose state
is described by numerous parameters. City's state is a function
of time, meaning that it is continuously changing. Within
software, city is stored as a number of variables, and
simulation is performed with a number of functions operating on
aforementioned variables, producing new set of variables which
represent new state of the city. Time evolution of city's state
is discretized for the sake of computation, meaning, that
consecutive states are set apart by some finite game-time.

Here, it is very important to choose optimal model to simulate
city and its evolution. Too detailed model, meaning too many
parameters and functions, results in high computation
requirements . Same statement holds for very fine
discretization of time.

Thus, parameters are chosen on the basis of their importance
for description of the most essential aspects of the city: like
population, budget state, traffic flow etc. Time step is chosen
so to provide realistically changing city, but since the player
is exposed to continuously animated city he is not particularly
aware of underlying evolution of the city state. So time step
doesn't have to be too small.

This is how I've envisioned gameplay:

GUI will provide the player with the visual representation of
the city's current state, interface to alter city's parameters,
appearance and query various details. When player starts new
city he will be presented with the blank terrain. Clock is
paused. Let's say player starts game at game speed normal.
Let's say that in normal speed, one game-month lasts 1
real-life minute (though, this will not hold exactly - I'll
explain bellow). Since this is the beginning player will
perhaps start building some necessary infrastructure, like
power plant, road connections and such. When he lays down
stretch of the road information about that construction will be
queued. Same for other construction or other changes player did
(like tax change).

When clock counts one real-life minute, these changes will be
sent to the simulator. Simulator will start crunching numbers
and then it will produce list of things that have
changed within duration of one time step. These changes
will be communicated back to GUI. When GUI receives updates it
will start new countdown and implement changes. Don't forget,
that all this time, GUI constantly displays animated city, so
player won't see city freezing up while simulator performs
calculations.

Now, let's continue. Player will continue making changes to the
city: he may lay some more roads, zones etc. When clock counts
another minute, all new changes player made are again sent to
the simulator in order for new city's state to be calculated.
Simulator will perform calculations, communicate them back to
GUI and so on.

Now, actual duration of in-game month will be one minute + time
simulator needs to perform calculation of new state. So,
fastest speed available to the game will be in-game month
lasting real-life time needed to perform calculation of new
city state. So, game speeds will be applied in GUI with clock
setting time between moment GUI receives update from simulator
and moment GUI sends to simulator changes player ordered to be
carried out.

This leads to design of communications interface. Interface
needs to be capable of queuing instructions reaching from the
GUI (more of them), and when the GUI's clock counts down,
queued instructions will be sent to the simulator. Immediately,
interface will start new queue accepting new instructions from
GUI while simulator is busy and so on. Once simulator finishes
calculations, changes to the city's state are sent to the GUI.

Here is rule I suggest for managing multiple GUIs. When we have
multiple GUIs we cannot expect them to send update commands at
same time intervals because they experience different workload,
reside on different hardware and so on. So, once first GUI
sends request to the simulator to calculate new state, request
will be put on hold until last GUI sends same request.
Meanwhile any new communication from GUIs will be stored on
queue. When last GUI calls in entire queue is sent to the
simulator and new queue is started. So, game speed will be
dictated by the slowest GUI in the network.

I hope this clears a bit what I had in mind. croxis I expect
comments from you about this queuing system. Please read
carefully and if you find that something isn't particularly
clear, please, don't hesitate to ask.

[dragonshardz]

I could edit the design document for spelling, grammar, etc., if you wish. I'll probably take a look at it once I get home.

[Genocidicbunny]

I know we have some few set sizes, but im trying my hand on a random map generator (ill need one for another project, so may as well kill two birds with one stone, one very big stone)

What im interested in is what kind of tile resolution are we looking at. Right now I have it set as 1px = 1m, but that is waaaaaaay too granular, and anything beyond small maps takes too much memory. Im thinking every 10m is a single pixel, with a pixel corresponding to a point on the heightmap? If we have a standard 10km by 10km city, (this is the base size, it may vary) and a region as 100km x100km, it means a 100mp image for the heightmap, which, while still pretty big, should reduce the number of memory overruns I have.

[croxis]

It is silly to have the terrain resolution that small. 10x10m should be satisfactory. 

[JoeST]

I would suggest with sticking to base-2 lengths...slightly more memory efficient...and SC4 does it

Joe

[Atomius]

Eventually the aim is to produce a game with graphics as good as what 5 would have had. I pixel representing ten metres would be a grand way not to do that. Terrain imo is one area Simcity 4 is very archaic compared to what is possible. The level of detail is essentially two triangles per tile. Very poor stuff, and something which should be improved in a successor. (perhaps for older pcs there could be an option for switching between level of detail amounts for terrain?)

I have seen video games with very realistic terrain, and putting aside the problem of graphics taking up game speed, a successor to 4 should have a good realistic terrain. OpenCity imo fails at this dismally, and i think that realistic terrain is integral to the graphical side of this project.

In Atocity as i only have the lite edition of Game Maker i don't even have terrain but it stands to reason that the smallest unit of terrain definition should be smaller than that used in 4 in a fully 3D game, or you'd get ugly affects like in OpenCity