They call this progress ?

It’s been a week since the last update. This is mostly because I’ve been banging my head against a brick wall. Presently, I’m still working on the Inquiry screen. I’ve decided drop the timed update, mostly because there’s never a guarantee that an inquiry will happen in N-seconds.

This leaves the player in command of searching for new opponents when they need to. However, once an Inquiry is finished, the application flips over to client mode and unless the player selects one of the devices found to challenge, the app will await a challenge from another user.

The main thing I’ve realised is get the application working in client mode first. I’ve spent most of the week trying to code the Inquiry functionality but have realised that there are other BT apps I can use to search for the game service that’s available. So I’ve switched focus to get the client service working and have a third party app look for my service.

The problem is that most of the sample code I’ve been looking at is mostly unhelpful spaghetti and I only discovered what I needed to last night, it’s a case of read through your documentation as it was in on of the documents I skipped on. Talking about kicking yourself!

Hopefully I’ll make some progress tonight with this tonight.

I can’t get the computer and the 6600 to communicate but I can get multiple instances of a Bluetooth app working on my machine using the emulators. The plan now is to get the Enquiry screen working and test it using the emulators, whilst this is going on, find someone with a spare (!) 6600 and borrow it, to validate the emulator results.

Things feel as if they’re possible now !

Slaphead !

The main problem with Bluetooth coding is not the writing of code. It’s the testing! At my disposal I have a Bluetooth capable computer, a Nokia 6600 and a Nokia N-Gage.

The N-gage doesn’t run Bluetooth with Java, so I can’t use any test programs with it (I’ll have to find some C++ samples to bastardise!), the 6600 runs the java programs just fine but I can’t get the Emulator working on the computer talking to either the N-Gage or the 6600 over Bluetooth just yet.

This is the latest in the line of hair ripping out frustrating sticking points. Excuse me while I go out an buy a wig !

Don't forget !

In all my excitement with the Bluetooth functionality, I’ve really forgotten that there other things to get right before the app is a released state. One of my problems with coding is that I get the functionality working 95 % and then think that’s it.

Normally, the last 5% however takes as long to do as the previous 95%, but that’s any application development for you.

The things to remember are;-

1. Introduction Splash Screen – This will required help from the artist to pull together the picture required.
2. Language switching – The actual functionality is complete to switch between French, German, English (That’s UK English so colour is spelt correctly) and Swedish. However, I have to get the phrases I have translated. There are a couple of people who I can ask for help to do it.
3. Graphics – The present method of storing graphics is very inefficient. It’s causing the size of the Jar size to balloon. I’ve got to group the separate PNGs into their different themes and also one big resource PNG for all the icons on the menus. The new functionality available in MIDP 2.0 will allow me to flip the images so it means that each player can have their own theme and the opposing player will always have their theme.
4. Sound – It’s soundless at the moment. I’ve got the samples ready; it’s just a case of including them in the build. There are only two sounds planned;-
a. Activation of a player piece.
b. Countdown Bleep on the clock.
5. Change the Single Player title to Practice Game. This is a short change but it’s important to inform the user that the Single Player version is very short and not to expect much.
6. Help Files or instructions - These files have been written, it’s just a case of integrating them.
7. User Naming - Validation of the user naming code. User-One and all its case and variations have to be disallowed (User-one, user-one, user-1, user1, usr1, etc). That’s going to be my ‘handle’ when playing this game so there’s no way I’m going to allow anybody else to use it. J
8. Win/Lose Screens. These require images from the artist. One showing the player victorious and the other in defeat.

Still investigating ......

I'm in progress of upgrading the Nokia development kit from 2.1 to 2.2. I'm waiting on the serial code arriving through email.

However, this is not the only things I've been doing tonight. There are two documents which help in the process of learning the pitfalls of Bluetooth and J2ME. They are http://www.forum.nokia.com/main/1,6566,21,00.html?fsrParam=1-3-/main/1,,21_10,00.html&fileID=5005 and http://www.forum.nokia.com/main/1,6566,21,00.html?fsrParam=1-3-/main/1,,21_10,00.html&fileID=5284.

Both give a detailed overview of how Bluetooth works and the Example in the first document is exctreamly interesting. I've been pulling together the Tutorial in the first document to see how it will apply to the game.

Sent an Email off to the Artist. I'm still trying to put the concepts I want down on paper which is a lot harder than I first imagined it.

The Progress Bar

Downloading alot of Nokia Notes at the moment. Lot of Information to sift through !

Bluetooth Investigation Part 2

Looking into the Bluetooth capabilities was initially a little confusing. I had made the assumption that you could be a host and a client at the same time. Although, the API doesn’t allow it, it’s still possible for the game to appear to the user that it’s scanning and awaiting connections at the same time.

How? Well, first the UI is a simple List. With Bluetooth, there are two modes which you apply - host and client. Client mode just sits there and tells anybody who’s looking that they’re available to play. Host mode, searches though the ether to find anybody who has;-

1 – Bluetooth switched on (Device Discovery).
2 – Running the game’s service (Service Discovery), which means they’re in client mode.

The default mode for the game is client. However, once a minute or so (or even by user command), the App enters host mode and searches for people with clients active. If any players are found then the player details are stored within the app and the App re-enters client mode. The list is cleared and those stored players are displayed on the screen.

When an app becomes a host, it’s no-longer discoverable so therefore the searching for other players has to be a quick as possible. This might be a problem because the time Bluetooth takes to perform a Device Discovery and Service Discovery does seem to take quite a while.

