Home » Stars! Clones, Extensions, Modding » Stars! Extensions » Stars Core Engine
Stars Core Engine |
Thu, 30 October 2014 04:05  |
|
Shadow Whist |  | Chief Warrant Officer 2 | Messages: 167
Registered: August 2003 Location: Vancouver, WA | |
|
This is a project I have been working on for a few months.
https://github.com/jurlaub/StarsCoreEngine
Revised StarsCoreEngine Internal Structure:
https:// docs.google.com/drawings/d/1rE61lFW4LO713llX9rlSGZ4sUVmTcOb8 _4Co501PzH0/edit?usp=sharing
Possible Stars! game structure that includes the StarsCoreEngine
https:// docs.google.com/drawings/d/1aE9Fp3Aul-DSjEzRmPvZQcCKjugAvtQS Q83G45UGQnA/edit?usp=sharing
While I hate the idea of 'abandoning' the other stars! efforts and beginning (yet Another!) stars project, it seems like it needs to be done. (Hopefully, it is not too late! ) Considering the past, I believe a new approach is needed. I really liked a number of ideas from the Stars 3 topic found in the Bar. From that discussion, I derived the following:
- Developer time is at a premium so use Python for development
- Build the core engine (i.e. limit project scope)
- Use JSON to communicate outside the core engine
Considering that a project like this is similar to undertaking one to three large universe stars games - (say 12 Gates, Rabid Weasels in a Box II-b, and Diadachi Wars II ) - I want to make it as simple and easy as possible. I think Python allows for this. I also enjoy developing in it. (Whereas I looked at the Freestars code ~5 separate times in the last few months and wasn't very excited about it.)
Creating the core engine with a standard interface allows other projects to complete the UI and any other components. Those other projects could include: Android, iOS, and/or web browser based UI. The core engine is also a smaller chunk to swallow by one's self (if necessary).
The structure makes extensive use of Python objects and dictionaries. It is still early in the project but I think the internal design (above link) is solid. Almost everything in the game is a Space Object and inherits from that primary object class. Many of the Order of Event actions can be written as functions inside the class. The others will do stuff to the Space Objects.
The initial project objectives are laid out in the wiki https://github.com/jurlaub/StarsCoreEngine/wiki (actually two lists - I like "The other list" better. ) My first focus was to create a outline to work within. And then to prove that the pickle module will work and build a test framework. That was finished last week. I am now working on creating support for generating a game universe (or 2+ ) from a standard template (basic part is done) and then modifying that standard template. After the basic structure is finished, it will be easier for others to contribute (at least that is my hope). (Oh, and I am in the "close enough" "& lets get into the ball-park" camp. Because we need to get this done! )
Let me know what you think,
Thanks!
SW
[Updated on: Thu, 30 October 2014 04:10]
Rapid Weasel News Agency, We've got the Rabid!Report message to a moderator
|
|
| | | |
Re: Stars Core Engine |
Tue, 11 November 2014 16:21   |
|
skoormit |  | Lieutenant | Messages: 665
Registered: July 2008 Location: Alabama | |
|
Shadow Whist wrote on Tue, 11 November 2014 00:39
This weekend I started thinking a bit too hard about the interaction between the Player object, a Player Race design, and a player's fleets.
Maybe it's less ambiguous if the model uses "Race" rather than "Player" to refer to the in-game entity. I.e.:
"Players" create race designs.
The game creation engine, to create a game, requires a race design for each player. (These can all be different, or all the same, etc.)
The game creation engine creates a "Race" for each player, based on the race design for that player.
A Race has- a PRT (determined at game creation time from the race design)
- 0 or more LRTs (determined as above)
- Hab settings (determined as above)
- Econ Settings (determined as above)
- Tech Settings (determined as above)
- 0+ Fleets
- 0+ Tech Levels (and 0+ resources of credit toward the next level of each of the 6 research fields)
- 0-16 Ship Designs
- 0-16 Starbase Designs
- Intel: current info on currently scanned objects (planets, fleets, wormholes, salvage, packets, MT), old info on planets previously scanned but not currently scanned, memory of last ship design seen for each enemy ship slot
That approach makes it seem natural that the Race object owns the Fleet objects, rather than the "Game" object, since all fleets have exactly one owner.
(I am considering the MT a space object rather than a fleet. Tomato, tomahto, perhaps.)
Since a planet has 0 or 1 owners, the Game object owns the Planet objects. Races always have current perfect info on Planets that they control. (The Order of Events engine, when it creates the current turn's intel for each Race, knows this.)
Just my top-of-head, back-of-napkin thoughts. Use, discard, ignore, etc., at your preference.
[Updated on: Tue, 11 November 2014 16:21]
What we need's a few good taters.Report message to a moderator
|
|
| | | | | | | | | | | | |
Goto Forum:
Current Time: Sun Mar 26 06:22:43 EDT 2023
|