Friday, June 06, 2008

Synchronisation bug in the server...

Well well, what a surprise! More updates on Dune :).

I've coded a bit on Dune in the past few days. Not an awful lot, because I had other things aswell, but I managed to code up a few bits on the train while traveling to/from college.

Units are moving again

Yes, first thing I did was re-enable the controls to move units and scroll around the map. Sure, they don't actually send stuff over the network, but units are moving, and I found a few bugs in there related to the MCV(ie, MCV can attack, but isn't supposed to). I intend to fix this first, before actually buffering the calls to order units around.

I also need to build the turn-system for the packets. I guess I should buffer up the commands first, and then actually start working on the system that collects the packets from other sources and hands down the orders to the correct player.

DebugConsole is now a real UI object

I updated the DebugConsole, because it didn't quite behave like I wanted it to behave. It was the first 'UI' control I built, and wasn't based on the later written UI system. In other words, it was a dirty hack that rendered itself to a texture and constantly drew the texture when needed. Obviously, that was faster than the current approach, but made it more difficult to make the console support features like real UI objects, such as resizes and adding of sub-controls.

I think the next iteration of the console replaces the current code with a Textfield / Textbox in which I draw the text, and a 2nd textfield / textbox to type in. That would make it much easier to add in support for scrollbars, and other various snazzy features. But, that doesn't have an awful lot of priority at the moment.

Synchronisation bug!

And of course the bug I mentioned in the title. I have a really weird bug in the Server code related to loading. It's a few days old, and I've been trying several times to patch this up, but it didn't quite work.

The problem is as follows: When I enter the NetworkPlayState, this will create a new state called NetworkLoadingState which is responsible for loading all assets and synchronising all the clients with each other so that each game starts around the same time. However, when the server is behind on loading than the client(On my machine that is. The game having the focus will load slightly faster than the background window), it will be done loading by the time all the clients are done loading too. It will see that everyone is done, and trigger the OnStartGame event, which in that case, will report that the server hasn't completed loading yet. This will mean the client will push a new NetworkLoadingState onto the stack and voila, the game will start throwing exceptions.

I have no idea yet on how I'm going to solve this. I'm considering the just ditch the current asynch approach, get rid of the events of the events and start using blocking functions instead, to make sure things will run in proper order. Alternatively, I might just build in a 1 second delay on the server side to prevent this from happening, but that would be a dirty hack I rather avoid. First step is to figure out where it actually goes wrong, and then find a way to solve the issue neatly, without fudging up my code too much.

Monday, June 02, 2008

Unexpected progress!

Some people probably gave up on me(or Dune or both), but don't worry, I haven't given up yet. It's just that I've been way too busy with other things in my life(Which got twisted upside. But I didn't move in with my auntie and uncle in Bel Air).

Last friday, I had my laptop with me and I was like, what if I open up Dune and start coding for a bit again? And so it happened. I coded, and debugged the code I had written, and debugged more, and yelled at my laptop. I really had to look back at older code to see how far I was, and how I solved certain issues. And to be honest, I solved quite a lot of things in a clever way.

Last weekend, I managed to finish up the lobby / loading / synchronizing part. It now successfully manages to synchronize all the data between the lobby/clients, and then starts the game, including units. Each player gets an auto-assigned starting location when they connect(At the moment, since I haven't added in start points to the maps yet). After the game is done loading, it shows everything like a regular single-player game, except the controls are currently disabled.
Lobby-server awaiting another player to join. Player numbers are currently fixed.

Minor bug with the sidebar during loading. Still need to fix that, but it's not too important at the moment.

And we're live! This shows up on both sides.

Next step is to re-enable the player controls. But instead of immediatly executing all the actions, I need to buffer them, send them to the server and have the server distribute this to all clients again. I already isolated the calls which I need to buffer, so I only need to build the mechanism to actually buffer them, broadcast them around and execute them when needed. Still need to figure out how I'm going to do that.

Wednesday, January 02, 2008

Happy new year! (And progress updates)

Happy new year! May 2008 be a good year!

As in updates: I've managed to complete the loading of all assets and the game actually ends up being started. So, the next step is to place some units on the map and start building the turn system.

I'm not entirely sure on how I'm going to implement the turn-system yet. I intended to send a StartTurn to all clients, which then starts each turn. But, as lag increases, the game would hang for a short period of time with this system(Perhaps not even noticeable). So I could send them out sooner, but that would mean I could miss packets with commands in them. Not sending StartTurn packets is even worse, as the game would continue to run(And go out of synch) when the connection is temporarily congested. Not a good thing either.

I think I need to experiment with this a bit, and when I have a good working alpha test release, do some real testing with 2 or 3 people to see how it works out.