Author Topic: Pulsar 4X  (Read 32485 times)

0 Members and 1 Guest are viewing this topic.

Offline Redshirt

  • Sub-Lieutenant
  • ******
  • R
  • Posts: 121
Re: Pulsar 4X
« Reply #15 on: August 09, 2012, 10:50:39 AM »
I'm usually fairly busy, but I'd like to help out where I can on this. I've got several years of experience as a lead tester for PC games; once you've got a working engine, I can take a look and see if I can write a test plan.

Once the engine's working, I can also contribute ideas for races, tech, etc.
Living up to my username. . .
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5654
  • Thanked: 366 times
  • Forum Admin
  • Discord Username: icehawke
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2022 Supporter 2022 Supporter : Donate for 2022
    Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Pulsar 4X
« Reply #16 on: August 09, 2012, 11:08:10 AM »
Ok, time to read the fine print.

Bitbucket: Provides private repository hosting... for up to 5 contributors. That should cover a solid core of primary developers, but makes accessing the crowd of associate coders expressing interest difficult. This might not work after all.

SourceForge: Free hosting. May support both Mercurial and Git. Requires us to explicitly choose an OSI-approved licence.

Github: What McBear said. I think I also saw a use clause that explicitly makes us legally liable for any lawsuit against Github in regard to our code.

No matter what you guys decide, I'll give you the best support here that I can :)

Offline HaliRyan

  • Lt. Commander
  • ********
  • H
  • Posts: 232
Re: Pulsar 4X
« Reply #17 on: August 09, 2012, 05:55:19 PM »
I sent a private message, but I'll post here as well.

I have some moderate experience with C#, VB.net, and C++. I'd love to lend a hand with this and I have a glut of free time due to my employment situation (which is to say, a lack thereof).
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5654
  • Thanked: 366 times
  • Forum Admin
  • Discord Username: icehawke
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2022 Supporter 2022 Supporter : Donate for 2022
    Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Pulsar 4X
« Reply #18 on: August 09, 2012, 06:17:38 PM »
... I have a glut of free time due to my employment situation (which is to say, a lack thereof).

Welcome to the club.

Offline Antagonist (OP)

  • Pulsar 4x Dev
  • Sub-Lieutenant
  • *
  • A
  • Posts: 124
Re: Pulsar 4X
« Reply #19 on: August 09, 2012, 06:23:30 PM »
I'm willing to go with any source control. Since my bad experiences with git seems to be unique to myself, I'm willing to give it another shot.

I have never worked with github before, but from the discussion it appears that MrBear seems to have extensive experience with it and the only real STRONG preference for any source control over another.  His experience would also be useful for any advanced tasks we may need to perform.  I'm not too worried about the legally liable from lawsuits thing, since the person with the most standing to sue is Steve and he seems okay with it all, not to mention the fact that we aren't making money from this.

Re:sublight's proposed project subdivision:

I have 2 issues.  First is that the entities classes, aka new Star, new Starship, etc, should all be together with one another.  I would also prefer to keep them close to the main game logic library. If your proposed design keeps entities there, but you are suggesting only seperating the say SQLlite or whatever database specific stuff, I can support that.  I feel we should pick a db engine and stick with it, but it is possible to in the future need to say have something that supports MSSQL or MySQL.  Just... I personally feel that can still be kept in same project.

I would like to avoid situations where we spawn a dozen dlls in the form of: 'Pulsar4XCombat.dll' that we need in our game.  If needed we can go that route, but I don't see any advantage to keeping stuff THAT modularized and decoupled.


Okay, I'd like a show of hands and opinions on some more choices:

Logger - log4j good for everyone?

ORM - What are you guys familiar with? Entity Framework is out due to portability. Two options seen so far is LINQ to SQL or nHibernate.  I don't think either is WRONG, but I'm willing to have us use the one most ppl are familiar with.  If you have worked with either, or have a 3rd option, please say.

