Today’s post is going to be about my independent senior project at Loyola Marymount, Celldoku. I graduated in May of 2006, however only got around to uploading it into Sourcefoge a few weeks ago. I did plan on continuing development on it, however that plan was put on the back burner when I decided that I would go the iPhone route when ever/if-ever they release a 3G version of the phone. Those plans went back onto the front burner when the rumor mill on the interwebs said that Sun is planning on porting a Java runtime environment to the iPhone (thanks to the recent announcement of the SDK). However I may end up recreating the project as a native iPhone application. We will see.
Celldoku is a Java 2 Micro Edition implementation of a basic Sudoku game. There are 4 different difficulties to choose from. Due to the extremely complicated nature of generating a valid Sudoku game, I did not even attempt to implement that aspect of it. The cell phone I was using at the time was far to slow for it to be a plausible route to pursue. Instead I have four static boards preloaded into the game, one for each difficulty. However, thanks to the idea of Caskey Dickson, one of the brightest people I’ve met, and educator in the computer science department of Loyola Marymount, I was able to implement a series of transformations that make it seem like you are playing a different Sudoku each time (for instance, moving rows around, but restrict it only to the 3x3 sub-grid which that row is in. Then do the same with columns. Inverting the board and moving entire 3x3 sub-grids around). Also by changing numbers around (for instance, all 4s become 3, all 3s become 7s, etc) you also get a feeling of randomization.
A solution I had to this problem was setting up a web server that would serve up Sudoku games to my Celldoku in a form it knows. That way if the user ever gets bored of the current board, a new game board could be downloaded from my web server and cached locally on the phone. That way not only do you get a board that has been randomized, but you can get a totally different starting board as well. Caching can be used if the user had no cell phone service, to still give quite the randomized experience during play as then the boards would be pulled from the local cache of boards. Alas, I never got around to implementing that for the final version turned in for class credit. That is on the list of things to do.
Now here is what sucks about it. Everything about that game is pretty much hard coded. If you have one of the original Motorola Razr V3 phones, then the game will operate, more or less, flawlessly. The screen dimensions are hard coded, as is the cursor movement. Although I would have loved to get all that code cleaned up prior to releasing it, I just never got around to it.
Future plans for the game include a dynamically built board to allow for play, as well as maximum enjoyment, on all types of different sizes of screens. I wanted to give the user the ability to put in numbers on the sides of boxes, much like how a typical user plays a Sudoku with a pencil and paper. The game gets extremely hard to play if the user cannot take notes. And don’t forget, the ability to contact my web server for more boards.
The project was built using WTK 2.2 from Sun, Eclipse and the EclipseME plug in. Using the tutorial on EclipseME’s site, there should be no problem getting everything setup and configured correctly. Then just build the JAR/JAD files and deploy to the device. Please contact me if you have any questions regarding this game.
I guess it might be a good idea to provide an actual link, just to be sure:
I have decided to start hosting my projects on Google Code. And as such, I have moved all source files there. The current SourceForge version has been orphaned and will not be updated.