Gutted. Spitting Tacts. Very Angry.

I should be celebrating. The code was completed and I was confident about the Bluetooth game-packet transfer. I had to make a small change to change an Integer variable to a Long and that would have been it. Then all Hell broke loose.

The 0.3.1 prototype JDK stopped emulating Bluetooth and no matter what I did, the damn thing would not pick up any sent data from the client to the server. Server to client was fine. So after a day of trying to get that to work, I tried the 2.0 prototype JDK and the Series 60 JDK, both with horrendous results.

The 2.0 prototype doesn’t seem to want to work with JBuilder debugging. It keeps on crashing over. When it doesn’t, then it only seems to transfer the first 48 bytes of the original 128, even if you specify the length to be 128.

It’s making life very difficult. Still waiting on the other 6600 to arrive, maybe once that’s here I can get this testing out of the way once and for all.

Boosted by my success with the map transfer, I’ve now started implementing the game play communication. Like I envisioned, it’s a lot easier than the map transfer. I have two problems outstanding.

1. Presently, the clock for the game is run by which phone has been challenged and the challenger resyncs when a move is made or every five seconds. The problem I’ve noticed is that the clock only takes into account the sleep time and not the processing time of the game beat. So if the clock says twenty seconds it’s not really been twenty seconds of play time.

2. The only other issue I have to worry about is the capture of an error during the game it’s self. I.e. one player gets a call during a game, the game stops and both players have to be notified it’s abandoned.

There should be a new 6600 on the way from Ebay. I just have to sell the N-gage now (Boo Hoo!) and beta testing can start. I’m going to send an email to a few contacts I have to see if they’re interested with help beta testing it.
I’ve also downloaded the Sony-Erricson development environment just to see how difficult it is to port from one phone to another. I’m kind of dreading it.

Full speed ahead !

I’ve now got two emulators working. One generates a map and then passes it to the second emulator. This map is then displayed correctly on both emulators. I’m as overjoyed as a programmer can get (!)

I was worried about the performance because it seemed to take ages to create and parse the XML. However, when this code is run on the 6600 itself, it seems to fly so I’m not as worried as I was.

I am a bit worried about the other handset. I managed to pick up a 6600 on EBay. However, I’ve sent the check off, but made it out to the wrong person (doh!). I’m going to send a second cheque but that makes me a little nervous because of the bank details that available on these things

It means that I’ll have to sell the N-Gage. Don’t really want to because it’s a nice piece of kit, but because the Java is incompatible and, when I consider things realistically, I don’t have time to re-write the game in C++ just for the N-Gage, its going to have to go.

Leaps and Bounds. I have successfully parsed a map. No Failures, every part of the map assigned correctly. I’m now coding the relationship rebuilding code. I don’t think it’s going to be as difficult as I’ve thought (but I have said that before) so hopefully be the end of this week I’ll have a visible map on both cells.

Today, I’m going to price up some 6600 handsets. I’ve got to test it between the two systems. Hopefully I’ll be able to the sell the second handset on eBay once I’ve finished with it. There is no hire service and all the people who have 6600 don’t want to swap them for an N-Gage.

It’s funny really. The actual playable part of the game has been working without a problem now for eight or nine months. It’s just this multiplayer Bluetooth that’s been holding everything up. In fact, it’s just the Map Setup that’s the problem. For instance on the success side, I’ve managed to parse one part of the map. However the rest of the map is missing the relationship data.

So the Bug search was on. Was it a problem with the conversion from binary to string? No! Were the figures being lost in the transfer between maps? No! Was the XML being generated incorrectly? Yes! Took all weekend to find that one.

There’s also been yet another SDK release from Nokia. I’ll investigate this once the Map transfer is working correctly. I won’t make the same mistake as the last beta release.

Well, that’s two major bugs out of the way in the XML Parsing. Still haven’t managed to parse an entire map yet but I’m getting there. I have noticed another problem with this section of code. This is going to have an impact somewhere I’ve just got to work out where.

Due to real life, I couldn’t work on the game last night. Just too tired.

