Ukrainian Rumble 2

Rebirth of Development: Lasers to the rescue!

2007-08-17T14:02:00.000-04:00

Man, it's been a while since I really really got into the code of URumble. Reasons to stay away from it for now are more psychological than programming, so I'll stay away from these for now.

However, the good news is I did not forget my URumble codebase, it's easy to get back onto the horse and easy to recall all class structures, all connection between classes, files, libraries. Just awesome, better than I expect from myself.

As a proof, I was able to implement a whole new gun: laser in a just a few hours, and then add a graphical effect for it within 3 hours - and this is while still being bothered by external noises. (Why does a world has to exist while I code? Geez.)

Here's a screenshot of a laser in effect, and you can even see some consoles behind it that shows some details behind the scenes, and the development environment I usually have. Instrumental, calm, positive music is a must, of course.

There are some really Cool things behind this gun. One is that I have developed an entire XML framework around vehicles. Now, guns can be assigned via XML text files without having to edit the code. This is very important, since it allows for faster development, since I don't need to worry about various guns setups while I code new features.

It took some effort and thinking to create a good XML structure for that. I don't think I nailed it yet. But it is definitely good enough right now, and thus it is perfect within the context of current time. Tomorrow I may have to add something else, and thus it won't be perfect anymore, but that's the way it ought to be developed: "just right for now."

P.S. And previous tasks of replicating damage over network are done.

Replicating Weapons and Damage

2006-12-17T19:33:00.000-05:00

This replication is more involved than the movement replication I did previously. It involves firing a missile, homing in on the correct target, insuring unique missile id across the network, placing explosions in correct places once the missile hits, and replicating broken joints in physical simulation.

All of the above requires decent amount of designing. Just imagine entangling those, and you will get yourself a really messed up system.

So far I had only made on major change - I added robot owner for each gun and missile shot. This was needed to properly report missile events to other clients with ability to check if the missile was shot by a local player (and thus needs to be replicated) or by a remote player (and thus does not need to be replicate).

----

Basic network framework is being tested by every addition of network events. Every new event tests the framework for extendability and maintainability. The framework holds well.

Movement Replication Completed

2006-11-25T11:20:00.000-05:00

The idea has proven to be good.

Now, any time a vehicle moves (by player or by environment, etc.) the event of that movement is sent to the rest of the players. Those other clients receive a message, read where that vehicle must be, and let the robot handle the operation of the vehicle to achieve the desired position and rotation.

According to my tests, it definitely overcomes lag. The worst case scenario is when an event comes in rather late (lag). The vehicle does lag behind the actual location on the originating client, but the robot does move the vehicle to the desired location and rotation. So, this works great.

I have also implemented accuracy setting. Movement updates are sent every time current position is P units far away from the last sent position, or the rotation is R degrees different from the last rotation sent. Currently, this pair of values (P,R) is (1,5), where P=1 means 1/6 of the vehicle's length.

These values have direct affect on two things. One is the accuracy of replication across the network. Another is how much trouble the robot has to go through to achieve the desired position and rotation.

This last issue can be a problem at low values of P and R. The reason is that vehicle does not turn on a dime, instead its turning mechanism (4 wheels on one side, 4 more on another side) has an error, so the rotation causes the tank to move away from its original position. This means that vehicle gets too far from the desired position (more than P units), and now it must first get back into the position, before continuing to turn. You can now imagine that at low values, this turning error will cause the robot to really struggle to get the vehicle into the position. And that is what it did in my tests.

While the above is not a problem, since I intend to keep values of P and R high, it is an indication that turning mechanism of the tank must be improved. One possible solution is to alter the power of both sides (set of 4 wheels) in order to achieve equal turning power, kind of like ABS for vehicles, which alters the power of the breaks on the wheels to prevent loss of contact with the ground. This is, however, is rather complex, so if I do decide to do it, it won't be soon.

Improving Movement Replication

2006-11-19T10:01:00.000-05:00

