ico questions

[Mobhack]

What you are asking for realy would require massive modifications to the basic game engine, to deal with the fact that the OOB database has a finite limit. And enthusiastic developers will always go to the limit, whatever that happens to be - we thought that 999 units would solve our problems, but in reality it just provided space for a bit more "clutter" that I would not have bothered with myself.

If the game engine were to be redesigned as you are suggesting, (which would take a year at least) then use of a proper (SQL?) database might be the correct way to go (though speed may be an issue as it means searches through an entire table of say units for everyone, not an individual data file in memory). Paradox, or maybe MySQL.

SQL however, is a real problem for end-user database changes to be propogated. the WW2 databases are nearly 7MB as they stand. I already have an internal utility using Paradox that extracts the unit and weapon data to basic tables, and that expands to 10MB of tables and index files (with no formation data), just for basic searching. Any sort of database that treats the database as a "DB" file which wraps all the files that paradox does separately into a singular lump, would probably be a real headache!

Any end-user changes would require the entire database to be sent, as all the units and weapons etc are in tables and not individual OOB files.

Sure, I could write an SQL update file of a few KB that could be run through an SQL-enabled mobhack type utility as a batch fix (been there, got the souvenir t-shirt and mug, doing local authority databases for elections management and licensing systems) - but almost all end users would be clueless as to how to write such. They would use the mobhack type utility to add changes on a screen-by screen individual update basis, like a local council employee adding a new taxi firm forex, and then have to send a copy of the entire DB to anyone interested in thier mod. To write SQL updates, they would need the entire database schema to be published, and then they would need to read and understand SQL. Which looks simple at first, and then gets complicated when you try to do anything worthwhile, especially updates rather than queries

SQL databases also need the tweaking of ODBC data sources and such like, and make the use of multiple installations of databases (e.g. a fan mod ACW version) a real pain to do. They also can be a pain to write installation routines for. And things like ODBC are maybe windows-specific and so anyone using WINE on Linux may be defeated by such?.

Any new game engine therefore needs some sort of extensible database, rather than a hard limit, but the SQL database route may not be the one to pick. I already have some ideas for a flat-file based extensible DB solution, should I get round to designing a completely new game system (perhaps as a part of the degree course I join in September, as an "extra-mature" student .

Cheers
Andy