A Wasted weekend.

It turns out that if you are writing a real time game, then forget about using RFCOMM. Other people have reported that its latency is absolutely useless. Apart from the fact I couldn’t get it to work, most realtime games are written using the LCAP2 protocol.

This isn’t a big job as I though, but I do have to think a bit more about how to extract each stage of the game. Thankfully, the main game packet has already been designed. However, the Player details, Process Unit Details and Game Map will all have to be recoded.

A Busy time ahead.

I’m working out the control flow of the serial connection of the game between client and Server. I’m beginning to wonder if I have over engineered the protocol. Most of the examples I have mostly open inputsteams and read them. However, one (from a Website which is an excellent reference) opens a DatainputStream instead.

I guess it will be try it and see. One thing I’ve been noticing is that these Streams are closed on each iteration within the Run methods. I’m wondering if I need to do the same, technically I need the streams open for the length of the game but it’s confusing.

The main problem I have is the AcceptandOpen method. This blocks one of the threads until a client connects. The problem I have is that this locks up the game after you attempt to leave the Multiplayer section. I don’t know if this is a problem with the Emulator or if I’m missing something within the implementation. This means more things to add to the testing schedule.

By the end of this week, I’d like one Emulator to be able to challenge another. I’ll then rebuild the game for the 6600 and see if it will shut down the multiplayer section properly.

Another Issue ?

I’ve finally got my head round the communication protocol I’ve got to use. Hopefully I’ll be able to press on with the duel. There are four objects which have to talk to each other in order to get this working.

The Master object – The previous screen which will handle the display of opponents.
The Bluetooth Connector – This handles connection requests to the Handset.
The Network Layer – This will handle the flow control between client and server.
The Muliplayer Game – This handles the graphical front end for the user to use.

I’ve already notice a flaw in the basic version. I’ve made an assumption that every player will have a unique User ID. This is not true for the basic version. There is no unique key that I can latch on. I’ll have to code this possibility in which will be difficult at this stage. Could be worse, could be a lot later.

This is going to be the difficult bit.

I’m going to have to take a step back. I’ve got the XML Parser and the Challanged/Challenging Screens coded but integrating and then testing them is turning out to be a real pain. I feel I’ve lost my way slightly and I’m going to have to take stock.

I’m still in unknown territory. I’ve got look at classes which manage the communication between the two different clients. This is where I’m lost. I don’t know how to integrate these classes into the system. The classes I’m using are based on a chat program but it’s showing up my inexperience with Java.

The sample code is uses hashtables which I’ve got no idea what they are or how they work. I have to clarify what I’m doing with threads to make sure I’ve got the algorithm right. I thought that once I’d got the xml working then that would be it. How wrong I was. Think I might integrate the graphics back into line while I try and learn

Captain's Log !

I think it’s time to add a debug or Log screen. The other sample programs I’ve see have got them and I think it will probably save me so much hassle when it comes to debugging the application that it’s worth the effort of putting it in.

At least when I catch a Bluetooth exception or any kind of communication error, then I’ve got a trace. The Piece and Map transfer is almost coded. Due to ‘Real Life’ tm, I’ve only been able to code for an hour or even two every day. Normally all the transfer details could be done in a couple of days(including testing) but it just goes to show how much effort these things take to do.

I often wonder how long it would take to code up this game if I was working full time.

Well, that’s two idiotic mistakes is two weeks

When I was busy copying the map between the server and client, I forgot that for future releases that the number of pieces the player uses can vary as well. These have to be included in the setup code. So it’s a case of more XML work. It’s not that difficult to do, just a bit boring to code and test.

The idea is for the basic game each player has a set number of pieces to use. But for the standard game, players are allowed to gamble their rating to get more pieces to use against opponents. Regardless of which version of the game the opponent has. Some of these pieces could last longer or be used in a different way.

Still, I’m on schedule to start testing at the beginning of next year and hopefully the obvisactor will bring the size of the Jar down.

The only other problem I do seem to have at the moment is the graphics I’ve recently received from the artist take up 44k I have no idea how to cut this down. Looks like I’ll have to fire up photo shop and see what colours I can strip out so that it still looks good. I’m really impressed with the quality of the artists work, it’s a pity the files are so big.