XAPBob wrote on Sun, 01 June 2014 16:24

I would suggest that the "Logic" code could indeed be a list of the Order Of Events. After all they are independant sections.

Call out for each Event...

Just what my Master Plan said.

But my feeling is that it will make it rather difficult to keep things consistent and will result in a lot of code redundancy.

Does anyone really object to writing the engine modules in python so we can combine it into a single 'engine' module?

I don't disagree per se, I just don't really see technically how that would work. "calling out" within the same language is easy (i.e. have each order of event or group of events a separate modules and call them to progressively construct the 'next turn'). Calling out between languages makes it messy on a number of fronts:

- installation issues (if you make a c program, someone else a .net program and another person a perl script, anyone running the engine would need to compile the C, have a .net and perl interpreter, and get all this working together in a pipeline.

- code re-use. Probably quite a bit of events use similar pieces of code, if only for manipulating the data structure. If we use different languages, this will become really difficult.

What I meant with a "modular architecture" is to split the project up into a number of components, but the "engine" would be one of the components; "client", "automation", "turn processing", "AI" being other components.

It is always interesting how disagreements remain hidden until you actually start making things concrete

1) The "engine" is responsible to turning universe+orders into a new universe.
2) Some other program (e.g. the current starserver stub) is responsible to handling the external interface, validating and merging files, keeping track of state, etc etc.
3) The engine consists of approximately* one module for each item in the order of events

4) Each module takes universe+orders as input and outputs the new universe (optionally plus the orders)

python-pseudocode for the engine (taking http://www.starsfaq.com/order_events.htm as reference)

def process_turn(universe, orders):
universe = scrapping_fleets(universe, orders)
universe = manual_load(universe, orders)
universe = wp0_unload(universe, orders)
....
universe = remote_terraform(universe, orders)
return universe

1) How is state encoded and passed between modules? My vote (at least for the time being) is json, since it is flexible and easy to make changes to. XML is imho too cumbersome to parse and manipulate, plain text is too fragile.

2) How are modules called/coded. I would still really argue against writing modules in different languages* and using system calls, but of course that is possible.

However, I would think that the logic in most modules is not actually that difficult, and porting existing e.g. C++ modules to python (or python to C) should be not too much work compared to making sure that existing modules deal with the state as agreed on in (1), which is necessary anyways.

we're unlikely to have single servers needing to process millions of games (and we could always fire up another server

extra outputs are needed though - messages for each player (and maybe battle videos etc, possibly a generic "m file block" return?)

Does it seem logical to make a "universe orders" blob out of all input files?

Keep it fully interpreted. no need for speed here (we're unlikely to have single servers needing to process millions of games (and we could always fire up another server at that point - open source ftw )

Need to read up on json as a format - csv would suffice in my mind - extra outputs are needed though - messages for each player (and maybe battle videos etc, possibly a generic "m file block" return?)

- pop_growth iterates over the planets. If the planet is populated, it looks up the owner and multiplies population by growth rate

My reason for separating universe and orders is that orders never change during processing, and universe changes all the time. Also, it makes sense conceptually. We could even split into universe, state, and orders later, as planet names, locations and race files are invariant

mrvan wrote on Sun, 01 June 2014 21:43

- pop_growth iterates over the planets. If the planet is populated, it looks up the owner and multiplies population by growth rate

Funny that, I'd rather do it the other way around, 1st getting the relevant race params (once) then iterating along that race's planet list. Not only would I avoid uninhabited planets, but it could also be better combined with the rest of the "Production" step.

mrvan wrote on Sun, 01 June 2014 20:43

My reason for separating universe and orders is that orders never change during processing, and universe changes all the time. Also, it makes sense conceptually. We could even split into universe, state, and orders later, as planet names, locations and race files are invariant

Sorry, I meant a glob of all orders, so the processing was done on a glob of orders, not a set of 6,8,... files

Merge the 6 order files, then split according to OOE, then pass each split to the relevant handler.

You would need a collection of csv files (for planets, fleets, etc), so that adds some complexity.

JSON is a key-value format, it essentially allows 'objects' to have keys with values that can be primitives, more objects, or lists.

Any csv format, say headers a,b,c and rows 1,2,3 and 4,5,6 can be trivially converted into a (more verbose) json file [{"a": 1, "b": 2, "c":3}, {"a":4, "b":5, "c":6}]. The verbosity is of course a drawback, but it makes it easier to read/write as a human and gives more flexibility for e.g. adding keys later, ommitting certain keys for certain rows, adding embedded 'rows' (for example for ships in a fleet) etc.

Merge the 6 order files, then split according to OOE, then pass each split to the relevant handler.

I would say, have a go at it. I didn't actually really think about optimizing, just about doing something easy but not completely trivial.

(although at the moment there is no 'planet list per player', so the best we can do without changing the universe definition is first getting all races to prevent the repeated lookup)

mrvan wrote on Sun, 01 June 2014 22:00

You would need a collection of csv files (for planets, fleets, etc), so that adds some complexity.

Not too much, I hope. There's a bunch different "data tables" that need to be considered, and it makes sense to keep 'em apart, even if it's just as independent chunks of the same json file.

* race params (all races together? makes sense, but sounds... weird)
* Univ params, including the techtree (plus hull defs & fuel tables). PRT and LRT params. HWs?
* fleets (incl Ship designs), planets, diplo settings, research status, battle plans, default Qs
* messages? (at least player-to-player) Multi-turn orders? Minefields. Packets. Transport Orders.
* battle reports, MTs, WormHoles, comets, player_orders, salvage, scores, etc.

I guess things like deleting and creating designs are all orders, as are things like merging a fleet and giving the new fleet orders. However, we need to think of how to give orders to a newly created fleet or build ships of a newly created design. Does the client assign an ID? How do you prevent clashes? UUIDs? player-specific fleet/design numbers? And I suppose that something like 'deleting a design' is even earlier in the order of events than scrapping. But we will run into these and related issues soon enough

XAPBob wrote on Sun, 01 June 2014 20:37

we're unlikely to have single servers needing to process millions of games (and we could always fire up another server

I was thinking of games with perhaps more than a couple thousand stars and fleets, and more than a dozen+ players... Maybe in the future.

extra outputs are needed though - messages for each player (and maybe battle videos etc, possibly a generic "m file block" return?)

Meh - you're talking tiny numbers. Seriously it doesn't matter if it takes more than a few hundred milliseconds to generate a turn.
When we're talking about an unlimited "generated on demand" universe then we'll talk again...

Yes I was thinking along the lines of the current VCR, the client then renders a video in anything from ascci art to 3D spectacular...
Something along the lines of chess notation might be useful here?