Data Extractor Utility

After some hours of hell with my junk-code, I decided to rewrite all of it. There are many reasons for that.

• Totally mess-style code.
  
• No suitable database access class at all.
  
• No logging class for best practices.
  
• Not full structure of objects.
  
• Some things in fallout-investigations changed.
  

Let's take deeper into this.

1. Code is awful. No standarts, no style, no specialized classes. It looks like a great mount of stones, that you first have to climb up to, and then take all the stones one by one to the mountainfoot to build a great castle. There are no reasons I should be doing that.

2. No database class means a mess in the main program, you have to write same dosens of lines of code over and over again. You can't easily change database. You're unable to use some database access standart in other solution-related projects. In one word you're creating headache with your own hands.

3. There's no need to say, that logging is pretty important in all aspects of development. No matter, you're developing a simple database application with few controls of programming a huge industrial database-driven mega ERP. You need to log errors, warnings, traces, exceptions and a large variety of other data you may need to review if something happens. It's always useful if you make your logging class able to write logs to simple files, SQL server, System events log, send logs by e-mail and other special handlers.

4. In some strange way I was sure I had a description for all types and subtypes of Fallout objects. That turned out to be partially true. I have a single proto-object, which holds data that is same for all objects in a game. Then I have classes, inherited from proto-class for each object type (like "item", "scenery", "walls", "tiles" etc.). And finally I have some inherited from them minor classes to manage data for the object-types, that have subtypes. That is all I have. Not too bad for the start. But...

5. I looked through some of the latest releases of fallout objects structure documentations and found some inconsistencies with the object structure I have built four years ago. So I have to spend some more time getting familiar with the latest fallout-rippers documentations.

That's all for now.

Object Editor

And now, Object Editor is uploaded too. Actually that's not an object "editor" in the meaning of the word. For now it's just shows information about items and displays graphics for the item (with animation where possible). Source uploaded to Google Project page.
Yesterday I've tried to find my old design-document, but I failed. It seems I should write another one. It's even better, than refactoring something I wrote four years ago.

Paper work

It's not easy to manage project even with one man envolved. What to say about a team work or even corporative masses. You need to develop main concepts, write design-document (Oh! I've wrote one four years ago!), create shedule and manage a million of minor tasks to success.
But enough moaning, let's get to the business. I've created project at Google Code. Now anyone can keep in touch with the progress of the project, read latest issues and get all the necessary project data if needed. I have uploaded the four-years old script to Google SVN. Sure, you may check it out, but only if your soul may stay alive while contacting with that huge horrible piece of sh.. code. It's really ugly. I know. ;)
Later, maybe even today, I'm going to put there my other four-year old projects like Fallout Object Editor and des-doc for my "project of the dream".
That's all for now. I'm spending my project-sheduled time reading various docs all over known universe. So for this week you should not expect any interesting coding exeriences in this blog. Only some thoughts about what I read and some news on wiki-updates at my Project page.

Nothing changes

Surfing around the Internet in search for some valuable information on server architecture and whole game development concepts, I found that nothing changed in minds of game developers during this four years. As they were saying "It is impossible to make successful game alone" as they're still saying that. But... Times of teenage maximalism gone away and now I don't think that they're just a bunch of loose sucks. "Write a simple game first" they write. That's really make sense.
I'll follow their advice. Let's start with some simple game, based on fallout world. Just a simple "walk around the town a talk to people" will give me great experience in game development. And I'm still not familiar with Fallout maps structure. Though there are plenty of docs on this topic on my hard drive, I'm busy thinking about how great my game is going to be.
Let's keep it realistic. It's really helps sometimes. Simple map maker, then a little game with working Fallout-style interface and then some kind of server with a single client on it.
But first I should finish with my dat-file-ripping script. It's be a really good thing to start with. I found an interesting feature to store my fallout-objects data. DB4O - an open source object database. It stores full-scale objects as they appear in code to the database, allows full range of operations, usual for traditional databases. DB4O supports variety of features like inheritance, collections, arrays and complex structured objects and allows to access database of objects really fast.
Fallout game files ripper will use this thing to store data in, fortunately I've written most of code for all types of fallout objects, and all the methods to fill them with data from fallout dat-files.
Thats all for now. Se you. ^_^