Check it out here: https://play.google.com/store/apps/details?id=com.iftracker

My first Squramble prototype on iPhone was built with the Interface Builder using standard iPhone controls…except for my UIButton “category” extension, that is.  And the UIButton’s were sort of pretty because I adopted a glowy button technique from the ‘net…but I definitely “wanted more.”  Squramble in concept is a fun-enough game, but it could be really great if it had cool graphics.

My initial brainstorming for the “really pretty” Squramble environment included some 3D landscapes through which the camera zoomed (beaches and palm trees!), rendered perhaps using Unity or some other commercial 3D engine.  I thought maybe the player would “play” Squramble on a 3D swinging wooden sign-board that hung from a 3D palm tree arm or somesuch.  But after some thought and research, this seemed a bit much for what is at heart a fairly simple “find the hidden word” game.  I decided that if I could get “some kind” of pretty animation, even 2D animations like fireworks or a moving timer, I would be happy.

The go-to 2D graphics environment for iPhone is Cocos2D.  Cocos2D happens to be free (even for use in commercial apps), approved for use in the App Store, and supported by an active community and tons of very useful online examples.  There is good reason Cocos2D is the go-to framework (because it rocks!), and I am fully satisfied with my choice of it as the graphical basis for my app.

My first experience with Cocos2D was the “simple game” application that Mr. Ray Wenderlich describes on his awesome web site.  This is an excellent “first Cocos app,” and in fact Squramble was called Cocos2DSimpleGame for a very long time, belying its starting point from the generous Mr. Wenderlich.

After changing the sprite that the “player” shoots at the “targets” (in the simple app) to be an actual, real-life, 2D colorful “firework,” I was ready to proceed with my own work.

I planned to start small by creating the “initial sign in” screen, but jazzing it up as much as I could manage with limited Objective C and Cocos2d experience.  During earlier Squramble prototype work, I had created a vector graphics “circular button” that I had intended to use as the backdrop for the puzzle letters.  So I hopped into Corel Paint Shop Pro and used that program’s drawing features to draw a nice, gigantic “PLAY!” button and a few other colorful circle buttons.  (I suggest using a vector graphics application and making every piece of your art gigantic, by the way…like 3000×3000!  This comes in handy for iPad, or iPhone 4 Retina, or whatever comes next.  You can always scale down from there for the real PNG files that you embed in your app.)

Right away, I found that the Cocos2D way of life was much, much easier than the Interface Builder NIB way of life.  You can easily add your own buttons and labels, and put the handlers for those buttons right where you want them.  The memory management aspects of Objective C are really minimized: just add an item such as a CCSprite to a layer, and make sure you [sprite release] in the dealloc routine.  (There’s a little more to it than that, in all honesty…but my point is that you can quickly establish a forward pace through your GUI elements and not necessarily leave a swath of steaming heap creep in your wake.)

Throwing GUI elements on the panel and making handlers for those elements is really, really easy…and it matches the paradigms of several other graphical applications I have made in the past.

With just three evenings work, I was able to make this nice “sign in” screen from scratch, complete with a lazy “blue ribbon firework” passing in the background, and unique “shrinky” buttons:

I was pretty stoked by this very fast progress.  My next step was to cart over my entire MFC prototype code and see if I could get XCode to swallow it.  (Keep in mind that my model and controller portions were entirely portable, and were hooked to a non-portable view via some nice, standardized calls.)  It was critical to ensure early on that I could use my model/controller/view code in iPhone – after all, if it didn’t port, there would be no Squramble game under the graphical hood.

