Thursday, October 25, 2007

Updates!

So, let's explain what I'm up to all this time.

Personal situation

Last summer I landed a job as System Administrator at a company. The company itself had about 150 employees, and my job was assisting the sitting sys. admin to keep the servers up and running, fixing issues, etc. While the job was fun at the start, it become pretty boring in the long run. Esp. when the main sys. admin was on vacation, I had almost nothing to do. But, I needed the money to pay for college coming year. This was one of the reasons I stopped development on Dune: I came home from work after around 18:30, had to make dinner, eat and clean up again. By the time everything was done, the last thing I wanted to do was code.

Eventually, when classes started again, I worked there for 2 days a week, as it was a nice solid income. However, after a few weeks, I got an e-mail from a professor, with a job pamphlet. An acquaintance of the prof was looking for a student who wanted to do some C++ / OpenGL development on an existing CAM software package. So I called the guy, went in for a job interview and got hired.

So, right now, I'm working 2 days in the week as C++ programmer on CAM software. The software itself loads a CAD model on which the user can then do several operations to prepare the model to be cut out in wood, plastic or metal. Editing the model has to be done in CAD software, so the transformations are mostly simple ones. A pro of this job is that it pays 50% more of my old job, which is even better.

I also have a load of school assignments to do, which have a higher priority than Dune has.

Dune 2: The remake

I never intended to permanently cancel the project, I just didn't have any time to work on it. The downside of hobby projects eh? Anyway, I intend to continue development in the coming months and pick up where I left off: The networking engine.

Last night, I was considering my options on what I could do to get it working across the internet. Initially, I intended to go with a Star Topology network using UDP. Each client would connect over TCP to the host, which would then assign a port number to the client. Using NAT Punchthrough, the client would then connect to the host over UDP over the assigned port, and disconnect. The other clients would then connect to the client as the port would still be open. However, this is quite complex, and I do not know if it works. Since UDP is connectionless, the UDP port should stay opened in a router for a short time span, even after "disconnecting". However, I would need to test this to verify that it actually does.

If it won't work, I'll to go with a traditional client/server approach. However, I still intend to go with the same approach as AOE, go with turns, etc. However, this would be a problem in a P2P setup, because how do I ensure that each player executes the same commands?

For instance, consider player 1 moving units 10 and 11. These orders will be send around the network to be executed for gameturn n. Each client will respond back to player 1 that they received the orders. But, how do the other clients know that all the other clients have received the order aswell? If one client does not have these orders, and all clients execute the turn, this client will run out of sync, and gets kicked. So, I need to work out a little bit on how we're going to do this. I could technically let each client send a hash / CRC of all received commands from the other clients to the 'host', which then determines which commands get executed and which get re-scheduled for the next turn.

As you see, lots of thinking to do. I should make a few diagrams of this, as it's quite confusing in words only.

1 comment:

Anonymous said...

Hey man,

I think UDP is way to go. Lean and mean!

From your "w00t" greatest fan.