By far, the most important events to copy across clients are the movements of the vehicles. In my current implementation, I simply send events that describe what command a player pressed: forward, backward, turn left or right, etc. This works, however, there are two problems that create large difference between clients.

One is lag. Events do not reach other clients right away, so all commands are executed later than they are actually started on the original client. So, this leads to some differences. However, this difference is not that big. The main problem comes from the second problem.

Physical simulations do not run the same way on different computers. This means that if a vehicle turns to the left for one second on computer A, the vehicle may turn 40 degrees, while on computer B it will turn 35 or 45 degrees. This causes large differences very quickly.

So, another solution is required. One roadblock is the way my vehicles move. Their movement is produced by a complex interaction of bodies, joints, and motors. So, I cannot do what many other simpler games do: manually "move" the tank from one position to another, and then smooth out the movement by using dead reckoning. I simply can't do that on my vehicles. They want to be controlled by physical laws (Newtonian), and do not like to be warped from one place to another (This may be limited to the specific engine I am using) or be forced into one position or another (by using direct external forces on vehicles, for example).

However, while these vehicles want to be "manly" and not be pushed around, I can control those vehicles via usual commands, exactly the same way that player controls the vehicles: IVehicle::moveFoward(), etc.

So, my idea is to send updates on vehicles position and orientation, and have vehicles on other clients, try to get into this position. They can turn turn and move, whatever they decide to do to get into desired location. (Btw, control is performed via IRobot's)

This solves one important problem for vehicle movement: even though simulation may run differently, robot-controlled vehicles will take care of the differences by adjusting their movements to get into the position.

Granted, this does not resolve the first problem, the problem of network lag. But this is something I cannot remove at this moment. Lag simply exists. I may decide to predict the movement on remote clients, however, if there will be a need to further improve the movement replication.

Child Steps across the Network

2006-11-13T10:12:00.000-05:00

After spending 25 hours of coding in just two days during weekend, I have developed first operational network events.

Server is now operational. Clients can connect at any time. Once connected, they are sent appropriate Id for vehicle and robot for the new player, and those same Id's are sent to existing players. Thus, all players are now replicated.

Current event cover all tank movements, tank's tower rotation, and missile firing. All such events are now broadcasted across the network.

Overall, I had a blast this past weekend. It has been a while, since I made an awesome progress with URumble. And this one was hard earned, but was well worth it. I can feel pride kicking in again. This means I can push harder then before to develop more and more features into the project. I may have a working demo within months now. And possibly a beta for the New Year's Eve! :D

That would be the best gift I ever had.

----

OK, I have a few technical comments as well. The entire network code runs on RakNet library. It is GPL licensed for free projects, such as mine. Many thanks go to the creator of RakNet for the free version of his library.

RakNet is not a high-level library. It does provide a tons of low level features, and a few medium-level ones, but overall, I had to built an entire event framework on top of RakNet. I will probably release my framework at some point in the future as GPL or similar license.

I first tested the connection on my wireless at home, between my desktop and laptop. I had a really bad lag, though, from 0.25s - 0.5 seconds. This is really bad. I was stunned. I suspected that my wireless connection is really bad, so I tested at my university on 1Gbit LAN. Oh, man, what a difference, I could not notice any lag at all with my eyes. It must have been in the order of a few milliseconds!

Other than that, developing events has been very easy. One thing though is that I have create a new class for every event (by implementing an abstract interface), as well as adding a new type Id for the event, and adding a few lines to EventFactory, so it knows about this new type, and appropriate new class. This is rather annoying. I'll think about a better solution in the future.

Refactored Core Framework, Back to Network

2006-10-28T10:45:00.000-04:00

After a very long pause, and hours of work and designing new component-based framework, the code is operational once more. I had disabled a lot of features, such as particle effects, and graphics optimizer, since I have designed how to integrate it into component framework.

However, new framework is awesome, especially, new XML format for it.

Before I finished migrated all components, such as particles, etc., I want to delve into network once more. This time I have a better vision of what and how things need to be done, and have already implemented basic server. Events are being sent across the network, new players requests and receive their data.

It is time to start dishing out new features yet again. It is time to return from the sleep of many months where I developed very little.

URumble2 on YouTube.com

2006-08-04T11:57:00.000-04:00

Some time ago I've uploaded a video on video.google.com. Now I've uploaded the same video to youtube.com: http://www.youtube.com/watch?v=EQjnSBOSgTM

Let's see how it will go.

Oops! Time to Refactor Messy Code.

2006-05-13T14:01:00.000-04:00

I decided to make a major, very major rewrite of the code class in URumble 2. Here is how it started, if you've coded something large enough, you probably already know the story.

(I will lay out my thoughts below. It was a discussion between a worker and a insulter (both parts played by me))
---------------------------
Worker:
Well, it is finally time to kick the network code, and get something going. Let's see I've got basic framework ready to go.
Insulter:
Are events being sent to the server? I bet something is messed up there. :D You've not touched network code since last year.
W:
Hmm, StopVehicleEvent is flouding the network.
I:
Bingo!
W:
That's cool I've migrated to OIS from OGRE demos input system, so something has changed.
I:
Nooo, really? I thought you write unittests for everything?
W:
Well, not that one.
W:
How about implementing events to report new player, get a vehicle id, and transmit it to other clients as well, so we can have a 2 player battle? No problem, I just wrote some docs, so now I have an idea what to do.
I:
This network looks complicated. I bet something is going to fail.
W:
RequestVehicleEvent should do it. Alright, that's done, now connect it to something, so that a vehicle is created as requested by the event.
I:
Hahaha, I can see how messy rgf::scene::Scene has become! Oh, I see you hard-coding what vehicle to load from RequestVehicleEvent.
W:
Just for a test, man, I'll improve it later. OK, compile and test.
I:
Booya! It compiles but doesn't link. Principles still hold, baby.
W:
Shooo! What's the problem?
I:
rgf::scene and rgf::physics can't resolve their linking, b/c they are so tightly coupled. Nice, I thought some smart ass was going to cleanly decouple rgf:: components?
W:
No problem, let's decouple them.
I:
I like it, it's getting uglier. Some core classes in rgf::scene are half-implemented, half-used, and just bloated with various hacks and hooks to get stuff done. That "assert(false);" looks really good.
W:
Jesus, where was the last time I've touched this?
I:
A year ago.
W:
Dang, I will put the network aside for now. I gotta rewrite this rgf::scene and rgf::physics.
I:
Haha, not so quick, plenty of other things depends on how rgf::scene and rgf::physics work, for example, their concrete implementations: ur::scene and ur::physics.
W:
8-O Indeed. Time to make a SVN branch, and get started.
---------------------------
To be continued...

Passed Physics, starting Network again

2006-05-12T14:21:00.000-04:00

I have cleaned up and updated physical tasks. A simple castle was created to populate the scene. A tank has been redesigned into a more complex structure. It has 8 wheels and 17 more parts. At the moment, there are no graphical models for them, so I created empty placeholders - very nice white boxes. If you can model anything that is beyond white boxes, drop me a message. I'll be pleased to show your work in the project. Take a look at this manual. It describes what I'm looking for.

Now I feel I have enough content and features for network testing. The first goal is to have two player interact. One server accepts both of them and exchanges events. That's not much to ask, and that's the point. One small step at a time has gotten me this far.

Once network is up and running, I will add a firing event, and see how the game feels at that moment, and reassess the goals.

A little bit of history: network framework was started a year ago, Summer 2005, but was left off at the basic level of functionality - ability to simply sends events between server and the client. That was accomplished by another programmer on the team, Greg Horvay. However, Greg did not continue network development and instead switch to GUI development. Now, I'm done with current physics iteration, and have a choice to make. My choice is to develop networks.

Why networks and why now?

I would like to close the loop. By the "loop" I mean have some game play experience. At the moment, a user can drive around and shoot stuff, but there is no one and nothing to play with. AI code is far from ready, but the networks are close, and can be accomplished in, what I hope, next month. This will allow two player to play against each other. Thus the loop will be closed, and from proof of concept, the project will enter the stage of a playable demo.

Movie on Video Google

2006-04-30T11:23:00.000-04:00

I have created a movie of the recent development code running on some really high-end machine, and uploaded it to the Video Google program. I highly recommend both the Video Google and the movie.

The movie was recorded on Linux using xvidcap.

Music from "Dark Overlords of the Universe"

2006-04-30T11:16:00.000-04:00

A fellow from my university has gracefully agreed to provide me with his band's music. For now, I have picked one song for the introduction GUI. It's the song "Going Agro!" ('agro' means getting angry).

Here is the band's site: http://www.darkoverlordsoftheuniverse.com/
And their logo:

Big thanks, guys!

Pulling GUI and Sounds

2006-04-30T10:48:00.000-04:00

Another developer on the team has created GUI component of the project along with a new project states management - GameStates. This makes for a better approach then old way of simply following OGRE demos code. Now, GUI and the rest of the code are tied up. And more importantly the code feels a lot better, that is cleaner and easier to maintain.

Another big component that made its way is Sound. For this, I rewrote my old code for OpenAL to work with Fmod. I had some problems with OpenAL running on my Windows, so I decided to ditch it. When comparing Fmod with OpenAL, Fmod has a slightly better interface since it uses a bit of C++ as opposed C-interface of OpenAL (I prefer OOP when dealing with large project such as Ukrainian Rumble). The problem however is that Fmod still feels like a C-library. Even though it offers "Objects", they are very rudimental. For example, error handling is done by each function returning a FMOD_RESULT objects which is a enum (yes, every function does that with a few exceptions). So after each Fmod call, you need to call some method to check for errors. This is rather annoying. Exception handling would be much better, but those guys have their reasons. Nice C++ interface is not on top of their list. One way or another I made a wrapper around Fmod to give myself something I can live with. Other than the interface, Fmod seems to be a powerful system that supports all major platforms, including upcoming next-gen consoles.

Now, writing a wrapper for Fmod is a simple task compared with making sounds feel right for the game which heavily relies on physics. This means that I am dealing with a "messy" system (physics engine) that does not provide exact same results for every run. Furthermore, physics give you a range of results. For example, let's say you want to play a sound for each collision. OK. I create and assign the right classes, etc. Run the application. Here is what I get: a sound for each collision, no matter how small or big it was. Alright, a threshhold is put in place, and now collisions are filtered out. Now, I notice that those collisions don't reflect real life, for example I might get 5 collision for an object simply sliding. Another thing is that collisions vary in magnitude (big and minor ones). So, now I need to add a filter to set a correct volume of the sound. After this, we get into situation where different collisions should sound different. Think of sliding motion or simply different surfaces. Mmm...

One note about sound. Once you add one, you need all of them. This is because with no sound you don't notice that everything is silent, but once you have a single sound effect, your mind expects to hear other sounds as well.

All in all, GUI and sounds add a lot to the project. It feels more complete now.

Missile Controllers are done.

2006-04-08T13:37:00.000-04:00

After "some" work, missiles actually fly, and home in to their targets. It turned out to be much harder than I thought they'd be. Most problems came from improper math calculations. Especially hard to track were bugs that were related to local coordinate system of the objects, which caused problems for missile rotations, spin, and control thrust. This in turn caused confusion in the controllers that did not receive correct missile status, and made wrong decision how to correct them.

What this means for bug fixing, is that there were multiple layers of interactions, so a digging was necessary to identify actual problems and not their results.

Man, I imagine how much work it took to implement control for real-life air missiles.

Here are missile trying to hit each other. Yeah, missiles at the moment are trying to hit anything you click on.

Missile updates

2006-03-26T18:28:00.000-05:00

Missile controllers have been implemented to a certain degree. However, there is a bug, which causes them to improperly spin in the flight. It seems that spin is always around side axis (perpendicular to the target and lying in the plane parallel to the ground).

There is a bug where deletion of a target is not handled properly. I think I'm closed to nailing that one, though.

Migrated to OGRE 1.2RC1

2006-03-26T18:21:00.000-05:00

A week ago, I've migrated code to OGRE 1.2RC1 from 1.0.x Overall, it came through without blocks, but with a few rough spots here and there.

First of all, crosshair does not appear anymore in Linux, but it appears in Windows builds. This remain untackled for now.

Second, mouse control is wacky on Linux. For some reason Ogre::InputManager::getMouseRelativeX() returns large numbers from time to time. Maybe something changed. I'll take a look at OGRE demos to see if anything different has appeared in them with mouse control.

Big thanks to OGRE team for awesome open-source 3D engine.

Missile Controllers and CrossHair

2006-03-09T15:28:00.000-05:00

The framework for new missiles and their controllers have been finished. Crosshair have been added as well, which is the first time it's been added to the project. I wasn't planning to have them actually, but here is why I've added crosshair. The idea is that manual firing of missile is hard. To simplify aiming, I've decided to implement homing missiles. The crosshair will be used to point at the object you want to shoot, and the missile will follow the missile even if the object will be moving. Of course, homing missiles won't be perfect, and I expect plenty of cases when they will miss or hit an obstacle before reaching the target. This should make for some fine strategy and tactics.

Watch Out For Parasites!

2006-03-05T22:54:00.000-05:00

Here is a funny bug, I've uncovered from working with latest missile framework. (It's a rewrite of old clunky system.) Those look like really nasty parasites, don't they? Got some spray to ward them off? :D Or maybe it is a new weapon? :DDD

