Aurora II

[x2yzh9]

Hi! It's been a long time since I've posted, but I'm very curious as I've gotten back into aurora lately, is steve planning on making aurora II a game that supports multiple cores? I'm not sure if this is a easy or difficult task to accomplish, so I wouldn't be surprised of it's a no..It's just, someday I'd like to put the 7 CPU cores that came with this computer to use 

[Antagonist]

@ardem: Well, if you find your lead coder let me know, I might be able to contribute some stuff.

Hi! It's been a long time since I've posted, but I'm very curious as I've gotten back into aurora lately, is steve planning on making aurora II a game that supports multiple cores? I'm not sure if this is a easy or difficult task to accomplish, so I wouldn't be surprised of it's a no..It's just, someday I'd like to put the 7 CPU cores that came with this computer to use 

Far as I am aware Aurora II is on the 'TODO' pile for Steve, no real ETA on it.  As for multiple cores it depends more on implementation than technology. You can technically do something that works with multiple cores in Newtonian Aurora in VB6. It will just be... easier and faster once the switch to C# is done.

Programming for multiple cores isn't actually that much harder it is just more... complex. The issues with it isn't initial implementation, it is debugging afterwards when stuff goes wrong. That said, I'm pretty sure there is some low-hanging fruit that can be done with multiple cores, I am just not aware of any plans from Steve to do so soon.

[ardem]

@ardem: Well, if you find your lead coder let me know, I might be able to contribute some stuff.

Hahaha my post was not directed at me doing the hard slog or pick up the bat and ball and running with it, my post was directed at people dissuading others to attempt it, but also keeping it real.

My lead coder is working on a commercial game at the moment and if I ever get him back I rather him be working on a project we already started working on. Steve is right money always comes first over dreams unfortunately. Sorry not in space.

However I was saying I could contribute, if someone was to pick up a mantle, 3d modellers can contribute without the project falling apart, that is the good thing about us content guys. Coders a totally different kettle of fish.

@steve totally agree with everything you say.

[Antagonist]

@ardem: I know, it was just a form of agreement that a lead coder is needed to carry the project else it will go nowhere. And was referring to a hypothetical lead coder.

I think that Steve's reply can be considered permission to attempt an aurora-inspired game, which alleviates some of the concerns I've had about pursuing any such project, so I am now considering it more.

Of course, I know my own weaknesses, namely lack of design forsight as well as a tendency towards over-engineering which often saps enthusiasm before much can be accomplished.  Also I am far more interested in Stellar System generation and been playing and customizing systems like Stargen for a while now, while I have not often been good at stuff like research and unit and equipment design and balancing, something that leans more towards the design side.

I do C# programming professionally so I can offer a good starting point in creating a framework to link WPF with a Entity Framework<->SQL database system, which should eliminate any need for SQL statements in game logic, instead just working with classes and properties. If I take over this specialist part of the engine it should mean that the lead coder only really needs familiarity with WPF, experience with C#, time and most importantly a willingness to pursue it. Since Aurora is mostly a windows forms project any experience earned here is directly applicable to professional C# experience. I'm even willing to mentor. I just don't have the time and mental effort available to take responsibility for this non-commercial project.

It's not a high bar I'm setting here for the position of lead coder, what's needed most of all is responsibility and preferably a design in order to not fall into the traps Steve mentioned.

Anyone interested send me a PM with a basic design and if I'm convinced you won't just drop it the following day I can set this up.

[sloanjh]

a Entity Framework<->SQL database system,

I looked into this 6-8 months ago in the context of a personal project, and it seemed to me that the tools visual studio/.NET provides looked really good in principle, but lacked that last 5% to make them a complete system. 

