OneWorld has gone through so many revisions in the last month; if it wasn`t for our Microsoft Team Foundation Server I doubt I would have been able to track them all. So our Beta brought in a good bit of bugs, some good, bad and ugly. As I addressed each one I realized that I had some flaws in the design of OneWorld as well in the implementation. Now that I`m getting to release the product I thought I would go over some of the things I encountered to help other people who might be doing something similar to what I did.

Rule 1, Don`t over complicate things.

I usually don`t set out to make things complicated, but you know how things go. You start down a path, hit a road block and come up with this amazing simple way to work around it. You find a glitch in this simple procedure so you add a bit more code. The next thing you know, you have this freakishly complex nightmare.

Best thing I can recommend for combating this situation is to be willing to take a fresh look at what you were trying to do. Put it down for a week, let your mind process it, and be willing to rewrite your code properly now that you have the full picture.

Rule 2, Quality Assurance will break things.

So, I`ve spent the better part of 6 months building this amazing program. It`s perfect in my eyes, runs great, I`ve done my unit testing and I`m ready for people to load test, etc. This is a technicality because I`m a good programmer and I`ve tested everything. Reality is a B1TCH!

When the bugs start flooding in, the server keeps crashing, and your world is coming to an end, take a deep breath, record the bugs and then walk away for a day. When you come back, start looking at the code with Rule 1 in mind. Maybe you over complicated something, maybe you should of spent more time organizing your code, maybe you just missed resetting or packing your data. Some bugs take minutes to fix, other, require you to re-evaluate your methodology. Take them in stride, use this moment to clean up code and step through it, add in Console messages (don`t forget to wrap them with #ifdef TORQUE_DEBUG) and chase them down.

Rule 3, Make your code readable.

Initially I was in somewhat of a hurry to get this project done so I could get back to work on the next release of DNT and to get it out on schedule. So I admit I cut some corners to finish, this all bit me in the butt when it came to debugging it all.

I ended up having to spend a week organizing the code into sections, making pieces work the same way across the board, etc. Standardization and code templates work wonders, there is a reason why large companies have coding standards.

Now, onto OneWorld specific things I learned.

My original concept used threading and separate threads to run routines I needed for processing the messages from the clients. Initially it worked great, but I discovered that under heavy load the GameConnection class, try as I might to make it thread safe, was just was beyond my skill set. I ended up modify a great deal of classes to making them thread safe. In the end, I tossed all that code out and went to the iTickable object.

iTickable is a pretty neat class. You have two ways to get your code executed. The first way is by the `ProcessTick()` function. Now the only problem with this function is that it is only fired every 32 milliseconds, so for my use case it didn`t fire often enough. But there is a lesser known function called `advanceTime(F32 timeDelta)` now this puppy is tied to frame rate. It isn`t as fast as a separate thread, but it was fast enough for what I needed.


Another thing I learned the hard way was that the Terrain, Forest and Decal manager are all interconnected in the Space Time Continuum even though they really aren`t connected in code. I originally built them as separate components.


This meant I had a group of classes to handle each of them independent of each other. Each section of code preserved order of the events on both the client and the server. This would ensure that they would be applied on each client in the same order they were processed on the server.


You might wonder why I did this, but if you think about it, it`s important. Let`s say you paint with the forest, delete some of it, paint some more, rotate and offset a tree, erase, paint, etc. The order that these events are processed is important and they matter. If you don`t apply the changes in the same order on the client, well then each client will be looking at a different version of the same world since the brush strokes would be applied differently on each client. Worse yet, you might programmatically try to delete something that hasn`t been created yet.


But, remember, I said the Forest, Terrain and Decals are connected in the Space Time Continuum. One thing I didn`t recognize before the beta was that not only is the order inside each of these components important but so is the order that the events across all three.


So for example, I build a mountain and then place a tree on top of it. Well, if the client receives the command to place the tree before the command to build the mountain is processed, the tree is drawn at the bottom of the mountain and not on the top where I wanted it when others log into the server, and same thing applies with decals. Let`s say I put a hole in the terrain, later fill it back in and place some decals and trees over where the hole use to be. That would potentially crash the engine if they were applied in the wrong order.

To resolve this I ended up having to build a server and client global coordinator which directs the Forest, Terrain and Decal subsystems to apply there changes in order across all three. In the end it wasn`t difficult, but I didn`t realize it till the end.


I never did manage to get the material editor in for objects since the system is so file based, but I did manage to get the material editor in for the terrain. I did manage to shoehorn in a system to modify datablocks, even though it is different than the default behavior of editing datablocks in the editor. The rest of the editors have been addressed in previous blogs, but these were the things that I had to handle the most in the last month.

So when will it be released and how much will it cost?

We are offering two different licensing options.

Binary

The Binary license will only include the compiled T3D binaries. It will include the entire script source, in case you want to change the log in screen, add script objects, etc. This will meet most people`s needs since this is a tool and not a game platform. Most people will be using OneWorld to collaborate on editing missions and C++ source code modifications usually aren`t required for this.


The price for the Binary License is $39.95 and includes Forum based support.

C++ Source

The C++ Source Code license includes all of the C++ source code and an updated template to recompile OneWorld as well as direct email support. The source code license does have several conditions attached to it.

Like you can`t build derived tools and the source code can only be used for a game. Of course you can modify it all you want for internal use, but you can`t publish and sell new tools based off of our work.


We also require that a person or company contact us before purchasing the C++ Source Code and there is no guarantee that a license will be granted.


The price is determined per contract and game title. If you are interested in licensing the source code, please contact Paul Yoskowitz [pyoskowitz@winterleafentertainment.com].


If QA testing goes well this weekend, we will most likely launch the product next week.


Vince
Winterleaf Entertainment L.L.C.