Home » Stars! 2.6/7 » The Bar » Stars 3
|
Re: Stars 3 |
Wed, 28 May 2014 14:33 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
mrvan wrote on Wed, 28 May 2014 17:26Python 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 .
It was quite slow when floppies were mainstream.
I was thinking about managing relatively large scenarios, and of course many games going on at once, with many races sending and receiving their order files, hence the need for some sort of multithreading. Most calculations should be relatively simple, but there'd be a lot of them.
Quote:You can integrate C code in python seamlessly (you replace one module and the rest of the code doesn't notice the difference).
Ahhhh. Neat! Modularity for teh win!
Quote:I meant developer-time efficient as pointed out by XAPBob.
Of course. I was putting the cart before the horse. Blame my impatience!
Quote: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).
Fun could be excuse enough, but before worrying about improved clients, it'd be better/easier/faster to get a working bug-free server, that can work with future improved clients, and also with Nova and the Plain Old Stars! Client too.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
|
Re: Stars 3 |
Wed, 28 May 2014 14:42 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
XAPBob wrote on Wed, 28 May 2014 18:57That's the key... can we make a game that's comoelling enough to attract new players.
Low barrier to play would be important,
Imagine a new serverside "turn processor" that could interface seamlessly with the current Stars! client, or at least with Nova. That'd be the lowest barrier (even if aux tools were necessary to enable extra things like autobuild ships, bulk Q changes, etc.) and it would already offer something valuable: no nasty bugs and showstoppers, better traceability of inner workings, improved scenario creation, possible MM reductions, etc.
Things like better AIs, massive persistent universes, ladder-like competitions, 3D, etc, would come later.
About spreading the word, well, this is not the only place where players hang out and bash each other to smithereens.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| | | | |
Re: Stars 3 |
Thu, 29 May 2014 04:22 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
mrvan wrote on Wed, 28 May 2014 22:09I 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.
As long as it's easier/faster to get running than a brand-new client, yeah, why not. But if not, there's Nova. And there'll be others.
Quote: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.
Why do I feel like my colonists just found a cool alien artifact that's boosted my knowledge of www-Construction technologies by a few thousand Resources?
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| | |
Re: Stars 3 |
Fri, 30 May 2014 07:59 |
|
mrvan | | Officer Cadet 1st Year | Messages: 220
Registered: May 2014 | |
|
I've created a meeting point for the little fleets:
https://github.com/vanatteveldt/stars
I will try to find time to set up the most rudimentary basic server/client so people can start contributing. I've posted some starting thoughts in the readme, all comments welcome of course.
Edit: I've added the most basic server stub that runs and keeps track of 'games'. I realized that the repository should in fact only contain the server code, and any clients can have their own repository (to keep things modular).
The way github works is that if you want to contribute, you fork the repository, make changes, and file a 'pull request' which I can merge. At any point in time we can decide to create a more 'corporate' repository with multiple people with commit rights, but for the meantime I think a decentralized model makes sense. I will post some 'getting started' links for the various techniques we use as well.
Just for the record: I absolutely refuse to work with anything that is not open source and cross platform. All development starts in the open and will stay there. I picked GPLv2 as a license, but would be equally happy with affero (slightly more restrictive) or MIT/Apache (completely permissive).
[Updated on: Fri, 30 May 2014 09:09] Report message to a moderator
|
|
| |
Re: Stars 3 |
Fri, 30 May 2014 18:26 |
|
mrvan | | Officer Cadet 1st Year | Messages: 220
Registered: May 2014 | |
|
m.a@stars wrote on Fri, 30 May 2014 14:30Looks promising!
I can't quite fathom where/how I could send things like old design docs, working C/C++ modules, etc.
Cheers!
Well I would envision that once a very elementary 'turn processing' is in, a lot of knowledge will be needed to recreate all the various bits and pieces. Presumably, 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.
m.a@stars wrote on Fri, 30 May 2014 14:30
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.
Let me disagree and agree here . I think the "core server API" should be as clean as possible, and json is the current de facto standard for these things, and easy to manipulate in a variety of languages (including javascript, which I envision the core client to be written in). In any case, allowing different input formats is opening a nasty can of worms in terms of maintainability.
However, 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.
Report message to a moderator
|
|
|
Re: Stars 3 |
Sat, 31 May 2014 03:38 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
mrvan wrote on Sat, 31 May 2014 00:26we 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.
Quote:allowing different input formats is opening a nasty can of worms in terms of maintainability.
Probably yes, but it would allow more interoperability with clients whose "native" standard wasn't json. At least as a future option.
Quote: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.
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.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| | |
Re: Stars 3 |
Sat, 31 May 2014 20:04 |
|
mrvan | | Officer Cadet 1st Year | Messages: 220
Registered: May 2014 | |
|
OK I spent more time on this than I should have (programming is almost as addictive as playing stars! )
There is an update on github. I connected it to a mongo database and split the server file into logical units (views, models, stars). Since there is no client, you need to interact with the server directly, e.g. using curl or postman.
I've put up a curl demonstration session, where I create a game (which for now has two planets and a scout, and there are no different players yet), inspect the 'universe', and order the scout to move from Sol to Alpha, which he manages in two turns.
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. The module uses the object representations defined in models.py, which has simplistic models for planets, fleets, orders etc.
The main thing that needs to be done is that all game logic needs to be reimplemented in this file. Maybe it would be good to start with planetary production (as that is relatively easy), but hopefully different people can work on different parts simultaneously. Obviously, adding things there will require updating the object model as well, so we can for example have multiple players with different races etc, and record minerals and factories on planets. I think it is best to add stuff incrementally as we run into them. 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 (but mongo is used in some very serious production settings as well). But what I mean is that we can just add/rename/remove attributes from the object models without needing to reconfigure any database etc.
We should also create test cases to check whether the outcome of the game logic corresponds to what we know stars should do.
(obviously, it would also be nice to make a simple javascript client so that some of this becomes a little less abstract to those whose passion is not using the command line to send json documents to API's )
My next steps:
- Add player support
- Add some unit tests to show how these work
- Maybe get started on a simple javascript client
For anyone that is interested to contribute, please:
- Try to install and run the server and see if you can do something like the curl session posted above (see the readme on the github page)
- Think of what a nice and small contribution is to get started with
- Tell me what I need to do/explain/change to make it possible for you to make that small contribution
Report message to a moderator
|
|
| |
Re: Stars 3 |
Sun, 01 June 2014 05:51 |
|
mrvan | | Officer Cadet 1st Year | Messages: 220
Registered: May 2014 | |
|
AI is indeed pretty far down the list. Whether this will work depends on how many people will start contributing - I have neither the time nor the in-depth knowledge of stars required to finish this project by myself.
Update: I've added a simple unittest at https://github.com/vanatteveldt/stars/blob/master/tests/test _fleetmove.py . These unit tests are incredibly important in making sure that the engine behaves the way we expect it to. For example. I've coded in some assertions about travel: travel should go at warp^2, traveling a distance less than warp^2+1 should get there in one turn, the travel order should be duplicated for the next turn if the fleet didn't get there. We should add test cases as we add more functionality (e.g. mine fields affect fleet bevaviour, fuel usage, etc) and as we find bugs (e.g. if we discover that flying west doesn't work because someone messed up a minus, we add a test case first to confirm the wrong behaviour then fix it. Every 'push' to github is tested automatically, as you can see in the little 'build: passing' flag on https://github.com/vanatteveldt/stars.
I am going to stop working on this now for a while, so for anyone interested to help out, please checkout the source and think of something simple to contribute. Examples might be adding mines, planetary build order, hab values, adjust pop growth for crowding, etc. I think the next 'bigger' project should be to add players and races, and after that to think of how ships and fleets should be represented. But I think it is important to add some 'smaller' stuff first so people have an idea of how this is working.
[Updated on: Sun, 01 June 2014 05:52] Report message to a moderator
|
|
|
Re: Stars 3 |
Sun, 01 June 2014 06:26 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
mrvan wrote on Sun, 01 June 2014 02:04The 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: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
Sounds great. I don't think Stars! data is all too "relational" to begin with.
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?
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
|
Re: Stars 3 |
Sun, 01 June 2014 08:57 |
|
mrvan | | Officer Cadet 1st Year | Messages: 220
Registered: May 2014 | |
|
m.a@stars wrote on Sun, 01 June 2014 06:26mrvan wrote on Sun, 01 June 2014 02:04The 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?
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?
Of course, different clients and helper programs can all be in different languages, and they are strung together by all communicating with the (web) server.
m.a@stars wrote on Sun, 01 June 2014 06:26
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?
Actually, I think you're right. We should have a standalone repository that calculates the 'next turn' given the right information, and a web server to do all the messy management. That would also make it easier to contribute since it places less requirements on the engine part.
As soon as I have time, I will split the current repository into two different ones, a 'stars engine' and 'stars server' (which obviously uses the engine underneath).
[Updated on: Sun, 01 June 2014 08:58] Report message to a moderator
|
|
| |
Re: Stars 3 |
Sun, 01 June 2014 11:20 |
|
mrvan | | Officer Cadet 1st Year | Messages: 220
Registered: May 2014 | |
|
Quote: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 completely agree (and that is in fact how stars.py is now set up).
We could have different executable programs for each step and have them communicate using some 'universe+orders' format, and essentially do something like
cat universe | scrap | load | groundcombat | unload | ...
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?
[Updated on: Sun, 01 June 2014 11:21] Report message to a moderator
|
|
| |
Re: Stars 3 |
Sun, 01 June 2014 13:16 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
mrvan wrote on Sun, 01 June 2014 14:57Hmm. 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.
In my case, your approach would entail moving code from different modules to a single place and make everything coherent.
Quote: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.
You mean, because of dependencies and having different compilers to create executables? I'm guessing we'll need to distribute pre-compiled binaries of every thing anyway, won't we? Don't forget we want to leverage developers' time, by allowing each to code in their own preferred lingo, if at all possible.
Quote:Also, it makes it more difficult to check consistency, prevent bugs, etc. How yould you propose getting this to work?
Yeah, there's that risk. But it's the same for any big project, isn't it? You explained about the need for unit tests, so each module and coder will need theirs anyway.
Then we'll of course need to agree on how to communicate things from one step/module to the next, but there was gonna be plenty of that too. Reminds me a bit of usual Stars! Diplomacy, actually.
Style and technical consistency will be harder, but that should be less important if each module is actually independent, I guess. We'll need to come up with some "standard" for main "tables", logs, bug reports, and things like that, once we get things going, but it was gonna be necessary as soon as there was more than one coder, I think.
Quote:I will split the current repository into two different ones, a 'stars engine' and 'stars server' (which obviously uses the engine underneath).
Divide and conquer! Always conquer!
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
|
Goto Forum:
Current Time: Sun May 19 10:10:02 EDT 2024
|