Python can easily manage large arrays and lists. If needed, packages like numpy/scipy can offer extremely fast matrix manipulation. If it could be done on a single floppy, it can certainly be done in python .

You can integrate C code in python seamlessly (you replace one module and the rest of the code doesn't notice the difference).

I meant developer-time efficient as pointed out by XAPBob.

can we somehow convince more of the community to come back if we have a more modern client? Developing a game for the <50 active users of this forum doesn't sound like a very efficient use of time (even if it can be good fun).

That's the key... can we make a game that's comoelling enough to attract new players.

Low barrier to play would be important,

POStars! client isn't that easy to get running nowadays.

Not sure that the old client id a good starting point, it fixes protocols etc poorly.

public/private key encryption of a 'NICE' Xml interface woyld be much better - and can be added later (assuming it's designed in early)

I would indeed not aim for compatability with the current stars client, unless it is trivial to convert the move / order files to some sort of nice format.

Multiple concurrent plays could actually be done as completely separate processes, so the global lock does not come into account. That is how web servers like nginx do it automatically, so that should be no problem. I am envisioning nginx+flask or something like that for the API, and if needed celery for the turn processing.

For the record, I currently use python 2.x and write in emacs, but probably 3.x is fine here.

Looks promising!

I can't quite fathom where/how I could send things like old design docs, working C/C++ modules, etc.

A couple notes: I don't think it's necessary to restrict messages to json.

The API could actually be hidden under convenient html forms, so those who want to use it directly could do so, while others could resort to plain old html-form-trickstery.

we would have to see per module whether it is best to rewrite as python given the existing knowledge, or try to use the existing C module.

allowing different input formats is opening a nasty can of worms in terms of maintainability.

there is nothing against writing a human-friendly web server on top of the core API that accepts html forms and translates these into core API calls. For most of the non-game interaction (ie creating games, browsing games, user management etc) this is probably the way to go. In a sense, this web server is "just another client" as far as the core server is concerned.

mrvan wrote on Sat, 31 May 2014 00:26

we would have to see per module whether it is best to rewrite as python given the existing knowledge, or try to use the existing C module.

Actually, several of the more "finished" modules are Javascript. A few are C, and the rest are just pseudo-code and design docs. Lots of docs.

I guessed so. And thus the "server/client" concept passes its 1st test with flying colors. We should tell this guy ASAP and get him onboard too.

it shouldn't be too difficult to start implementing these docs into simple python modules.

We don't need to worry about performance yet, we can always optimize later.

The most interesting file is probably stars.py, which contains the actual game logic of stars, as yet limited to fleets moving around and all planet population always growing by 10% . The intention would be to recreate the whole "order of events" there.

Using a mongo database means that objects are saved between sessions, which is nice, and that you can just add/remove attributes as desired on all objects: mongo is a very flexible "document database" that doesn't use a predefined schema. This is ideal for developing/prototyping, and we can always move to a regular database if needed

We should also create test cases to check whether the outcome of the game logic corresponds to what we know stars should do.

mrvan wrote on Sun, 01 June 2014 02:04

The most interesting file is probably stars.py, which contains the actual game logic of stars, as yet limited to fleets moving around and all planet population always growing by 10% . The intention would be to recreate the whole "order of events" there.

You mean, everything inside the same file, and all in python? Weren't we going to use all kinds of independent modules strung together?

Quote:

We should also create test cases to check whether the outcome of the game logic corresponds to what we know stars should do.

Which reminds me: isn't it a bit cumbersome to ask everybody to install a web server just to run a server program? Would it be too hard to have a "standalone" server that could be used for testbedding, battlesimming, off-line playing and such? Perhaps the full-featured "web" server could call that one underneath?

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...

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...

Hmm. I feel that the 'engine' should be a coherent piece of code. I'm pretty sure it should be split over multiple modules, but my approach is generally to not do too much designing up front and refactor as needed, including in this case moving code out to different modules.

Using modules in different languages is a bit of a pain, I think, as it makes it exponentially more difficult for people to run the engine.

Also, it makes it more difficult to check consistency, prevent bugs, etc. How yould you propose getting this to work?

I will split the current repository into two different ones, a 'stars engine' and 'stars server' (which obviously uses the engine underneath).