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.