He's 20 and he's addicted.

This is the answer to WashPo: Dealing with your Online Gaming Child article by Greg L at Terra Nova.

If someone is addicted to virtual world, are the roots of the addiction lie in the virtual world? Or maybe its a problem of the real one, which seems to be too much uncomfortable for a young man? He's 20 years old and he's bearded. He is not interested in life. VW is a problem! That's easy to say. He likes heroine - the problem is heroine! He likes MJ - the problem is MJ! Let's jail all those programmers, designers and artists with all the drug-dealers to one cell. Is that the way out?
How many active healthy people have you seen, who play virtual games all the day? How many successful people have you seen, who take heroine? Is that because they're so smart for not to try? Or maybe that's because they're just not interested? Why there not interested in such activities?
How to deal with it? Do you really think that you may stop someone from doing something by reading books? I would say for myself. I was the guy like him. I was out of university twice because of games. There was nothing, absolutely nothing as interesting for me as computer games. But time heals. He would be healed by himself. Or die playing. That's life - and that's his choice.

P.S. Or just kick him off the house to make him build life of his own.

Gordian Scimitarization

About a week ago, I discovered, that MMO360.com changed its format. Now it's like some kind of knowledge database about MMOs, I guess there are planned to be articles on different subjects of massive multiplayer online games, interesting discussions on this subjects and lots of other information on all aspects of MMO-world. Just a view from 360 degrees as it declared in the name. The first article was about MMO design. As I found out, it was a reply to a challenge, started by Brian 'Psychochild' Green as inspired by Patrick Rogers at I Maek Gaemz blog. This readings really inspired me, so I decided to express some thoughts of my own on this topic.

This article is covering basics on the situation around character design.

Design. Its everywhere. It permeates all aspects of development. From program design to design of the character and the World itself. It is a single system and without changing one part of it, there's no way to change another.

But let us start up with the Character.
Reading various blogs on MMO design and gameplay, I came to conclusion, that at this very moment most popular MMO games divide in three categories.

First: Itemized design - this is what has awaken the dragon. The world designed in the way, when all player's development depends on their equipment. You want to be successful? You need the best weapon, best armour and The Ring or The Staff, whatever it looks like and whichever story lies behind it. Your only way to "endgame" lies through infinite chase for better equipment. I had this experience in Lineage II. I couldn't play it after about 50 hours. I have played x100 server and a small x3 server. Maybe I have imprinted wrong thing and haven't experienced social part of it, but as I've noticed, on official servers everything is spinning around economics. You cannot have good time being poor. You have to earn enough money to equip well. You need enough money to maintain clan or castle, money is the power, power is the money. (I wonder, what would happen if there were no people, scavenging game resources for money.)

Second: Character-oriented design. The some kind of polarity for Itemized one. You have a character, you design it to the birthmarks at the left heel of the body. You may give it thousands of skills and abilities, you may do with this character anything you want in game environment. You challenge quests in parties with other greatly customized characters. You know this character to the marrows. You play social games, enter and leave guild and all you do in a game is having an alternative reality to play with. But the same toys make you bored sometime.

Third: Mixed types and outcasts. Under this category lie games, where design balances between the first two polarities, and games, which character design is so "weird" that no one even heard of it, and those, who've heard of it, dare not speak its name. What its name? Oh, I dare not speak it. :)

Sometimes, I'm even happy, that I have not played any Really Massive Multiplayer Online Role-Playing game. As I think, it makes me unbiased in some aspects of game design. I don't have hardcoded patterns in my mind about "what is the good style in game design", "10 rules of good game design" or "how to make people love your work". It's great as for me! I can experiment with the craziest ideas and let the Force/Hatred flow through me.

Crazy idea in the next article. I need to learn some maths for it.

Logging Class Part #1 : That's the way I log it

In my previous post I mentioned, that a good logging class is a must for any-scale project. Now it's time to take a look at what Mono may offer us on this subject.
At this very moment, Mono has implementation of System.Diagnostics Trace, Debug, Switch, standard Switch-type and Listener classes. As far as I studied Microsoft (heh - I'm using payed MSDN library to learn free Mono classes) help for tracing features of .NET, this set of tools (with using custom switches, of course) will provide me full access to the logging power of C#.
Using of this tools is really easy to understand. You have a great variety of choices for making your logging class really flexible to be used in all parts of your (and mine too) project.

Let's take a little structure overview of the future logging class.

As we create an instance of the class, we should let it know where to store messages that we pass to it. You may store them to some system-specific logging system, to a database or a simple text file. As showed performance-test of all this ways of storing data, the best performance provided when using simple text file for output. But depending on the specifics of your project, you may use database for better after-analysis and system-specific logging system to provide end users with necessary information.
At this moment Mono does not support Framework 2.0 TraceSource class of System.Diagnostics, but this feature may be easily implemented within your own class.
For my project, I'm planning to use simple text files for storing error, warning and in-game event messages. About in-game events - I think, maybe an extra log-parser will be written to find any information I need.
That's all for now. In the next article, I'll tell how to set different log levels for program-specific needs.

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. ^_^

Experiencing Mono

At this very moment I'm testing Mono C# realization for necessary capabilities to keep my project alive. At first glance everything seems to be just fine. I found my 4-year old script for getting all data from Fallout ".dat" files and putting them into database. I spent lot of time getting familiar with Fallout objects structure and which is even more important, I commented almost every string of the code! Thanks to that, now I have a very little things to do to get my script working in even a better way than it was.
Oh, I almost forgot. MonoDevelop successfully imported my windows MSVS2000 project and I haven't changed even a string to get it working. That was a good surprise. As far as I seen, Mono has support almost for all types of databases I may need to use in my project.
Choosing database. That's the next step of my work. Not the server-architecture, as I were thinking before. So at this moment I'm gonna spend some time making my "old-school" code "beautiful" and reconsider object structure, which was created 4 years ago. No - fallout object structure hasn't changed. But my look at this may have changed greatly.

Choosing server platform.

Actually, I spent pretty of time thinking about what platform to choose for the game server. I'm quite good in C#, but it is strongly chained to x86 and MS Windows. Now I'm getting started with Python, but its more "Starting" than "getting", heh.
Surfing internet I found Mono. Mono is an open-source project providing the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. It seemed to be much acceptable solution for my project. After digging it for a couple of hours, I wrote some "Hello world" program and discovered that Mono allows me to use almost all features of .NET Framework 1.1 and it's still under development extending it's functionality every day. So, now I'm able to code in my favourite language and still have my server-part platform independent. That's all for now. Later I'll post my considerations about server architecture.
More information about Mono you may find at their website.

Let's get started.

Finally, after four years of unconscious comatose, I'm ready to start the project of my dream. It's going to be a long way to the dream, but what are we living for, but to make our dreams come true.
So... Let's start!