m.a@stars wrote on Thu, 07 July 2011 09:50

Musmuris wrote on Thu, 07 July 2011 14:14 we're working on a code base we didn't start and that's not how it's been designed, so given that XML is a very reasonable way to go. You're building a client-server system, aren't you? Then having some choice in intermediate data-exchanging formats makes sense, and would indeed help with the creation of additional clients, or even servers.

Nearly everything has XML parsing ability these days - so it seems the perfect format for this

Report message to a moderator

m.a@stars wrote on Thu, 07 July 2011 09:52

Musmuris wrote on Thu, 07 July 2011 15:39 file formats can and frequently do change. That happens with databases too. There's ways to cope with that. Plus, public access to the data files helps keep everyone honest.

So why are you against XML again then? Anyway that comment is out of context - my point was that the APIs would always abstract the changes anyway, and in fact this would be more important for a database

I would always favour XML over CSV for a file format for something like this, simply because the XML spec is well defined whereas CSV doesn't even have a spec really.

Report message to a moderator

Daniel wrote on Thu, 07 July 2011 15:45

I found the binary serialized data impossible to debug

Quote:

The advantage of XML is that it is very forgiving of layout and order for 3rd party tools

It also forces them to include an XML parser/engine.

Hopefully once the game and its files are stable enough, other file formats will be possible.

Quote:

you have a bit of time to wait, unless you want to code AIs in C# using Nova .dlls.

Perhaps what Paul (and maybe others) would like is to start developing their automated empire-builders on their own, without waiting for the Nova devs to get everything ready.

Report message to a moderator

Musmuris wrote on Thu, 07 July 2011 15:56

So why are you against XML again then?

I find flat tables simpler.

Quote:

Anyway that comment is out of context - my point was that the APIs would always abstract the changes anyway, and in fact this would be more important for a database

Actually, it seems I guessed right. APIs are all nice and convenient, but as any user of propietary file formats knows, the real power comes with free access to the data. And that is also pretty important for databases, where one of the most serious concerns is the possibility to migrate to different DB engines.

Quote:

the XML spec is well defined whereas CSV doesn't even have a spec really.

Again, there's ways to cope with that, starting with a good documentation on which flavors/formats are being used.

Report message to a moderator

Musmuris wrote on Thu, 07 July 2011 15:53

Nearly everything has XML parsing ability these days - so it seems the perfect format for this

Excel, openOffice, and many other spreadsheets can digest CSV, so...

Report message to a moderator

m.a@stars wrote on Thu, 07 July 2011 10:01

It also forces them to include an XML parser/engine.

I'd much rather be "forced" to include an XML parser than roll my own CSV parser

Most languages include an XML parser anyway, like python, .NET etc. Even in C++ it's not hard to plug one in like xerces and probably quicker than writing a flat file parser

Anyway - I sense we won't convince you. Maybe you could do an XML to flat file converter

Report message to a moderator

Musmuris wrote on Thu, 07 July 2011 16:47

To follow up again! Have you thought about learning C#? You'd be really welcome to come and write an AI actually in the codebase directly.

Thanks, but programming in C# is not the thing I'm looking for. If I'm not mistaken you guys have someone responsible for AI, which already have some success.
Writing AI is not a straightforward process. Different ideas, different approaches. No need to start every AI attempt in your project. Let 3rd party devs have some fun and if some day anyone will come with decent AI, then I think porting it to your project will be a trivial thing comparing to the efforts spent to elaborate the algorithm itself.

m.a@stars wrote on Thu, 07 July 2011 17:01

Perhaps what Paul (and maybe others) would like is to start developing their automated empire-builders on their own, without waiting for the Nova devs to get everything ready.

You got it right

Report message to a moderator

Writing a AI is something I've never done and don't really know where to start with - which is why I was hoping to persuade you to write one for us

Report message to a moderator

Musmuris wrote on Thu, 07 July 2011 17:32

Writing a AI is something I've never done and don't really know where to start with - which is why I was hoping to persuade you to write one for us

You make it sound like I'm a kind of specialist knowing how to implement it

Why do you need AI now? Seems like for testing, right? Then it should be like a guy building/researching everything, sending his ships everywhere, doing all possible actions in a random way.

Once you guys finish file formats - this is when the fun (and "serious" AI ) begins. Because you will have others (including me ) ready to help you without touching C#.

Report message to a moderator

Musmuris wrote on Thu, 07 July 2011 16:18

I'd much rather be "forced" to include an XML parser than roll my own CSV parser

You lazy bum!

Quote:

Even in C++ it's not hard to plug one in like xerces and probably quicker than writing a flat file parser

Dunno. It took me just a couple minutes and a handful lines of code once I decided I'd just throw away anything non-standard (as per my standard! )

Quote:

Maybe you could do an XML to flat file converter

Well, someone has to do it if Nova is to ever be able to "Dump Reports" as Stars! does.

But I'd rather do the dumps directly from memory.

[Updated on: Thu, 07 July 2011 13:44]

Report message to a moderator

My last post was stupid; indeed you don't need to implement a whole server... I was thinking of the current AI that runs server side wise and I was sleepy A third party client will do.

[email

m.a@stars[/email] wrote on Thu, 07 July 2011 13:20] Well, someone has to do it if Nova is to ever be able to "Dump Reports" as Stars! does. But I'd rather do the dumps directly from memory.

Dumping the current state right from memory for the turn files would make their relationships very spread out in a flat table style dump. For example,

Flet inherits from Item, and contains a list of Ships, which also inherit from Item, which store all of their components, which also inherit from Item, and link to a design that also inherits from Item.

It means dumping a single Fleet needs to link to at least 4 items, if the fleet contains one ship with just engines. And this is besides linking to the respective Ship, Design and Component objects.
Doing this in XML is fairly straightforward as the items are just subnodes on fleet, ship and components, and those are subnodes of each other, so no need to hunt for a ton of them in other blocks/tables when deserializing a fleet; they are all grouped together.

EDIT: unless we dumped them together, in which case each dump would be long and ugly and it would be nasty to check when each item started and ended, as the number of serialized variables on them can change, same for components.

"Report Dumps" like in Stars! can probably be handled differently with some flat table like dump (as they are shown as a table in the GUI already) or some stripped down XML.

[Updated on: Thu, 07 July 2011 15:09]

Report message to a moderator

Aeglos wrote on Thu, 07 July 2011 20:47

"Report Dumps" like in Stars! can probably be handled differently with some flat table like dump (as they are shown as a table in the GUI already) or some stripped down XML.

Those "Dumps" is what I meant. Also, that it should be easier to craft them from the in-memory working data than from any intermediate XML dump.

Note: nested and linked structures can be dumped too if needs be, each in their own little flat table, with perhaps their relationships spelled out too, same as the big databases do.

Report message to a moderator