I started fucking around with programming Java in probably 2000 or 2001. I had never taken a course, read a book, or otherwise seen or written any code since, well, ever. So I bought a book with the deceptive title Teach Yourself Java in 21 Days. Here it is at least a decade later, and I am still a long damn way from actually knowing the language. Despite that, I have made leaps and bounds in my programming knowledge along the way.
Here you see my first ever completed Java Program (click through for real size). I had made a few other applets along the way, but just silly little image cycling and displaying type stuff that took very little knowledge, and I don’t think any of those exist on any of my backup disks. This is the first playable game that I ever made (well, a screenshot of it). It was probably the happiest day of my life when this applet was the “featured applet of the week” on the Java Boutique shortly after I finished it. After that though, I pretty much gave up on the language entirely. Why? Well just look at that applet. It is very blocky and drab; it clearly looks like someone’s first applet. Not to mention that since I didn’t know anything about arrays, I had handled all of the blocks in the grid in a ridiculously complicated axa, axb, axc, … bxa, bxb, bxc …, type manner that made the code overwhelmingly long (over 1400 lines of code) and difficult to understand. Simply put, nothing in that applet taught me how to do anything because, while I did soldier through and make a working game, the way I handled every single thing was just flat wrong.
Shortly after the release of the Android, a friend’s suggestion that we should start programming games for the device (which runs on Java, but with a different enough library that it requires a completely different knowledge set to program), combined with a game idea that came to me for the game Cubits (click through to play Cubits on the GoGamesZone), got me excited enough to give programming another go. Unfortunately Cubits proved to be too difficult to play to become popular (though I still love the concept, and love playing the game). The game was successfully ported to the Android OS, and along the way the friend who ported it over helped me learn a great deal about the Java language. I then decided to go completely the other way with it, and created HyperSpheres” (click through to play HyperSpheres on the GoGamesZone). This game uses most of the methods from Cubits, but simplified the game play so much that it is way too easy to play, and as such it also doesn’t get much play. These games were both conceived entirely in my head, without doing any research into what puzzle games were the most popular, and without doing any of the requisite legwork, the absolute flop of both should have been expected.
So for my next, and most ambitious project, I chose to go with the popular match three item type games to see if I could get a bit broader appeal. What I came up with is Fruit Madness (click through to play Fruit Madness on the GoGamesZone). Fruit Madness is just like all of the jewel matching games that are so popular. I went with fruit instead of jewels for two reasons: 1) so that it would stand out a little bit from the myriad Jewel matching games and 2) because in my head I had this super cool casino type theme that I wanted to implement. So when you clear a group of 3 blocks the fruit drops away, but if you clear 4 blocks one of those blocks will turn into a “Spin” block (the spin is a wild block that can be matched with any group of two blocks. It will then spin, slot-machine-style to the same fruit as the ones adjacent to it). But the real fun starts after that. If you match 5 or more fruits, one of the blocks will turn into a gold “Super Spin” block. This block has the ability to turn all of one type of fruits on the board into “Spin” blocks. The spin blocks can also be matched to each other in groups of three or more, in which case they will all spin until they come out in a matching group. The feel of the game really did come out like a big slot machine. Between the mechanics, the audio (some of which I was able to download, and some of which I created the midi files from scratch to match the theme I was going for), and the images (which started as images gleaned from the internet, that were then modified -heavily- to get them to look uniform to the game), not to mention the big, neon sign on the top of the board, I nailed pretty much exactly what I was going for with this one.
But here’s the problem. Still suffering from a lack of programming knowledge, the code for this game is a whopping 2000 lines. Many of the methods used in the game must be used in a sequential order that makes it impossible for me to go in and make edits to the way situations are handled. An example: the biggest difficulty in the game is how to handle when the spin blocks will spin automatically and when the user must initiate it. I had initially programmed the game so that the blocks would only spend if the user had initiated it (meaning actually moved the spin block during the current turn). What this did (and what I would have known had I done any testing whatsoever) was made it possible for someone to get about 80% of the board filled with spin blocks, after which the game could go on, quite literally, forever. In order to change this, I decided to go exactly the opposite way with the spin blocks: they would all spin if matched at any point during the game. This meant that if you made a clear that caused a spin block to drop into a matching position it would automatically spin. Long story short, the idea is that there will never be a time when there is a valid match on the board since they will automatically clear themselves. The way the code was written though, I had to add a bunch of methods to try to handle this, and it is far from perfect. The only way to remedy this will be to completely scrap the code and start over, something I am loathe to do with such a large code that functions almost as intended. But it was another lesson learned.
This brings me to Kerpop (click through to play Kerpop on the GoGamesZone). Taking what I had learned from all of the previous experience, Kerpop is the most mechanically sound game I have created to date. The mechanics are every bit as complex as any of the previous games, but are handled in a mere 1100 lines -that’s almost half the size of Fruit Madness-. In addition to being the most mechanically sound, it also has by far the best combination of graphics and audio of any of my games. The graphics in this case were created completely from scratch, while the audio was gleaned from some slide whistle samples I found at freesound.org. As near as I can tell, the mechanics in this game perform flawlessly; I have played hundreds of games without a mechanical error (some may note that if a group of balloons is in the process of raising and you clear another group it will make that first group restart their ascent. This is true, however since that is how the code is written it is not a mechanical glitch. This led to me rethinking the way I handle the animation timers though, and in a planned sequel to KerPop, every balloon will have it’s own timer to eliminate this).
I took a few steps back from programming over the last six weeks or so. I am still kicking ideas around in my head, still actively working on the sequel to KerPop, and have one other interesting concept that I am working with a friend to try to hammer some potential mechanical problems with before I go to programming it full scale. This short hiatus has given me a chance to clear my head of the code a bit, and is ultimately what led to me writing this today. I actually went and played each of these games today as a fan of puzzle games for the first time -every other time I had played them was as a programmer, and I didn’t take away from those sessions the same experience that a player would- and I was just blown away by just how far I had come as a programmer. They may still have a couple of little bugs here and there, but for someone who has never had any training in Java, audio engineering, or graphic arts, I am damn impressed with the results that I have thus far achieved. Now if only I could get more people to agree and play the damn games…
To finish this post more or less where I started, I recently got another request for the source code for Lightz Out (click through to play Lightz Out on the GoGamesZone), and was so embarrassed by the code that I decided to rewrite it (I still get requests for the code once every couple of months. Usually from kids in college or trade schools taking courses in Java that want to see how to make a simple game work… the old code was not going to help them). I set about to re-writing the game without using any of the old code. In fact the only thing that made it into the new game was the audio (for nostalgia really, since this game is a direct rip off of Tiger Toys handheld game and I sampled the audio directly from that device.). Every method in the code was changed: the overly complicated board layout was changed to a simple boolean array; the hints were put into a separate method that makes their use more reliable; the graphics were updated to bring it into this century. The only reason I used the old code as a reference at all was to know the layouts of the fifty boards (again stolen from the handheld device), the exact hints that were given on the boards (also stolen from the game), and to know what the minimum and maximum moves were (also taken from the handheld game). Did all this modernizing increase the size of the code? Nope, exactly the opposite; the old code was 1434 lines, the new code is 399. Additionally the new code is handled quite well (I think) and is heavily commented so that when I do surrender the source code it will be helpful to those who are reading it.
Along the way I have learned how to handle arrays fairly well. I have learned how to use some simple graphic tricks to make mouse-over buttons that change colors. I have learned how to create fairly decent simple graphics. I have learned how to create a separate, system-based timer for every object on the board to move separately. I have learned how to store the entire game board all the way back to the very first move for the purpose of undoing them. And, probably most importantly, when I look at the finished projects like KerPop and Fruit Madness, I am filled with pride that I was able to handle all the elements, from code to finished graphics and audio, with nothing more than determination and a bit of technical advice from a friend (mostly in handling arrays and reciprocating check methods). And now that I have taken some time away and had the opportunity to see how fun the games are to play, I am getting excited about creating the ones that I have currently shelved. Who knows which one of these could become the next Angry Birds.