Full size screenshot is here.

Jet Thruster laid off. Game logic continued.

2006-03-01T21:16:00.000-05:00

Recently, I took a long and hard look at the jet tank. What I saw was that flying controls and mechanics have taken a lot time, but have not progressed to a usable state. So, I decided to leave it for now, and move on to everything else. I will come back to flying tank later after the core of the game play is done.

Game logic. The first thing to tackle is a better missile - homing missile. You don't need to guess the arc of its motion anymore. You just point at the object you want it to go, and press/click fire. The missile homes in to the target, though it may miss if the object does something tricky, such as hiding behind an obstacle, or maybe shoot the missile down.

Once the homing missile is implemented, I will work on creating a crosshair for aiming, add ray casting according to the position and orientation of your camera. Then the whole missile feature will be done. You will able to aim and send homing missile anywhere you want them to go.

Though, I will have to add an option to a homing missile to simply go in some direction, if you missed everything on the map, such as clicked on the sky or something. I'll think about that. 8)

Jet Tank Turning

2006-02-14T18:59:00.000-05:00

Recently I have been battling the complexity of the jet tank control. My estimations came true, as I struggled to counter-balance the tank's rotation, balance, and movement features. Balancing was an easy part with barely any problems at all. Movement seems to be OK, although I've not dealt into it deeply enough yet to really assess the situation. The turning has been the feature that has been boggling my mind for the past couple weeks.