With some elbow grease and luck, I was able to get XCode to eat a full meal of the Squramble model, controller, and view (with the MFC guts #ifdef’ed out).

At this point, the entire application was resident on iPhone…just waiting for the graphical elements to be added to expose them!  This was an awesome, motivating moment!  It was all there…you just couldn’t see it yet!

While I was in a firework frame of mind, I next worked on the “ribbon award panel” that shows up for each ribbon earned during a round.  Cocos2D offers many, many options here; check out the “Particle Test” to see an impressive roundup of what the base library offers.  (You can customize from there, too, with your own colors, bitmaps, speeds of rotation, speeds of particle decay, etc.)

I lucked out with this panel choice as my “second” panel.  Specifically, I had the “comet” streaking in from the upper right of the panel, to land in the upper-left area where I was going to place my blue ribbon graphic.  At the same time, I also experimented with scaling the whole ribbon award window from nothing to its final size.  What was crazy was that, since the “comet” was an element on that up-scaling layer, and that element was added outside the layer, way at the upper right and streaking to its home, the comet itself grew with the layer and took a very, very odd up-and-over curve toward its destination.  It’s fully strange and has (what I think is) a unique and fun look.  Paired with a circular “explosion” and playing a loud audio clip when it hits, I was really amazed.

Admittedly, it’s not rocket science or Half Life…don’t get me wrong.  What I’m saying is that, with very little effort or know-how, I stumbled on something that looked pretty cool and had a fun graphical buzz to it.  From here, with success in my sign-in panel and the strange exploding ribbon award panel, there was no stopping the Squramble motivation train.

Some months later, when I worked on the frustrating “ribbon list panel” that shows your earned ribbons in a finger-scrollable list, I realized just how lucky I was to have started with the sign-in panel and the exploding ribbon award panel.  At the time, Cocos2D didn’t have a finger-scrollable list that I could get to work, so I built the “ribbon list panel” using a standard iPhone UITableViewController.  Integrating this iPhone UI element into my Cocos2D base was a painful, five-day slog (though I like to think the results are okay).

But if I had started with that awful “ribbon list panel”…I don’t know if the third-and-final Squramble prototype would have ever gotten off the ground!

This post is “A Progression of Prototypes (or, “The-Idea-That-Sealed-The-Deal”).”

In addition to being frustrating, I can definitely say that the early days of iPhone application development are darned expensive.  It’s a good thing that the money flows like a rushing, refreshing waterfall once you’ve fielded your app!  (Just kidding…who knows?)

You can’t develop Apps on a PC, so you need an Apple computer.  It’s almost like these Apple guys are exclusively in it to sell you hardware and stuff, otherwise why wouldn’t you be able to “get your Objective C on” from your Windows box?  How can they possibly make money like this?

Further, you can’t really run/field Apps with just the iPhone “simulator,” because several things run differently on the simulator than on a real phone (in-app purchasing being a prime example)…so you need an iPhone, too.  Thankfully, having an iPhone has its own benefits, though (sorry Apple fans) I can’t exactly say the same thing for my spiffy new Apple computer.  While there are many things to dislike about the Windows experience, I’m pretty used to it by now…and, well, let’s just say that the Apple “Finder” tool is not the sharpest knife in Apple’s tool belt.  Also, the XCode development environment (compiler) is free, which is a good thing, but it, too, is an uncooperative beast – if you don’t agree, just try to get your build settings squared away from scratch for Debug, Release, and Distribution (with signed keys)!  And testing your code for in-apps purchases?  Ugh.

Anyway, enough grousing…Apple will probably withstand my meager complaints and will be happy to take 30 cents of every dollar my apps make, to boot.

I started with the Beginning iPhone Development book, progressing through “Hello World” and “Push this Button” examples, all using XCode for the development studio and Interface Builder for the screen layouts.  The book is good for showing how to do this, and also makes a reasonable introduction to Objective C.

My real goal was to get some “buttons on the screen” showing the game layout, populate those buttons with words-a-la-Squramble, and see if there was actually a game there.  My hand-drawn prototypes showed that there might be some fun to be had, but nothing beats trying to work through a real, randomized puzzle on an actual prototype.

Being a Windows (MFC) programmer at heart, my first instinct was to subclass the UIButton object so that “Squramble” (child class) buttons handled game operation.  Those buttons could store the letter they were attempting to represent, could draw themselves using whatever slick graphical appearance I wanted, and could also handle the application of game state changes.  This turned out to be difficult for a number of reasons, the primary one being that Apple doesn’t want you to subclass UIButton.  (MFC’ers can subclass CButton all they want, but there’s a specific-but-not-obvious restriction against this in XCode.)  The infuriating thing is that you can actually subclass UIButton all you want, but you can never get your own handlers to fire.  Eventually, though, I was able to get this to work by using the Objective C “category” class extension feature, which is even more free and easy than C++ subclassing because it allows you to add any old interface to any old class that you want.

Here’s a look at an early version of the button concept:

Once I got the button to draw and react, I spiffed up the graphics a bit and invented some visual “pipes” that connect them so that the user can follow the words a little easier.

With buttons and pipes in hand, I started on some game logic.  What happens when you tap a letter in the puzzle?  This turned out to be complicated, but moreso because I was just plowing through it without an overall design in mind; I really just wanted to be able to play some puzzles.  Wrapping my whole idea around a specialized subclass of UIButton was fragile and ill-conceived.

Eventually, though, it all came shakily together into the first iPhone prototype of Squramble, shown below.  The pipe logic was really squirrelly, being all wound into the button class, and all of the buttons didn’t quite respond as I wanted them to, but at least you could work through the high-level idea of Squramble without hand-drawing the puzzle.

Obviously, this mad-dash-to-prototype isn’t the technique that sealed the deal.  We all know this isn’t the way to program a real system, yet somehow it ends up being how many systems are really built.  Oh well…in my case it was sufficient as a proof-of-concept alone.

After proving its concept, the mad-dash-to-prototype failed in all other ways.  The Objective C class hierarchy for puzzles and letters was married right to the code that drew the buttons on the screen, and the pipe technology was unwieldy.  Following the triumphant proving-of-the-concept, Squramble languished because the developer didn’t want to wrestle with the flawed design.  Having to struggle with unfamiliar Objective C-isms didn’t help either.

The breakthrough came when I observed the in-progress version of IF Tracker, also by Looking Glass Software.  While waiting for some art and food database assets, my partner was able to get his entire application working…it was sort of a “shell” for the app, but one that was 90% functional and lacked only the “polish” of the final artwork and the “completeness” of the food database.  I said to myself, “I could easily get Squramble up and running (with a solid, pre-planned class design) if I didn’t have to worry about how pretty it was.”  All that fussing with making pretty, animated buttons was keeping me from making a solid game model under the hood.

From there, I also observed that if this application was written in C++, progress would be meteoric compared to the Full Stop pace that had been established for some months on the Objective C prototype.  As we have already established, I’m an old hand at C++, but a relative newbie on Objective C.  And it turns out that you can easily use C++ classes in an Objective C-based iPhone app…so…

The Idea-That-Sealed-The-Deal was to design and implement my game logic without worrying about the way the game would be shown to the user.  This, my partner informed me, was in fact a well-known programming technique called Model-View-Controller architecture (read about it in the Wiki, if you wish).

By switching to C++, I was able to build a very functional model of the puzzle logic needed for Squramble.  This model was driven by a cheesy MFC-based controller that handled button clicks and user input.  The controller and the model communicated the results to the screen through a view.  Both the model and the controller were portable C++, but the view was a Microsoft-specific MFC C++ dialog.  Progress in this area was absolutely amazing; a fully-functional and feature-complete prototype was done in 6 weeks (and do keep in mind that I also have a full-time day job).  Things went so swimmingly, in fact, that I was able to build my own flavor of “achievements” into the model: the Squramble “ribbon”…and to hand-build over 120 ribbons to include with the game.

Here’s a screenshot of the cheesy Squramble MFC prototype:

If you have a game idea but are having trouble getting into iPhone programming for some reason, consider my Idea-That-Sealed-The-Deal.  It doesn’t matter if your game interacts solely in the form of console input and printf()’s…that in itself might even be a good thing.  You can build it in a way that you want to build it, using C++ even, and you can make it pretty later.  Making progress = good.  Complaining about how hard it is to make progress on the iPhone while in fact making no progress = not good.

This leads us to the next blog post, which talks about the wonder that is Cocos2d.

Consider a game that chooses a word, mixes it up, and asks you to unscramble it as a minor diversion. What constitutes a good list of words, and where does such a list come from?

The game can’t just mix up random letters, right? It would be easy to program it, but you would be mad if you were asked to unscramble DACG to find the “correct” answer of AGCD. At a minimum, the words have to be words, according to some kind of English dictionary somewhere.

There are plenty of web sites that can give you a list of Scrabble-style words—yes, Scrabble words are words, and are in dictionaries of a fashion—but a casual game can’t realistically use these words, either. Unless that game has Scrabble in the name, I guess. My reasoning is that a Scrabble maniac might know that the word “BIX” means (fill in), but a mere mortal looking for a minor puzzle diversion is not going to enjoy a game that oh-so-cleverly hides BIX as XBI in any way.

So you can get a list of Scrabble words somewhat easily, but picking through that long list to find ones suitable for our minor puzzle diversion is no small feat. Primarily, by its definition, this task cannot be automated. Some person who knows something about words is going to have to look at each Scrabble word and give it the thumbs up or thumbs down. Unfortunately, that’s a lot of words to wiggle your thumb at.

For the list of all possible three-letter Scrabble words, this is a doable task, given the right tools to move the job along. For the four-letter Scrabble words, it’s a bigger job, but something on the order of tens of hours, again with the tools. For the five-letter Scrabble words, it’s pretty much insane.

All of this effort is intended to produce a word list that every casual game lover can enjoy. Every word chosen by the game has been vetted against a set of consistent standards.

I started making the four letter word list using this method and found that handcrafting your word list has drawbacks above and beyond the large amount of time you have to spend doing it. Everyone loves to supply arch comments on your word selections, and I hadn’t even hit the Internets yet! The word CAUL, for example, was the subject of some controversy, being near the beginning of the alphabet and likely to be selected by the prototype game at that point, with its limited word database. Of course, a CAUL is a troublesome biological “cover” that babies can be born with, but not everybody knows that.

This led to the conclusion that I needed “difficulty” levels if I wanted my CAUL. So now I needed to have multiple lists. And if you’ll allow me to get anatomical for a moment because this came up early in the alphabet: what about the words BARF and SNOT? These are actual words, okay, known to most people, and not on their own super medical or anything. (It’s easy to dismiss AGUE, a type of fever, as being too medical to allow at all, but not so much for those particular words for liquids that your head might emit.) It’s somewhat clear that you don’t want your family game to be expecting you to dig out the word BARF from its grid of mixed-up letters, but what if the player can complete the puzzle while using that word?

It became clear that, in addition to EASY words and HARD words (like CAUL!), I also needed a category of words such as DON’T USE BUT ALLOW. And while I was at it, I thought it might be fun to have a category for real curse words so that the game can give an achievement to people who complete puzzles using these words. After all, most of them are four letters, right?

I wrote a utility application to assist in the creation of the list. It runs on my PC, sorry Mac lovers. Below is a screenshot.

Squramble Word Definition Tool

When constructing the list, I can double-click on any word to go to a dictionary web site to see the definition. In most cases, I try to write a description of why I either included or excluded the word, though by the time I get to the “Z”’s that may go out the window. In any case, I can easily change my mind about a word (perhaps based on user feedback) and can recreate the word database files used by the game. I can change ACHE from an easy word (my original classification) to a hard word with just a few clicks.

This has worked out pretty well. Only players that bump the word difficulty above EASY will ever be asked to discern harder (or less-common) words like CAUL. And lastly, if the player finds a word that differs from the one chosen by the game—but one that is still valid, for example, POET and LOOM when the game picked POEM and LOOT—the full dictionary can be brought to bear in rewarding this creativity rather than penalizing it. And the same goes for common-but-icky anatomical words and curse words.

This entry talks about how the idea for Squramble-The-iPhone-Game came about.

The Story of Squramble

I’ve been developing applications for computers for a long time. Let’s just say that I created and fielded application programs long before we started calling them “Apps.” This includes simulators and test tools and data translators for my “real job” as well as games and general utility programs that I wasn’t specifically well paid to make.

My Mom called me one day and claimed she had an idea for a computer game. Her idea was that, presented with a grid of seemingly-random letters, a player would try to find a hidden word. The first letter would come from somewhere in the top row, the second letter from the second row, etc., until the player successfully formed a single word snaking down through the grid.

This on its own is a fair “starting idea” for a game, but it presented a number of technical problems. First, let’s say the grid looked like this (without the boldface emphasis of course):

B T P Z
T I E O
S O C E
M K K T

The game is expecting the player to zoom from top to bottom seeking and finding the hidden word TEST, presumably under some fun timing or scoring pretense. Upon identifying TEST, another puzzle would be generated. I asked my Mom, “If my game picks the word TEST, what am I supposed to do when the player finds the word POET instead?”…or “TICK”…or “PECK” all from the example above. It sounds like a pretty easy game to make, just pick out a random word, mix up some letters around it, and then wait for the player to tap it in…but the need to somehow “know” all the other words was daunting. Test? Yup, check. Every other valid four-letter word? Not so much.

So I thought about it a little more, and it occurred to me that I could guide the player into selecting the words I picked and mixed by picking four words instead of just one, and requiring the player to be able to make four words. If the player doesn’t find the four words that I picked, it is somewhat unlikely he or she would be able to use all 16 letters in valid words. At that point I could either be rigid about requiring the original four words, or maybe even get fancy by allowing valid alternatives.

I sketched out some sample puzzles with words I made up on the fly, and what do you know? It’s actually somewhat of a challenge to find the four words amidst the jumble.

A T P Z
T I E O
S O C E
M S K T

Finding ATOM, PICK, TEST, and ZOOS in the above matrix (running from top to bottom as my Mom originally envisioned) isn’t super easy, or at least I didn’t think so and my wife didn’t think so. This runs counter to the opinion of most of my friends who thought at first that the idea would make for a game that was “too simple”…but no, it’s challenging enough. Adding a three word option made it even more casual and easy, and adding a five word option made it significantly more difficult. I tried a six word option, and it was just no fun whatsoever, which is why Squramble currently only goes up to five letters at a time. Even the five letter option skirts the boundary of maybe a little bit unfun, but there are probably those that will really enjoy it.

Shortly after making the hand-drawn grid prototypes, I sketched up some screen ideas for the actual game and came up with the snappy moniker “Squramble.” Because it’s a square, okay? And it’s scrambled. Match made in heaven, and you can be sure the domain name “www.squramble.com” was available (though I still haven’t populated it with anything useful, so don’t bother).

It was about that time when the words started to flow from left to right, as you see in Squramble today. People just like to read left to right, so that’s how the game progressed.

http://wellspringshealthsciences.com/directory/item/3-news-item-2.html

http://www.theledger.com/article/20110118/NEWS/101185003/1326?Title=Check-Out-11-Ways-to-Get-Healthy-in-the-New-Year-

You can read more about it here.

iPhone App Finder recently reviewed the IF Tracker giving it 8.8 out of 10 while saying, “An impressive tool for those looking to adopt an anti-inflammatory diet.”