Excellent News. I’ve got a successful stable transfer of the map and transformation of it back to XML. It’s now a case of parsing the XML to create the initial outline. I then have to step through all the parts of the map rebuilding the relationships between them.

The problem I have is the time this is taking. It takes 5 to 6 seconds to transfer the map, which is acceptable if you put a gauge control on the status screens. It’s the Parsing of the XML I’m worried about. The Generation of the XML took 8 seconds and that was a straight string concatenation.

The parsing is going to involve even more processing which is why I’m worried. I seriously am hoping that this is mostly due to the 0.3.1 Beta Emulator. It does seem to run faster on the 2.0 Emulator but as that emulator seems to have a problem with Bluetooth.

Fingers Crossed!

Well so much for full code ahead. I was looking to a Friday all myself and occasional work over the weekend. Didn’t happen. Work called me in on Friday and that screwed me over for getting any work done on Friday. Saturday and Sunday were spent chasing a tiny bug that held me up and finally on Sunday night I got the map transferred from one cell to another.

It’s now going to be the reconstruction of the map on the second test cell which will be the problem. I’m worried that it’s taking too long and users will get bored or walk out of range of each other by the time it’s all ready. However, this is the stage I wanted to be at half way through February. I wish I hadn’t looked at the new SDK.

On other news, the big mobile games conference starts today in San Francisco. I would have loved to have gone, especially since a couple of companies have offered tickets, but it would have been £500 at least and the way my personal life is a t the moment I couldn’t afford to go. I don’t have the money or the time.

I’m looking at ways now to speed up the map creation and rebuilding. That seems to be the slowest part of the system and I’m evaluating options.

1. Hope that it’s just the emulators and the debug mode which is slowing it down and carry on as normal.
2. Work on a way to store 20 or so pre-generated maps and send an index between the cells to say which ones to use. The problem with this item is the size of the Jar will balloon. 9k per map – 180K. Ouch. Add that to the 256k already there and double Ouch! It will be too big.

I had to take a break last night. Real Life has a way of elbowing in at the most critical times. I did get a reply back about the Bluetooth Viral deployment idea. The general consensus was can’t be done, or can be done but you need OBEX. This is impossible on the Nokia series 60 as they don’t support OBEX in they’re Bluetooth implementation.

Hopefully, there will be “full on” coding over the next couple of days.

ill again

Well, I’ll reinstate all the things I said about Nokia in the first place. The new 2.0 Beta JDK is horrendous for LCAP2 Bluetooth. It crashes out with out telling you, it corrupts the data between cell phones and the worst crime is;- it raises no exceptions when it does.

The upshot is for finishing off and writing this section of this game, I’ve had to roll back to the 0.3.1 beta just to get going again. I’ve lost a week on this as well. However, it’s not a total loss. I’m now going to be able to code the Lookup algorithm I wanted to on the 2.0 JDK once I’ve got the actual game working on the 0.3 JDK. This will save on the actual hardware coding time because it was not possible on the other JDKs.

There is one other piece of code I would like to put into the game, but I don’t know how it could be done. N-Gage snakes allow you to transmit the game to other users via Bluetooth. I would love to be able to do that. I’ll have to ask about doing the . Problem is that Real Life is very hectic at the moment and the amount of time that could be assigned to doing this is not very much. Still, I’ve got a day off work on Friday so I should be able to concentrate on it then.

Another thing I have noticed is how slow it is to create the XML from the interface. Dependant on how complex the Map is, the longer it takes. This I’m going to have to rectify by generating the XML as soon as the Map is generated and then tag the playing pieces XML on top of that.

I’ve also found a bug in the decoding. Each Data Structure is broken down into 128 bytes packets and then passed to the next cell which then builds up and amalgamates these into an Array. In order to show where the structure ends a ‘/n’ byte is sent at the very end.
The responding cell phone has then got to look for this ‘/n’ to say it’s got the data.

So instead of checking just the latest 128 packet for the ‘/n’, the code was looking through the entire input array instead. This means that the 1000 ms response timeout was being missed and the whole process hung. Doh!