These ramblings here are more for the programming-oriented people but even if you're not such a geek, you might still get something interesting out of it.

It's my first game written using the SFML graphics/audio library. So far, I like it a lot. I thought about using SDL, but considered it a bit too low-level. SFML already has things like sprites with scaling and rotation built-in, so I don't have to blit my own graphics. Which is I what I wanted for this project - I wanted to work on the game, not the framework to support it. I'll be using SFML in the future, for sure. I'm already using it in my multi-player shooter, as it also supports networking.

On the minus side, the framework has little to no GUI functionality, you can only print text on screen and draw basic shapes. I looked around for SFML GUI libraries, but nothing really caught my eye. That's where SDL has the advantage, it has many fully functional GUI libraries available.

The game itself was an interesting project to tackle. Though it looks like a small game, there were many things to work on. I got the core gameplay of pushing and pulling boxes working in about a week. Then I hit a roadblock.

How do I shuffle or mix up the tiles, so that I could guarantee solvability?

At first, I wanted it to be random, with boxes scattered all over the level. If I provided the shuffled state of each level, there wouldn't be much more than one solution. I thought about it for a while and tried all kinds of algorithms to mess up the game field. At one point I even implemented a pathfinder into the mix to make sure the level could be solved. That turned out to be too slow when loading the level.

Then I had an epiphany!

Scrap the scattering idea and hold on to your tube-socks! If I simply took the solved state and randomly swapped positions of differently colored boxes, it would result in many unique variants, all of which would be solvable, solely dependent on the level design, which is fair. If the red box ends up on the blue tile and blue box ends up on the red tile, it's all you need to provide the challenge. If the level is designed so that it can be completed, in can be completed from any initial state, I think. Of course, some variants will be easier and some more difficult to solve, but the overall difficultly still comes from the level design not from the shuffle algorithm.

Level design was in fact the other tricky thing about the game, specifically making levels increasingly difficult. That means playing the game through over and over again but I can't be the judge of that. I'm too involved. So, few people tried it and I used their input to order the levels, as best as I could. I can't imagine if there were to be 50 or 60 levels instead of 30, the amount of balancing that would take is immense.

I should probably do a mobile version next. Or maybe I should've skipped the whole downloadable type of game and gone for HTML5 straight away? There are probably dozens of tile sliding puzzle games on the iOS and Android, but I don't know too many where you actually have to move the tiles with your character, meaning you have the extra task of being able to reach the tile you want to move and not corner yourself in. That, I think, makes it unique.

My first and certainly last Java Applet game. Hearye, hearye! I promise to make all future browser-based games in HTML5, which isn't quite mature yet, but it's getting there. I haven't really dug into it, but I've tried the basics. I like it!

Anyway, the game started out in a boring class, where I had my laptop with me and nearly 3 hours of boredom. So, I decided, having completed the "Hello, World!" program in Java class recently, that I want to make an applet-game. So by the end of the lecture I had the simplest form of maze game up and running, with a placeholder character sliding about. I was happy with the result and decided to make it into a game.

The story is quite silly and full of clichés, but it does make fun of itself and in the end, I thought it wasn't too bad. It does involve a princess, which is the oldest story in the book, but it's mostly in the title and not much in the game anyway :)

Now, about why I don't like the Java applets. As with everything web-based, there's no certainty. At the time of development, the game loaded and played well in my Firefox but would sometimes fail to load images on Safari or Opera. Then again, it loaded and played perfectly on those as well. Was it to do with a specific version of Java or the brower or the combination of both, I don't know. I think it worked on IE as well, of course, if you had anything better than IE6, which sadly was still used in some places. Also, Java isn't installed on many computers and forcing the player download and install it just for the game is not a good idea.

That's why, in theory at least, I like HTML5. People having (or going to have) a newer browser that supports HTML5 is more likely than them having Java installed. Also, HTML5 allows your game to run on the mobile devices, which is a great bonus.