It is coming along with a glacial speed. Learning from my College class, Software Engineering, I've been busy performing root-cause analysis. For us, simple folks, it stands for debugging and tracking down improper behavior of your code.

Recently, I have gotten some "fresh air" and tackling the implementation with new vigor.

P.S. Another thing, that is getting in the way, is that I would like to show off this jet tank on the upcoming internal College competition among Engineering departments. Only 2.5 weeks left.

Jet Powered Tanks

2006-01-16T00:03:00.000-05:00

I have recently read the book titled "New Space Era and the Fall of NASA." It opened my eyes on many things and had altered my game idea. Ground vehicles are not the hype anymore. Flying ones are the way to go. Imagine an ion-thruster tank that can hover/fly low above the ground, and quickly decent on the enemy's location.

Imagination is a nice thing to have, but the implementation and control schema are challenging. The results have been cool so far, so I will stick to the idea and get it done.

Praise for KDevelop

2006-01-04T18:09:00.000-05:00

Most of my development is done in KDevelop under Gentoo Linux. On the other hand, I still compile the code for Windows platform via MSVC .NET

In my opinion, KDevelop is much better overall, while not in all aspects.

I have stumbled upon a good article about KDevelop vs. MSVC .NET.

Past unit testing to game play

2005-12-07T15:50:00.000-05:00

