A few more thoughts on the WoW database

Dec 9, 2008 00:00 · 806 words · 4 minutes read development world of warcraft

It seems like my post on an open source WoW database has received a bit more attention than I expected. Let me share a few additional thoughts with you.

The database client

While I am currently using .NET 2.0 / C# to prototype a client which takes care for downloading and updating the WoW addon for data gathering, I am of course aware that .NET 2.0 is not available on every platform where you can play World of Warcraft. There is Windows in various incarnations, and there is Mac OS X for us to play the game on, and some people even use Linux to play. I probably have not mentioned this, but I am using all of these platforms to play the game, and thus I am very interested in making the database client work on all of these platforms.

My current plan is to finish my .NET prototype, as I need some quick test tool, to define and build a proper web interface for managing the WoW addon, and to test the client updater. Once this is done, and the web interface works, I plan to turn the whole client functionality into a plain C++ library, which can be build and used on Windows, Mac OS X and Linux.

For now the library is supposed to contain the following features:

  • Parsing the WDB cache: as many players know, the game client uses a simple data cache for books you have read, creatures you saw, game objects seen and used, items seen, and quests done. This data will be required for several reasons. E.g. if we want to display rendered views, we need the data from the WDB cache files.
  • Detecting WoW: of course, the library needs to find WoW on your system, and there are various different methods to do so. WoW is e.g. installed in different ways for 32-bit and 64-bit operating systems.
  • Parsing the addon Lua data: while this is not necessary it would be beneficial to embed Lua into the library. This would allow us to validate the saved Lua data, and it might provide options for blocking invalid data, too. Why should we upload broken data?
  • Authentication: I would love to have the database site requiring a login. Why? Because it would be great to give credits where they are due. If someone contributes to the database, it should be recorded and visible in some place.
  • Update management: we need to keep up-to-date, and this includes both the database client, and our WoW addon. The game client changes with every release, and bugs are everywhere. There is no development method that results in zero bugs.

On top of the library custom GUI clients can be used for each platform. On Windows, we could use plain C++ with MFC or a .NET GUI, on Mac OS X we can use Carbon API to integrate into the system.

Of course, suggestions are welcome.

The database server

Once of the things I have considered over the last few days was to turn the server into something that could run in a distributed fashion, much like the version control system Git which I use for my own projects at home and at work. Concerns have been raised that the current databases are commercial because you will have large hosting bills.

But what if the database server would have a central server somewhere, and all available installations would connect to this server for data sharing? Thus every installation (e.g. on guild sites) could contribute their data even without knowing the main server, and every installation would benefit from uploads.

Anyway, the only thing I have decided on yet is that the database server will be developed using a model-view-controller pattern. This may be done with ASP.NET, on PHP using the Zend Framework, or on Python using Django, or on Ruby using the famous Ruby on Rails.

Personally I would prefer a Python or Ruby based solution. But still, for my prototyping I will stick to using PHP and the Zend Framework for one simple reason: this solution works on most hosted environments. You will not depend on owning a root server (which not everyone can afford).

The code

There already is a bit of code, and I am working hard to get this in a readable state and documented. It will appear in my GitHub account at some point.

Contributions are welcome, in the beginning I would be very interested to hear what addon developers need. E.g. what would systems like QuestHelper, TourGuide, or LightHeaded need? After all, quest guides are the simplest form of giving data back to the community, thus you would want to have it done right from the beginning.

For now, I am considering XML output in a format similar to the armory format, but would that work for addon developers?

Comments powered by Disqus