Database - SQLlite has been mentioned, but I have 0 experience with it. Since we're talking multi-platform it excludes MSSQL, MSSQL Express and MSSQL CE, so it leaves me in the noob department.  Please discuss and suggest something. I would however advise we try for our PRIMARY SUPPORTED (no reason can't eventually support multiple, but start with 1) database is that it is file based, aka gives us something players can use and email one another saved games, rather than what MSSQL and MySQL usually does where you're not expected to ever manually touch the db file.

Scripting - One thing I would like is if a lot of the data files or stuff like AI was kept in decompiled scripts the player could easier modify. I don't want this stuff distributed and need DB access to modify. Perhaps when you start a new game, the data files are used as initial settings to populate your game file to prevent you messing stuff up by changing techs midgame, I dunno. Perhaps customize the tech tree, or modify the AI of the opponents, change stats of hulls and techs, as well as modify or add to the orders like 'Refuel when fuel below 30%'.  Its still up in the air how much we will put into scripts and how much hardcoded, but we should consider designing in the ability to use scripts.  Our options are lua, js, vb, json, etc, but one suggestion I'd like to forward is to use C#. Using reflection it is possible to RUNTIME COMPILE decompiled C# files distributed with the game.  This will allow modding capability without access to the source (even if open source makes that easy).

Windowing - We seem to be moving towards the Winforms side? I have gotten a few more help offers from ppl in PM, if any of you know your UI, we can still do with someone dedicated to this.  Or GTK#, but either way, this is like a developer position wide open for whoever wants to apply.

Design Document - We have a wiki, we should start using it. We need ideas and a roadmap.  The first bit of development is fine, we need to get planets and systems and a time passing system and all that up. Whatever game design we choose a lot of that is intuitive. But after that it gets harder. Will we support multiple races on one planet? Multiple factions each with multiple races on the same planet? Do new ship designs need to be researched? New ship parts? What parts are available? What does tech tree look like? How fast do ships move?  A lot of this we can just copy over from Aurora, but some of it we can do better, like having contstruction 'ticks' shorter than 4 days.  Even the stuff that we copy from Aurora we need to track down the formulas and preferably lay out.

Multi-threaded - This is a fact of modern PCs and a VERY requested feature of Aurora. This will need to be worked into the time and simulation system. We need to figure out what will and what will not create race conditions and we need to establish standards so that we can make what needs to be multithreadsafe, multithreadsafe. I know many libraries are available, we need to choose one and start establishing the standards. These standards are not just for consistency, but also so that devs NOT familiar with multithreaded programming can still contribute and maintain the code. A single person should propably be assigned to the skeletal framework of this initially however.

UI - Again, this is IMPORTANT.  The map, the windows, mockups. Whatever windowing system we use, we need to know how the main window should look like. The system and planetary maps is still up in the air, depends on whether anyone is gonna step forward as a OpenGL dev, but yeah.

There's propably still more decisions and options we should look at, but its after 1AM so sleep time now.


EDIT:
@clement: We need to have a nice LOOONG chat. I like what I am hearing from you. Your efforts definitely seem to mirror my own.

I dunno what your approach is, but what I did was take the universe's OOP approach to it [http://universe.sourceforge.net/], but used the actual code and functions from [http://jms.fmipa.itb.ac.id/index.php/jms/article/view/277/293] which is practically identical to that of TerraJ just with some changes, such as extending the dust distance and altering the calculations for safe distances between the planets. It also includes some nBody stuff, but that is not all that involved with the base accrete system.

