yeah, that comment was definetely directed towards me. Im sorry if i came off a little dictative, but my comments weren't meant to sound like that. im truly sorry if they came off that way. i know this game is near and dear to many people (inlcuding me) and im not saying everyone should starting working on my ideas immedately, im just trying to get ideas flowing. thats all. and im not knocking the programmers of this game either, its a great game with a reslient fan base, the game is just getting a little stale and i want to get some ideas going on what can be done to help revive the game or possibly bring it to popularity that its never known.

the underlining was just so people who dont want to read a long post can get the main ideas quickly and cut me down if i deserve it. please, constructive critism is good, thats the point of trying to get creativity going. again, my ideas aren't directives, just ideas (and maybe bad ones at that).

its just that i love this game and i see lots of potential.

Whoa, whoa, Database? Here we're going from files to a database... Hmm... Believe me, I know performance applications, you'll lose about 40x the performance because your database will be dealing with the data in a way that is not nearly as efficient. I ran my game's server off of SQL and it would update 3000 sectors of space once every 5 hours... it just took that long to index thru the sectors and update things. Now with just reading text files, I update 3000 sectors (1 file = 1 sector) in 5 mins. If I were to mmap it, Im sure I could update all 3000 sectors in 1 minute or less.

I suggest you consider exactly what you NEED SQL for, and see if there's a more efficient way around it. If your game can store data in a way that seems logical and straightforward, you shouldn't use a database with deterministic and genetic algorithms breaking down how to load the data from your query... Its like using a sledgehammer to cut down a tree.

You're joking right? Yeah we all know about those ultra high-performance ERP systems that Fortune 500 companies run which have a FLAT FILE backend. Oh, wait, never seen one. They all use SQL.

quote:Originally posted by rompca

You're joking right? Yeah we all know about those ultra high-performance ERP systems that Fortune 500 companies run which have a FLAT FILE backend. Oh, wait, never seen one. They all use SQL.


Data caching, raid drives, etc all contribute to the database servers. Rather than the database being on a different server and having to go through a 10 Mbs Ethernet connection, the database would be local and have faster access.

Plus I have seen slow databases, usually they are misconfigured and are having terrabyte size databases. A TWGS database would be much smaller, megabytes at the most. Each game seems to take up 4.5 to 5 Megabytes for the flat files. Plus if the data was loaded into memory from the database it would be a much faster access time but take up more system RAM.

In the old days, I remember DBase and XBase (Clipper etc) databases being flat files, DBF files to be exact. I recall converting a Clipper database on a 386 to Access 2.0. The Clipper database processed a report in about a few hours on a 100Mhz Pentium system. I converted the data to Access tables and queries and rewrote the code from Clipper's language to Access BASIC. I applied memory caching and bursting of multiple records in one read. I got it from 2 or 3 hours down to 45 or 30 minutes. On a 386 it would take almost all day to process the report in Clipper. Database size was like 600 megabytes or more. This was like 1996-1997. Access is not as powerful as most of the high end databases out there. I cannot tell you what the report was for or what data was being processed because I did contract work for the Federal Government and it was classified. They used a variety of different databases for many things. I used Access because it had a nice GUI interface to it and almost anyone could run it by using a mouse to click on forms.

I can tell you; however, that a 6M database will be much quicker to process with modern database technology.

While we can suggest database access, it is up to JP to decide what to add in. Flat files may be more easier to maintain; however, they can experence data corruption at lot easier than a database would. If a database were used, there would be less game corruption data problems. Also migrating from one server to another would be a lot easier as databases can export and import data quite easily. Try to do that with flat files and you experience a problem and almost always have to rebang. Also consider that EIS would have to not only support the TWGS server but the database program as well. It might be too much to support.