Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I'm going to begin work on the zoom action windows shortly. To do this I am also going to have to define all the item data. The plan right now is to push as much as possible into XML and have it loaded at run time, thus making changes, expansions or modifications as non code dependent as possible. Each Star system will have its own XML file, all the items will be in one file. Then, another single XML file can define all the systems to be used, thus making it easy to add/remove/modify them as desired.
About the star systems, I had put them all in the same XML file for the proto sundog navigator (go to arnaud dot cheritat dot free dot fr/SundogResurrection/ProtoSundogNavigator/ to check out). But all this can be easily changed. I had in mind putting the filenames of city maps and planet surface maps within the xml file instead of the maps themselves so as not to make individual files too big.
Also with Jake, we had a dicussion about city maps, from which we concluded it might be interesting for city tiles not to snap to a grid. And that their maps should be saved in XML.
As Jake mentioned, I was able to take a bunch of his old data and turn it into a relational database (MS Access). This database not only defines information about which systems have which planets, and which planets have which cities, but it also defines how the market variables are for a given location. I would highly recommend we stick with a relational data structure.(Not necessarily MS Access) We want to be able to not only store information, but be able to quickly and efficiently query it as needed. Generically speaking I am not opposed to using XML to store data; however I'm not sure it will have the speed, and flexibility/maintainability we want. Clearly if we use an Access database it will be larger than the XML file, however for the amount of data we want to store I believe it will be insignificant. Another advantage to a database over a plain text file is some form of inherent security. While we could encrypt or scramble the file it would take more development.
We should define the data structure ahead of time or we will find ourselves spending more time putting all the pieces together. It would probably make sense to define the object relationships now as well, as the data structure will likely match it in many ways.
I hope to have the pod navigator up and running shortly. (I currently have a working example however I want to normalize it some more before I post it.)
Ok, I usually just lurk out here. However, I have to say something...
For the love of all that is cool - GET OUT OF ACCESS!
Since this is a Java project, take a look at HSQLDB. It's a nice and fast embedded SQL database system with a JDBC driver. Quite a few GUIs work with it if you're not familiar with SQL.
Jake La Foret
Also about the star systems, there is a multi-table database that contains all the current and important star system data. That is what the market engine feeds off of. We can either create an XML document from that, or perhaps find a way for the zoomaction engine to feed off of the same database. I'll see if I can get in touch with CrazyWeazel and see what he thinks about the best way to handle this. For instance, would it be best to preserve the database for the final game, or should the database be converted into XML?
But at the very least, don't put any effort into creating the star system XML just yet, since all that data has been changed significantly during the course of the market engine creation, and because I can easily convert the data from the database to XML for you. I'll email you those XML documents shortly.
I do not need the star system data yet anyway so it good for quite a while. I have some of the old data from before in an xml uploaded to cvs/data. There is a DTD for items and the star systems as well as some XML. I have the program reading the current items.xml already. Just waiting to hear back from the guy working on the engine so I can make sure to be compatible.
Agreed, pick what we want now and then we should not have to change it later. For the pod navigator what classes are you using? Just need a general idea of what classes I should extend for the ZAWs. Frame? JFrame? something else?
I'm in a holding pattern until we decide what database/format to use and I see some alpha source for the pod stuff.
Jake La Foret
Not a problem. CrazyWeazel can address both issues better than I, though I'll say the database format is open to whatever is best - however unlike some other sloppy Access `bases out there, I think this one is well built and will run well for our needs. However, it can transfer easily to other formats if that's the way we want to go. I agree we need to determine that issue soon... so if you have an opinion, voice it. I might make a new thread to discuss that too...
Also, with the pod, we started overhauling the code from bottom up a few days ago (the previous testbed we were playing with proved to be too problematic...) and this new version already looks highly promising with fast code run and pixel-accurate collision detection. CrazyWeazel is busy in the evenings for most of this week (he is one busy dude, let me tell ya!), but hopefully we'll see something we can call an alpha version in the near future.
We also have a new member to the team, Xaxes, who is going to help out in the graphics department.
Hiya, and thanks for the introduction, Jake.
He's given me a cherry of a job, designing a bunch of new tiles for the cities. They will each have an overall "look and feel" to them that will help them seem different from one another, planet to planet.
I'm sure you guys will get the technical worked out...I'd better get busy on the graphics; got some big steps to follow in, Jake!