The first issue was "If I change my class structure, how do I update my DB schema in such a way that the data in my existing DB isn't destroyed?"  My recollection is that their system will generate an SQL script that you can run to update the DB, but if you e.g. add a column to a table (because you've added a property to an object) then the script essentially executes "blow away the existing table, then recreate it with the new list of columns" rather than "add all new columns, remove all removed columns".  In other words, if you already had your class structure it was good at generating DB tables, but if you needed to change the class structures then it was equivalent to starting over.

Do you know how to coax the tools to do this automagically, or is there still a lot of grunt work involved copying things over and editting tables by hand?

The other thing I remember running into was with the non-license version SQL Server that you can ship with executables (SQL Server Express?)  I think the issue was that you couldn't add items to a table with a pre-specified key (i.e. you needed to let the table auto-generate the key), which meant that the automated binding tools didn't work right and you had to work around it in your class objects by hand.  Do you know if they've fixed this?

Like I said, this was a while back so I might have distorted the details, but the 50,000 foot observation that it didn't seem to fully work out of the box stands.  Or is that what you meant when you said "creating a framework" - there's some standard trick to automagically persist your DB information across architectural updates, but that one needs to implement that trick?

John

PS - This is just curiousity, not relevant to your Aurora efforts.

[Antagonist]

Yeah, what you just mentioned is exactly why most database middleware don't save you all that much effort. However, there are ways around it, especially since we're creating and maintaining our own database, and not integrating with some legacy system.

For start, I intend to make full use of EF Code First. This means that the database schema is automatically created for you based on your classes.

http://www.codeproject.com/Articles/318010/Entity-Framework-Code-First-Let-s-Try-It

You get full use of a database without actually touching or working with the database or SQL at all.  Recently EF 4.3 allows migrations, which in theory should allow saved games from old versions to be used in new, even if columns or the entire datastructure changes. This is less auto-magical and more a manual mapping in code, but still a nice feature. Your 'basic' database stuff will also be created and initialized in code. Without migrating, it basically wipes and recreates and reenters initialized data whenever the model changes. It works well in my experience. This also works with SQL CE, which is basically a file based database, which should allow transfer of saved games.

Most notably it will be MUCH faster and far less prone to corruption than the current Access implementation in Aurora.

Only real issue I can see with this is portability to linux and mac, due to both WPF and EF being windows technologies. That said, porting to an ASP.NET webserver or silverlight is much easier and allows for web play. A LATER feature of course.

The alternative is using nHibernate (Fluent is a good equivalent to CodeFirst and I've used it before) and a portable windowing system like Qt or something, but I am not very familiar in that.

[Bgreman]

Also keep in mind that persisting to a database-based format isn't the only way to skin this tiger.  I'm about 30% into an Aurora-like that persists to xml.  All the game files are in xml, which allows modding for people who aren't necessarily DB-literate.

[Antagonist]

I mean no insult to yourself but frakk XML.

Not ever for anything this size.

Settings and initial data MAYBE, but it is a data communication format, not so much a database format.

[sloanjh]

For start, I intend to make full use of EF Code First. This means that the database schema is automatically created for you based on your classes.

http://www.codeproject.com/Articles/318010/Entity-Framework-Code-First-Let-s-Try-It

You get full use of a database without actually touching or working with the database or SQL at all.  Recently EF 4.3 allows migrations, which in theory should allow saved games from old versions to be used in new, even if columns or the entire datastructure changes. This is less auto-magical and more a manual mapping in code, but still a nice feature. Your 'basic' database stuff will also be created and initialized in code. Without migrating, it basically wipes and recreates and reenters initialized data whenever the model changes. It works well in my experience. This also works with SQL CE, which is basically a file based database, which should allow transfer of saved games.

Actually, the Code-First stuff you linked to looks like the stuff I tried out.  The problem was that I didn't get the "and reenters initialized data" behavior (which I take it to mean "stuff that was already in the table it just wiped out") - the data was just gone.

And yes, it was SQL CE that had the problem with (I think) not being able to specify keys and so having an odd behavior with (I think) Code-First that I had to kludge around....

Maybe I'll take another look at Code First and see if they've fixed the problems.

Thanks,
John

[sloanjh]

Also keep in mind that persisting to a database-based format isn't the only way to skin this tiger.  I'm about 30% into an Aurora-like that persists to xml.  All the game files are in xml, which allows modding for people who aren't necessarily DB-literate.

Yeah, I'd contemplated using XML as a format for initialization files that could survive class structure changes and/or for save files.  I didn't have the energy to grind through the infrastructure to set it up, though.  I assume you're familiar with .NET's auto-XML-schema generation class (XMLSerializer, IIRC)?  Just initialize it from a class object and it makes a schema with all the public members and i/o code for you - totally nifty.  The only downside is that it can't handle circular dependencies, so you have to throw in proxy classes to break the dependency.

John

[Erik L]

Personally, I'd only use XML for configuration and options. It would be too complex in my opinion to use anything less than a database format.

[Antagonist]

If you HAVE to go XML I would look at Linq to XML. The convenience of working with actual objects rather than having to wrestle with XMLDocument every time you need to know how much population your planet has cannot be underestimated. Alternatively sloanjh's XMLSerializer suggestion, tho I have had issues with it in the past. But yeah, XML is a flat file with no indexing. When storing small non-often read stuff like settings it has a great advantage with being editable by hand. For large databases not just is it storage space inefficient, it is slow. When you have a database the size it needs to be in order to play a game the complexity of Aurora, your HDD will hate you.

Additionally, XML being human editable isn't really a big advantage. Human editable doesn't mean it is in any way nice or convenient to edit. On the other hand, if you wanted to edit a SQL database in case of a save file messing up or something you can use Access or even Excel to edit it. Yes, you won't do it in a text editor, but I find it much easier and convenient to use something with rows and columns.


@sloanjh: Right, yes, it wipes the database upon model change. But it also supplies a way for you to initialize the database:

http://www.dotnetthoughts.net/2012/05/25/how-to-populate-data-in-entity-framework-code-first-on-database-creation/

The Seed function fills it with initial data every time it gets wiped, and you do it by creating .NET objects and adding to a collection, again avoiding having to touch the database at all. You would for instance define your static data and research and all of that this way. While developing this works okay, and when doing a release you can setup a migration for existing saves to allow it to persist database changes. Or if too much effort you can say frakk it and tell them to start a new game when upgrading, either works.

[Bgreman]

For one, I am not reading and writing the xml files with each "transaction."  In actuality, the "settings" information and game logic/relationship information is stored in xml files, and game state objects are serialized to XML and then highly compressed.  They are only accessed during load/save operations and kept in memory otherwise.  I haven't found disk space to be an issue, since hard drive space is cheap and even long-running games take up less disk space than a model archive in a AAA commercial title.

I do make extensive use of LINQ.

[Antagonist]

Well, even after weekend no interest or anyone taking me up on my offer. Perhaps not the best forum for interested devs to stumble over, but I'm not about to go on a recruitment drive without interest displayed. Ah well, I'll upload some code to source control next I have time, like my already mostly developed framework that I have to clean up. I still have work to do on my star generation code and this can be used to showcase that.

@Bgreman:
So your approach is pretty much in-memory storage with simply using an XML file for flat save files. I suppose that the XML eases the read-write burdens in such a case. Your approach certainly isn't wrong, just not the way I would do it etc. Most arguments I can make against your approach might be in miliseconds shaved off of loading and saving as well as using excel to edit save files which is harder with XML, but in the end these are minor quibbles, where other concerns like memory management, threading and algorithm use would have a far greater effect on performance than the use of XML ever could, but I suppose you are on top of that.

Good luck with your efforts, I'd like to see what you come up with.

[exdeathbr]

About realism
There is a book rpg with space battle/travel that tries to be very realistic called vanguard rpg, its 100% free pdf but their website is down.   
The system use wormhole as the only method to travel FTL.   
Wormhole there is not fully understood, its was discovered by accident, but it works.   
Not all ships there have wormhole equipament, you have to build ships with it.   
Sometimes the wormhole stop to work for some months (the book say this happened with a wormhole near sun).   

I dont remember how exactly the wormhole works there, if its instant travel to the other wormhole or instant travel to other specific place in space.
But you said, you dont want wormholes.     So you will problably not use it.     Just posting how a game that tries to be very realistic deals with having FTL.