I've been playing a game of catching up with unit testing and features. But after having written unit tests for XML, geometry optimizer, particle manager, and various minor tools, I feel much more confident about the code base as a whole. There are more components to be tested, such as Physics and Scene tools. They are still need to be refactored a bit to remove inter-dependencies. Mm... still need to think about this.

However, I'm not writing only unit tests at this point, I'll still pushing forward with getting second demo done. Nothing major needs to be implemented at this point. There are a few minor and annoying things to be dealt with. Things like incorrect aiming when the tank tower is not horizontal, or hitting your own tank when launching a missile from the gun.

A few mode models, a little bit more exciting level design, and second demo will be rolled out. :)

Migration to Xerces from TinyXML

2005-11-24T23:01:00.000-05:00

I have recently migrated from MSVC 2003 to 2005, because I saw it fix and improve lots of things that I could barely stand in 2003. There was a drawback of course. My xml wrapper refused to work in release but worked well in debug mode. The implementation sat on top of tinyXML, which seemed to have problem with using latest MS SDK. So I figured it was the right time to move away from tinyXML to Xerces-c. Now I do not recommend choosing Xerces-c as an easy to start with xml library, but it certainly is powerful nonetheless. It took a bit to understand that it had some rather weird approaches to handling strings. Now I can understand having to encode strings into a format that support various encoding and such, but the usage of those character arrays is simply bad. A user must be constanly on look out for cleaning up decoded and encoded character arrays. I did a few things to make my life easier with it, but still it did not feel right.