If this is too slow then I’ll remove the timer and perform a search on User Command Only
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

Bluetooth Investigation

The first stage of a Bluetooth game is the player list. This is the screen which searches for and then displays players who have the game running and wish to play.

The idea is quite simple; the game has a Bluetooth service UIID and scans the local area for other devices running the game UIID. If one’s found then the player’s name and application level is requested. This player’s handle is displayed in the list screen, along with an icon representing what type of app level they have. (ie basic, standard or advanced).

This scanning and building of the list runs as a background task which re-runs once a minute, thus keeping the list up to date. The next stage will be to either challenge another player or receive a challenge from another player.

On a more positive note, I have received a reply from an Artist in the UK, whose willing to provide me with artwork for splash screens and so on. Hopefully, we can agree on some ground-rules and then I can put the artwork into the game.

Well that's plain wierd

It's now working.

Two classes were missing from the Jar. The Jar itself is now up to 134K but it still works on the 6600. Can't work that one out so I guess it's time to look up the manuals to find out why!

Wonder if it will work on the N-Gage ?

Still going to go ahead with the smaller graphics idea though. According to the properties, the 32 seporate PNGs come to 9.4k. The single Big PNG comes in at 1.25K. That kind of memory saving is not to be sneezed at.

Also when going through the graphics, I've found a subroutine I can drop, this should help with performance.

Bluetooth, here we come!

Ouch! I just hit a brick wall.

Who ever said size does not matter was lying. I’m now over 128K for this project that means it won’t work on any MIDP Phone. On top of that I’ve still got to code and test the Bluetooth multiplayer section. Presently this stands at 133K

There are four things I can do to shrink the code.

1. Reduce the number of classes I import in each place.
2. Rename all the arrays I use by a few characters. (a quick reduction might be within the clsQuickList class)
3.Take advantage of the new Image and sprite functionality of MIDP 2.0. I have 72 little PNGs, which help make up a map. Each player will use up to 32 of those for their side. So all I have to do is put all 32 into one big PNG, load that PNG and copy the relevant bit to the screen, as I need them.
4.Obfuscate the App. I want to leave this till last even though I know it will compress the Jar by 30-40%. I need my long variable names for debugging purposes.

All of these options will take time, so it will be split equally between the Bluetooth and the new size requirements. The smaller I can get the app with Bluetooth, the better the Obfuscation is going to be.

Ignorance is bliss.

You ever wish you had never asked a question? The response from the message boards has been a little depressing. In order to get your game on the mobile net for download, it’s best to put it on the carrier’s wap sites. Ie. O2, vodaphone, etc. The easiest way to get your game to a carrier is via a publisher, because the carriers don’t want complete cack filling their servers.

The problem is that publishers will offer a contract which basically removes all your rights to your own game, bit like the competitions that Nokia and Erricson run. I think this is the most de-motivating issue I’ve come across regarding my game development. I think it’s time to blow the dust of the indie developer’s guide to life book I bought in January. Hopefully it will give me a few pointers.

In the programming world, debugging continues. Another logic flaw gave the AI equal ratings making the AI Map reading useless. This one took three hours to find.

Debugging Continues

Well, thank god I got the Nokia Debugger working with my IDE. Lord knows how I came up with such messy, buggy code. Some of them are the typical Java Newbie mistakes, which I'm not too bothered about, but there have been quite a few stinkers.

I'm now debugging the main single player game loop, which is turning out to be a lot easier than the initial debugging. It's all a question of whether I get enought time in my personal life to get through it properly.

The MIDP 2.0 will have to be left for the moment. It will take too long to rewite the game engine to take advantage of the new features. Pity really, they are quite powerful and would have helped me out over the last year. I've really got a MIDP 1.0 game which relies on MIDP 2.0 for the bluetooth functionality.

I've put out feelers to a couple of J2ME development boards, to see if the business model I'm thinking about will work. Bit worried about this as other notices I've seen like mine, normally turn out to be vaporware.

Debugging

Now to my favorite bit in the whole development cycle. DEBUGGING! NOT !

This is the bit which really destroys your confidence because all that nice code you've been working on for the last few months is all wrong. And the only person you can blame is you.

So far I have discovered several howllers and I haven't even got to the beginning of the game loop yet.

Ouch !

Slow Progess

Oh, it’s going to long development weekend. Both Nokia and Sun have released new development kits for J2ME. It would be advantageous to install them, but I think I’ll wait until after the Single Player version is finished.

The AI routines are now coded, now the outstanding task is integrating it into a single player runtime. I’m going to have to make it clear that this is a one-shot practice version of the game so that people don’t get upset when they only have a single match. I’ll add a more complex single player game in the Standard version.

It’s the play testing of it that I’m worried about.

Angry with Myself!

Actually more like fuming, for two reasons.

1. I’m amazed how much I rely on the IDE to fix my syntax. I worked on some code in notepad over the weekend, thinking my Java is good enough just to cut and paste into the project at a later point. Oh boy! Was I wrong! I spent two hours last night just clearing up the code into a compiled state. Another reminder of how poor my Java, let alone my J2ME, actually is.
2. My game playing habits. As I got a break from real life I got quite a bit of coding fixed. However, after a couple of hours coding I thought, “I’ll just have a five minute break on Homeworld 2!” After what felt like ten minutes, I looked up at the clock to find it was 1 am. What a waste!

As a work colleague of mine pointed out, the only way to actually write a game is not to play games!