PROBLEM is... this whole piece of tech based on Dole's stuff is OLD. No real hot jupiters for instance. Also, the planet type system is completely wrong, but not that hard to rewrite.  Also, albedos need a serious look at since in this game there will be the ability to change it. Oh, and doesn't support binary or trinary systems, but that isn't too hard to add by just giving stars forbidden zones. And shouldn't allow moons within the Roche limit. Actually take a look at [http://en.wikipedia.org/wiki/User:GabrielVelasquez/101_errors_of_Stargen] for some issues with the system. Linked doc is written from a 'Screw you' perspective but a lot of the points are valid.

Okay, and that is just the START of this rant.  Gas and Dust densities are not guaranteed to be constant.  For one it depends on the snowline where a lot of the water 'gas' turns to water 'dust', which affects accretion.  Collissions is another big one, since the dole system assumes fully elastic collissions where the two planets collide and create a new planet, without any mass lost or considering near misses or planetary orbital drifts.  I would like it if code could allow collissions to help create asteroid belts, where after a particularly violent collission the planet breaks up and forms a belt.  Studies like [http://www.lpi.usra.edu/meetings/lpsc2003/pdf/2000.pdf] further confuse the issue by making the amount of water available on the inner planets dependant on the formation and locations of the gas giants in the system.

Okay... part of this is my engineer mind trying to overdo this. Absolute scientific accuracy isn't needed, just fun and entertaining is. But yeah... getting a 'basic' system up isn't hard. Its improving it to be better that is breaking my brain.

------------------------

If anyone is friends with cosmologists, I would really LOVE the answer as well as the relevant papers and formulas for the following, would really really help make a better star gen system:

Under modern post-1980s cosmology understanding, assume a Star of mass M and Luminosity L.  This planet has a protodisc with gas density G and dust density D. Only one planet ever forms around this star, at orbital distance A and eccentricity E. What would the mass of the accreted dust and gas be of this planet after it has completed its formation and cleared out its feeding zone?

----------------------

EDIT2: The system I'm talking about and modifying, as well as clement seems to be talking about is basically a variation of [http://www.eldacur.com/~brons/NerdCorner/StarGen/StarGen.html].  Real cool, but old.

As for everyone offering help... there is currently the original 3 devs: Me, sublight and MrBear. Our ONLY claim to this project is not being best or greatest coders, but just being the first 3 to say 'That's cool! I'll help.' We can really do with more help, we're just still in initial part where we decide what to do. Even if you don't do C#, we can do with help by posting ideas on the ideas thread and responding in this thread about ideas or systems we can use: 'Use github! It worked for me and my project!' 'Don't use SQLlite, it has problem x!' etc.  Best way to help right now is talking, giving ideas. You don't need permission for that.
« Last Edit: August 09, 2012, 07:39:41 PM by Antagonist »
 

Offline sublight

  • Moderator
  • Captain
  • *****
  • s
  • Posts: 592
  • Thanked: 17 times
Re: Pulsar 4X
« Reply #20 on: August 09, 2012, 10:09:39 PM »
Project Division: My suggestion was based on perceived data flow. The UI and GameEngine each take turns updating the database depending on if time is advancing or not.

MultiThreading My recommendation would be to simply split individual star system time advance updates into their own threads. My thoughts are this would give us the best system performance for the least coding effort.

Developers: I too would prefer having another primary developer or two. I feel three is a minimum. Four or five would be ideal.
At the moment our two greatest needs are the UI and the Wiki content/ticket tracking. If needed I can do one or assist with both, but I don't think I can be the primary on both.

Development Phases and Objectives
Tentatively:

Phase 1: Pre-Planning (We are here)
Primary Ideas of interest include what the game should look like and what languages/tools should be used in making it.
- Form a core Developer Team
- Decide on languages, repositories, and tools.
- Sketch out game structure and UI appearance.

Phase 2: Pre-Alpha: This is where we start coding.
Phase 3: Alpha: This is where we make Pulsar4x playable.
Phase 4: Beta: ?????
Phase 5: Perpetual Beta:


I'll take another look at git and githost and see about breaking ground with an official repository some time this weekend.
 

Offline clement

  • Pulsar 4x Dev
  • Sub-Lieutenant
  • *
  • c
  • Posts: 137
  • Thanked: 13 times
Re: Pulsar 4X
« Reply #21 on: August 09, 2012, 10:38:56 PM »
@Antagonist I can try to do some code clean up on the system generation code I have. It is a derivative work of Stargen with some changes to the moon creation logic. I have an idea on how to include multi-star systems, just have not been able to do any coding on it recently (work has been very crazy). I will read those articles you linked to as soon as I have a chance.

Regarding making the Stargen code better, I have always liked the approach of get something that works, get it out and being used, and then iteratively make it better. Trying to get it just right means no one is giving you any feedback.

Databases: If you want to be able to work on Windows/Mac/Linux systems I would suggest Sqlite. With Sqlite you can write to any number of databases and it is very easy to create a new db in game on the fly. To that end, you can have a bootstrap database that stores in-game data like different templates for ship/person/star namings and all of the technology (this data could also be stored in config files (JSON or XML) if we wanted them to be easily human editable). Then each game can be given its own db to store all the needed data for it. It would be very easy to create the new db file and then run a batch of create table sql commands on it to get it setup. I have done this approach in an Android app I am working on.

Logging: Log4Net http://logging.apache.org/log4net/ is the .NET version of Log4J

ORM: I am a big fan of an ORM called Dapper http://code.google.com/p/dapper-dot-net/ It was created by the team at Stack Overflow and is very high speed. The only thing faster than it that I know of is direct usage of the DataReader object. At work we use a mix of direct DataReader loads and Dapper. It is very easy and straight forward to use. On the other hand, ORM technology should be of major significance in the project. I say this because I would expect there to be an initial load of bootstrapping data when the game application starts and then a second data load when a game file is loaded. After that I would suggest all game data is kept in memory and only written to the database when saving the game. The saves could be automated to take place every in-game month or some other setting like that. This would greatly improve performance and you could save the game out as an entire Sqlite database which would allow you to avoid any leakage of data from one game to another or corruption of all games by an application error in one game.

Scripting: I would suggest LUA for scripting with JSON for data storage in files where you don't want the data in a bootstrap database. On the other hand, for a lot of things like individual orders, it would be a lot simpler on the first pass implementation to simply make each possible order as a code construct that is compiled into the game. The new run-time code compilation stuff in .NET is pretty neat but it has some big dangers that it introduces. If it has problems it can be difficult to identify if the issue is in the changes to made to the de-compiled code or if it is somewhere else.

Windowing: I have no experience with GTK# but would assume it is as easy to pickup as WinForms or WPF. It would give us multi-platform capability but is that capability needed right now?  WPF does have many very nice features related to UI manipulation and controls that I do not remember seeing in WinForms. I have not done any work in WinForms for probably 5-6 years though so I have probably missed some developments. I have done a few data collection/input utility apps as one offs at work that have used WPF and found it to be very quick to throw together. It was very similar to what I remembered doing in WinForms just the markup and style of it is much more like HTML when doing the layout.

Design Document: I would recommend that for the first pass, all features and functionality be a re-implementation of the Aurora functionality. Imitation is the best form of flattery. The danger of trying to pick and choose and change the way parts work is that it means the game is not done and usable in a form that can be played with and tested. I am currently wrapping of a re-platforming at work of a piece of 10 year old software. We made the decision early on that we would not add any new features for version 1, it would only have the functionality of the original software. This gave us a great deal of freedom in defining the individual tasks and requirements but also let us take all the requested features and changes, put them in the backlog and then design our new system to allow the future inclusion of those backlog items. Obviously, all of the above does not mean re-implementing bugs in the current system.

Multi-threading: Fortunately multi-threading is very easy in .NET and C# especially in 4.0. With 4.0 a new threading mechanism was added under the System.Threading.Tasks namespace http://msdn.microsoft.com/en-us/library/system.threading.tasks This includes the Parallel and Task object which when used can allow very quick and powerful multi-threading. If you are using thread safe collection objects from the System.Collections.Concurrent namespace http://msdn.microsoft.com/en-us/library/system.collections.concurrent then there are very few of the issues that you used to have to constantly watch out for involving locks. The Parallel object will allow you to give it a task to perform (ie: a delegate) and it will analyze the total number of tasks to be performed across the collection of data and spin up an appropriate number of threads for you. As the tasks complete it will increase/decrease the number of worker threads based on how much time and cpu load the tasks are using. It is very powerful and we use it extensively in our software.

UI: I have a mockup I will try to attach to this post that I did for what I was playing around with in my spare time. Like I mentioned before I was pulling inspiration from other games as well and it won't both me if no one likes it.

Regarding how to break up the entire applicaiton into projects, I suggest having 2 projects in the solution to start with, ignoring any unit test projects.
- Core Engine Project - this would contain the following
  • Data Objects
  • DB persistence code
  • engine for processing time
  • core AI
  • research
  • anything else to run the game

- UI Project - this would only contain code for showing the results and data from the core engine project on the screen

This approach will allow for a UI to be done with GTK#, WPF, Winform or whatever. In fact, different UIs could be made to sit on the same core engine. You could deploy this behind a web based UI and run it through a browser. In addition as things get more fully developed, things like the AI can be pulled out of the core engine and made separate dlls for expansion if need be. However, breaking them out now, when there is no code and runs the risk of over complicating the design early on. I put database access with the core engine simply because the odds of it changing are slim to none once serious development is underway.

Rich
 

Offline Nathan_

  • Pulsar 4x Dev
  • Commodore
  • *
  • N
  • Posts: 701
Re: Pulsar 4X
« Reply #22 on: August 09, 2012, 10:58:35 PM »
Quote
The system and planetary maps is still up in the air, depends on whether anyone is gonna step forward as a OpenGL dev, but yeah.
The system map we can basically copy from Aurora(which is an excellent default policy), opengl can handle 2d drawing just fine. the planetary map is going to be an issue, one of the issues that I remember in an interview with a worker on an indie RTS was just what a giant pain tiles were. even a star control 2 like map would probably be overly much to expect.
« Last Edit: August 09, 2012, 11:00:27 PM by Nathan_ »
 

Offline clement

  • Pulsar 4x Dev
  • Sub-Lieutenant
  • *
  • c
  • Posts: 137
  • Thanked: 13 times
Re: Pulsar 4X
« Reply #23 on: August 09, 2012, 11:16:46 PM »
I would not really worry about using OpenGL if the game is still going to be Aurora-esque in its interface.

For the maps just put a ScrollViewer on the screen with a Canvas inside of it. Extend the Shape object with some custom drawing code to add extra info around a circle/triangle on the canvas for each object that needs to be represented, star/planetary object/ship/missile....

Simpler in the short term and then later on if the UI is an issue it can be re-worked with acceleration via opengl or DirectX.  If we were to use WPF, it will automatically route its rendering through DirectX and the graphics card if the graphics card supports hardware acceleration (ie: DirectX 7.0 or greater).
 

Offline MrBear

  • Pulsar 4x Dev
  • Leading Rate
  • *
  • M
  • Posts: 8
Re: Pulsar 4X
« Reply #24 on: August 10, 2012, 09:02:19 AM »
Lua is pretty damn easy to integrate with C#, so I'd be very much in favor of taking that route - it's really not too much more than exposing the functions and objects that can be accessed from the Lua scripts.

If we're using SQLite (which I suspect we will be), then it would be pretty easy to let Lua scripts have some scratch space of their own in the DB as well.  However, even though we should approach the code as though it will scriptable, it's really not something that needs to be thought about too much until we're at a point where we've got something cobbled together IMO.
 

Offline SnopyDogy

  • Pulsar 4x Dev
  • Chief Petty Officer
  • *
  • Posts: 41
  • Pulsar4x Dev
    • Pulsar4x
Re: Pulsar 4X
« Reply #25 on: August 10, 2012, 11:53:49 PM »
Quote from: sublight link=topic=5176. msg52873#msg52873 date=1344426233
GTK was a suggestion of familiarity.  I know enough GTK to coordinate/do UI development myself as needed, and have done basic graphics display in it with the Cairo 2D graphics library. 

WinForm with OpenTK could work, but would require someone besides me to be a primary graphics/UI contributor.

Thoughts? Volunteers?

I don’t have much UI/OpenGL experience but I’d be willing to take on the role of UI developer/OpenGL if asked.

For my background, I am currently studying a Games Programing course (6 months in to the 2 year course).  Most of my experience to date is with C++ and 2D rendering with OpenGL.   I have some previous experience with C#/WinForms but it’s been a long time so I’m going to have to dive back in Learn it again.

@clement If you’re going to use OpenGL as part of the UI then you’re better off using it from the beginning.  A toolkit like OpenTK makes it easy enough to implement that doing anything else in the short term would likely just be a waste of effort.  Also as MrBear stated OpenTK also gives you Input, Sound and a 3d Maths library (not to mention OpenCL) for free too.
 

Offline MrBear

  • Pulsar 4x Dev
  • Leading Rate
  • *
  • M
  • Posts: 8
Re: Pulsar 4X
« Reply #26 on: August 11, 2012, 04:38:29 AM »
Oh, good point on OpenCL - it's making me think that orbital mechanics calculations might be very well suited for offloading to the GPU to make them faster.  They're really not so different from sets of matrix transforms.

I'd note thought that this falls under the "interesting idea" category rather than the "we should do this category"!
 

Offline SnopyDogy

  • Pulsar 4x Dev
  • Chief Petty Officer
  • *
  • Posts: 41
  • Pulsar4x Dev
    • Pulsar4x
Re: Pulsar 4X
« Reply #27 on: August 11, 2012, 06:04:28 AM »
Quote from: MrBear link=topic=5176. msg53064#msg53064 date=1344677909
Oh, good point on OpenCL - it's making me think that orbital mechanics calculations might be very well suited for offloading to the GPU to make them faster.   They're really not so different from sets of matrix transforms. 

I'd note thought that this falls under the "interesting idea" category rather than the "we should do this category"!

My thoughts exactly.  Though I do agree that it’s something we should think about later rather than try right of the bat.
 

Offline Antagonist (OP)

  • Pulsar 4x Dev
  • Sub-Lieutenant
  • *
  • A
  • Posts: 124
Re: Pulsar 4X
« Reply #28 on: August 11, 2012, 12:35:19 PM »
I have some experience with OpenCL and more experience with CUDA. My main issue with any approach like this though is that it requires graphics hardware to take advantage of, and for those without suitable hardware it will need a fallback (yes, I know in theory the CPU is fallback already as an OpenCL host, but in practice it is annoying).

Why not just make a decent enough fallback?  I doubt we will NEED OpenCL to do anything here, that is if you want to do a nbody simulation with 10 000 objects or advanced physics with many moving parts, something like orbits of relatively VERY FEW planets isn't really gonna stress the CPU here.

As for timing, I remember Steve thinking about making Aurora II realtime, that is, instead of clicking skip x days, it constantly and smoothly updates, just with ability to increase the speed.  We should consider this, even if it increases the computational requirements.


Anyway, noone has said anything about repository in a while, I assume then that github is an okay choice?  If so, sublight, mind creating us a repository?
 

Offline Redshirt

  • Sub-Lieutenant
  • ******
  • R
  • Posts: 121
Re: Pulsar 4X
« Reply #29 on: August 11, 2012, 03:10:47 PM »
Ahh no! I like turn based. Can you imagine trying to design a whole combat fleet while the clock ticks away? Unless, of course, the ability to pause is there.

Another thought- why limit the game to two dimensions? (Sorry, I probably just broke someone's brain.) Granted, the comets and dwarf planets like Pluto are outliers, and most system bodies stay on the elliptical plane, but if the calculations are streamlined... granted, the control scheme would start to get ugly quickly.

A note for the people doing system design- hot Jupiters that orbit a star at close range usually didn't start there. They started out far away, and obliterated everything in the inner system on their death spiral inwards to the star.
Living up to my username. . .