The good thing is that unit tests helped me out to ensure that the wrapper works, so that now I can forget about Xerces-c lame duck interface, and hide behind XML tools that I have written on top of it.

Overall, it took only about day and a half to complete migration which is pretty good considering that I have not worked with Xerces-c beforehand. Xerces-c is not bad, though, don't get me wrong, there are plenty of good things like easy DOM parsing and XML tree browsing, but you need to watch your step, because there are plenty of hidden traps in its workings. But the main problem was almost complete luck of decent documentation. Website did not have any examples, instead sending you to download the examples that come with the source. Those examples weren't bad, but almost none of them were simply. It took some critical thinking to figure out what I need and what I don't.

I tried to find some tutorials for Xerces-c but could not find any. Very dissapointing. Xerces is one of the Apache components, and yet lucks useful documentation. And worse, it seems that there isn't any community around it to help out newcomers.

In conclusion, Xerces-c is good enough to be used after climbing its high wall, but it does not provide nice interface ( complete C++ and STL would be really nice ) and lucks documentation and community support.

Unit Testing

2005-11-10T11:21:00.000-05:00

Unit testing is an old concept that has been around long before computers came to life. You test what you make to ensure its quality. I have been putting off serious unit testing in this project for a while now. But lately I decided it was time to start writing complete unit tests to ensure quality of the project.

One of the last drops was a recent performance bug, that I have not nailed, so unit tests are coming to aid.

I started from simple components: math and XML tools. Next turn will be graphics and physics components.

I am using a very simple and handy QuickTest written by Tyler Streeter. Many thanks goes to him.

Physics Optimizations

2005-10-24T17:26:00.000-04:00

OPAL sure provides a lot of features, but I had to utilize it to the outmost to get the size of the simulation that I wanted.

First of all, grouping objects was essential for performance. So, for example a building would be made out of various blocks, which usually stay close to each spatially, so they can be grouped and their collision be optimized, because instead of checking for every block, collision can check their bounding box for the entire group. This is how ODE, physics engine, optimizes collision checks.

Second, OPAL is awesome that it can rebuild objects on the fly from static to non-static type. I used this feature to make sleeping objects static. And static object take the minimum processing power during collision.

