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.