Replicating Weapons and Damage

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.

Improving Movement Replication

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

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

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.

Oops! Time to Refactor Messy Code.

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

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.