With the above optimizations I was able to easily handle scene made out of 2000+ boxes. On the screenshot, you can see the system in action. Note that this is running on NVidia 5200 Go on a laptop, so performace is decent.

The third point is not implemented yet. Its goal is to stabilize some shakiness of the vehicle caused by a dozen of joints, which ODE does handle well at certain configurations. It will dampen small linear and angular acceleration at small values.

Simple XML tool in C++

2005-10-24T15:41:00.000-04:00

XML is really a great format. It gives a lot of freedom. I can define any structure with it.

And this is really useful for game development. Especially in C++. Its build times are rather long, so storing and modifying parameters inside the code is not very useful. Testing and experimenting takes a long time in this case. If, however, the data is moved out of the code, as it should be done, the problem of performance is gone. Just go to your favorite XML editor, edit the data, save, then and simply restart the application without any recompilation.

So, I have tried to move as much as I could to XML files, so long as it did not take away a lot of time to do so. One of the things that I had stumbled upon was uneasy reading of XML files in C++ libraries what were available to me. In particular, I used tinyXML. However, reading many small and simple files across the entire framework took just too much effort for its price. So I figured it was time to create a simple wrapper around tinyXML. This way I could expose just enough features that I need, and thus keeping it very simple.

The product is the following: XML tools: a simple reader and looper of simple XML files. See their examples for yourself.

Boy, that really made it very easy to use XML anywhere. One line of code for one value from XML file. Quiet perfect.

Switching to Artificial Intelligence

2005-09-16T13:48:00.000-04:00

I have switched from working on TrueAxis plugin for OPAL to designing some basic AI, because it was taking a bit too much time. And I feel that it is more important and productive to construct some basic scene and start working on the game play.

The thing about game play is that it is really hard to develop it unless there is an enemy to fight with. Here, I had two choices, either implement networking or develop some AI. Network is kind of ready for further developing, but I decided to go with AI. I had a few ideas ready to go.

At the moment I am working on navigation for AI. The current implementation does not require static environment, which is perfect for destructible physics of Ukrainian Rumble 2. It also does not require precomputation. The drawback is the luck of scalability, since at the large number of objects, navigation may become CPU-intensive. This however should only appear at a really large scale environments. It could be resolved though via use of octrees.

The navigation is near its finish. Vehicle control from the navigation recommendation is still being tested and fixed, but it is operational nonetheless. Once it is done, the easy step will be control of a tank tower to aim at the target and fire. This will be much simplier than navigation, though.

Soon, the scene creation will begin: the campus of the University of Louisville, KY.

TrueAxis as a new physics engine

2005-08-30T10:52:00.000-04:00

Lately, I have been working on new physics engine to replace a rather outdated ODE physics engine. ODE did a good job of starting the project, but its limitations have started to bog down the performance of the game.

What are those limitations? The main ones are inability to handle a lot of sleeping objects. That is, let's say we have 1000 boxes laying around the scene, while we control a tank moving around. A decent engine will be able to quickly parse out which objects need to be tested against, but in ODE collision detection is not optimized, so the product is poor performance. This is important, since I do expect all scenes to be like that: lots of sleeping objects. The second reason is instability: sometime ago I had to tweak things nicely to have more or less stable environment. But still I am running the simulation at 100 times per second, just to keep things from bouncing too much, yet it is still visible in demos. This is not only annoying but also eats up CPU.

Why TrueAxis? I had several requirements when choosing an engine. First of all, it has to be stable and perform well. Most engines other than ODE already do that (although not always for free). Second, it must support Linux. It is really hard to give up ability to develop under Linux. ;-) This cuts options down to two engines: Newton and TrueAxis. Now, this choice was easy since two engines seem to have gained a certain personality: Newton with correct physics (but slower?) and TrueAxis with handling of fast moving objects (but less correct?). My choice was a better performance for a price of less precise simulation and with an option of using super fast objects for missiles.

Any programmer out where will think: "Gee, moving to a different API, good luck on migrating your project." Luckily, I have foreseen this, and so used an abstract physics layer: OPAL. This way all I need to do is write a plugin for OPAL, without changing a single line of code in Ukrainian Rumble. Well, maybe some parameters would need to be changed around but that is handled in XML configuration files.

So, for the past 3 weeks I have been working on this plugin. It is not really hard but is time consuming. OPAL provides a lot of features, and I do use a lot of those features, so even though I implementing only stuff that I need, it will still take a bit. But I am getting close to a certain milestone: just a few things left to do.

Clean up stage.

2005-08-11T15:02:00.000-04:00

After having added particle effects for any broken joint, and thus any destructive event, I have distributed the link to the latest demo around Internet to get some feedback. Maybe people are just nice, but the comments were generally positive. What is more important is that I have received a number of suggestions about the direction of the effects and features that I should push in. Many thanks to those folks.

One of those ideas have led to think of a way to overcome GPU bus bottleneck. Here is what it was: GPUs have been developed and optimized to handle large chunks of mesh, however, it does hot handle well, large number of meshes. 10000 triangle in one mesh is MUCH better than 10000 meshes with one triangle. Here's a link that describe this in more depth.

Why is this important to URumble? Because the physical simulation is bound to have many independent objects, thus meshes. So, this is has to be dealt with somehow. Luckily, the framework allowed an easy implementation of the idea. Tanks in the recent demo are represented as a complex object consisting out of a dozen independent objects. Here is what happens now: once a tank goes to sleep (all its bodies stop moving around) its meshes are build into static mesh, and this new mesh replaces old separated meshes. The only downside is extra memory usage, and slow downs when builds large meshes.

Overall, the approach brought a huge performance boost, sometimes it doubles the frame rate! At the moment I am considering bringing this method to a large scale, when the entire parts of the scene will be built into static meshes. This will require some special division of the environment, possibly via use of octrees.

Other than that, a lot of time has been spent into cleaning up the framework and its interfaces, which led to creation of a few minor tools. More are scheduled to come as they approach a certain level of usability.

After CGAIMS

2005-07-30T15:41:00.000-04:00

The conference was actually quite a lot of fun. If nothing else, it is nice to meet people who speak and think on about the same wave lentgh as you. There was one physics related paper and a few on computer graphics, but most of them were on AI in games and just in general. So, I got a few ideas to look for when I get to coding in AI into Ukrainian Rumble.

Unfortunately, network did not make it to the conference. We had only an off-line (singleplayer) version to show.

Couples of demos were created: a hammer and a line scene. For more info about them, check this page.

At the moment, I plan to release this version onto Ogre forums, but before I do that, however, I would like to make a few graphical improvements to localize it for the Ogre community (my guess is that guys and gals there like graphics ;-) after all it is a forum for a graphics engine). The new feature that I want to add is actually quite simple, which is why I am willing to do it right now: add a particle effect for any joint break not just ones caused by a missile collision. This should greatly improve visual look of the hammer falling down on top of vehicles.

CGAIMS

2005-07-15T19:38:00.000-04:00

The paper work has been completed. The Ukrainian Rumble is coming to CGAIMS 2005 at Louisville, KY, USA. The conference's website is right here.

Long story short, I have two weeks before the conference. There is plenty of stuff I want to show on the conference. Most main features have already been implemented, but there are a few rough corners that stick out, mainly vey poor ground - nothing but bunch of plains stuck together in order to form a ground.

The reason this sticks out is because the robots have decent models with couple of different particles to represent smoke and small explosions.

Of course, network are still coming, the client side is mostly done. It still needs to be connected to the server, though. At the moment the server does not anything other than ignoring all incoming packets but the ones that are send during the connection and disconnection of a client.

Summer semester is almost over, and the free time is here to help me.

Blog has been created.

2005-07-13T04:44:00.000-04:00

This blog will be a journal of my development of Ukrainian Rumble 2: "Heritage", a Multiplayer Mechanical Shooter.

For details, visit the homepage of the project.