Manly Code

Lean iPhone Game Development: Day 10

2011-07-20T00:00:00Z

It’s the night before I’m supposed submit this game to the iTunes App store. I don’t have a starting menu, I don’t have an icon, or a splash screen, and I only have some basic game mechianics working. What’s a developer to do?

What went wrong?

Aside from my own hubris, a few cards were stacked in the deck against me. I had forgotten about family obligations in this last half week of development. This took time away from development, and also writing updates about the project.

Also, Victor the designer had a busy week at work this week. So the character design for the game has been pushed back (beyond the original end date).

Changing Gears

Since Victor couldn’t help out with the character design, It was up to me to produce the artwork for the game. And I’m not artistic. So I had to simplify things.

While my PhotoShop skills are limited, my MSPaint Skills are amazing. So I decided to make the game pixellated and have a retro feel. That means the general theme for the game would have to change. So now instead of Bastard Bricks, it’s now Bit Bricks.

What went right?

After several days of fumbling around with Box2D and not making much progress, some advertisements on raywenderlich.com caught my attention wile I was reading through a tutorial. So I clicked on them.

They took me to the websites for LevelHelper and SpriteHelper. LevelHelper is a desktop application that lets you drag, drop, and customize objects in a level. This can then be exported and loaded into an Objective-C application. This is everything I was trying to do programmatically, but failing miserably at.

SpriteHelper takes an image, detects sprites in that image, then exports them in a format that allows you use them within LevelHelper. It also exports them into a format that allows you to use them directly in Cocos2D as well.

These two tools are amazing. The UI is a little clumsy to use, but for the pair, I paid less than $35. I definitely got my money’s worth.

In addition, I found a tool for authoring bitmaps bitmaps pixel by pixel called Pixen. I haven’t used this much yet other than creating squares, but it looks promising.

Demo

Although I’ve been quiet for the past several days, I have been working hard on Bit Bricks. I still need menus, and bosses. But so far I have a functioning Breakout clone.

You can see the progress that’s been made here: Unable to display content. Adobe Flash is required.

Submission to the Apple Store

Tomorrow, I’m going to try to cobble up a menu screen and submit Bit Bricks as a “light” application. Since it’s very light on features, I don’t want to start charging for it quite yet. But I also don’t want to back down on my goal of submitting this on the 11th day.

It’s going to get rejected on the initial versions. So, to make lemons out of lemonade, I will be posting updates about the Apple Rejection process.

Lean iPhone Game Development: Day 3 & 4

2011-07-15T00:00:00Z

Things have not been going well for this project. I’ve been encountering road-block after road-block. The past two days have been spent mostly reading documentation and tutorials.

Required Reading

For the most part, I’ve been reading and re-reading the Box2D manual. It’s a great library, which does all the heavy lifting for position calculation and collision detection. It feels really awkward to work with though. It’s been a while since I’ve touched C++, so the syntax is a bit unfamilliar. In addition, the C++ syntax looks gross sitting next to Objective-C.

I’ve also been reading through Ray Wenderlich’s Tutorials. This blog has several really great iPhone tuturials. Where it shines are the Cocos2D tutorials. There’s even a tutorial on how to build a Breakout Clone.

What happened to my frame-rate?

I was able to get the ball moving around the screen by removing gravity from the world (the physics context which objects move around the screen relative to). This eliminated the need to add a vector to the ball to balance out the world gravity. Progress.

But upon running this in the simulator, I noticed that the frame-rate had dropped from 60.0 FPS to 20.0 FPS. That’s not good. Especially when this is in the simulator.

I set up my provisioning profile and ran the code on my device. And just as I expected, it was much worse. 7.0 frames per second. Completely unusable.

So I’ve got a lot of work and experimentation ahead of me. Hopefully things will pan out.

Vino Veritas

2011-07-13T00:00:00Z

There will be no “Day 3” on Day 3. It’s taking me forever to write about what I’m doing (I write slowly). And also, I’ve been social with friends today. Expect a digested post of Day 3 and Day 4 with the next post.

Standing On My Soapbox

In the interim, if I may stand on my soapbox for a minute.

If you haven’t lately, get into a conversation with a stranger. As a developer, I find my technical skills to be adequate, but my people skills have something to be desired. But, in software development, communicating with people is a much more important skill than slinging code. And getting better at this is something I’ve been trying to work on.

I got into a conversation with a stranger tonight. It was brief, fun, and interesting. So the next time you overhear an interesting conversation, butt in. You’ll know if you’re welcome or not. If you’re not, then who cares? You don’t know those people anyway. If you are welcome, then you’ve gotten yourself into an interesting conversation, haven’t you?

I’ve never been all that good with engaging with people. But I find the more I do, the easier it gets. It’s when you stop caring about what others think about you that you can let go and really get good at talking and listening to others.

Lean iPhone Game Development: Day 2

2011-07-12T00:00:00Z

Sometimes the second steps of a journey are just as difficult as the first. Today I finally dug into development and discovered that I’m in over my head in a few areas. To parrot the sentiment of Teen Talk Barbie: “Physics class is tough!”. I don’t have much choice except to buckle down and learn this stuff as fast as possible.

Working Prototype

Before putting any effort into design, I must first prove out the basic concept of the game. Doing design work for a game that won’t fundamentally function is like polisihing brass on the Titanic. Completely pointless.

Frameworks Galore

After taste-testing a few game engines I settled on Cocos2d as the game engine for Bastard Bricks. It’s free and it has an extensive community behind it (something I always look for when choosing an open source library).

Best of all, Cocos2D provides Xcode templates which create boiler-plate projects for both Chipmunk and Box2D. I wanted to incorporate a physics engine as the main means of motion for the sprites. These templates make my work much easier. I settled on Box2D as that seemed to be what most others on the Cocos2D forums were using.

Fleshing Things Out

Out of the box, the Cocos2D/Box2D demo app looks creates bricks that drop based upon the gravity setup in the Box2D environment. It looks something like this:

To create the stack of bricks at the top of the screen, I reverse the gravity:

This made it so that the bricks would float to the top of the screen. Then I place brick sprites on the screen next to each other in 4 rows. I calculated them as carefully as possible, but I let gravity do most of the work. In addition I colored each row similar to the Atari Breakout. That just makes it look kind of nice.

I was also able to add the ball as well by copying the sprite configurations for the bricks, and then modifying it. The Ball drops in the direction of gravity, then comes to rest on the bricks. Not too exciting.

The Next Steps

This prototype is nowhere near complete. There’s several things I’d like to get working before I’d be comfortable with proceeding. First, the ball needs to move. I’ll have to figure out a way to balance out the gravity and then give the ball its own motion vector.

Also, I still don’t have any sort of user interaction. I need to get the paddle on the screen and have it react to touches.

As long as I can get these few things squeezed into this prototype. I think I can make this work.

Lean iPhone Game Development: Day 1

2011-07-11T00:00:00Z

The first steps of any journey are the hardest. Today I was able to get most of the tedious things out of the way. But I was also able to squeeze some of the fun things in too.

The Busy Work

Although this project is not billable (workin' for free!), I set up a Harvest account in order to keep tabs on where my time is going. I want to keep time spent on this project to a minimum, so I’m using Harvest as a tool to keep an eye on things.

I also renewed my enrollment in the Apple Developer Program. My initial estimate of sunk costs was $99. I didn’t consider the tax. There’s always tax. The cost invested now is a total of $104.94, which moves my initial sales goal in the first month up to 150 units.

It’s going on 3 hours now and I still haven’t gotten a confirmation from Apple that my order was processed. This is just one of the many headaches I have to deal with involving the Apple mobile development process. They do desktop UX so well, why can’t they apply that to their web services?

The Fun Part

I came up with the idea for this project a while ago. I knew I’d have this large chunk of free-time ahead of me and wanted to work on a pet project I’d been thinking about for a while: Hell Panzers.

The idea for Hell Panzers is a mobile turn based strategy game using tanks. But really it was an excuse for me to mess around with NodeJS. I’d not only have to create a client to play the game with, but also a server to run the turn-based portion of the game. This idea was simply too large for my own abilities. I needed to scale back.

Sipping coffee one day, I had an idea. Re-create the Atari favorite Breakout, but put a modern spin on it. Breakout is a simple game. You control a paddle, you bounce a ball against some bricks, and the bricks disappear. That’s easy enough to implement. This simplicity makes it a blank canvas for creativity.

What if the bricks had personalities? What if they had different behaviors? What if they had cute faces? Or ugly, angry ones? What if they fight back?

There are so many possibilities!

Lunchin' and Sketchin'

My classical training is as a developer. I can picture how things should look visually, but I have a difficult time executing it (refer to my concept sketch from the last post). I’d need a lot of help designing this thing.

I struck up a conversation with Victor Sirotek about my idea. I work with Victor. He’s a designer at Mutually Human Software. But more importantly, he’s a gamer, he can illustrate, and he liked my idea. So we grabbed lunch.

Over some delicious cuisine we threw ideas back and fourth. Mostly about character design and gameplay. Having the bricks be just that, bricks, is boring. You hit them with the ball and they disappear. That’s not interesting. So we decided to give them faces. Angry ones. Ones that get madder and madder each time you hit them. They wobble and shake, get furious and attack you.

I sketched out the basic dynamics of the game (Breakout, but using a physics engine). Then Victor sketched a character in detail. At the end of lunch, our heads were swollen with ideas of how we want this thing to work. The biggest take-away from the discussion was the working title for the game: Bastard Bricks.

We both decided that before doing any actual design work, we should prove out the feasibility of the game dynamics. So tomorrow, I will create a functional prototype and get it in front of people.

Lean iPhone Gaming: Building a Product in 11 Days

2011-07-10T00:00:00Z

Taking lessons learned from lean startups, I’m going to build and market an iPhone game in 11 days. I have no experience in game development, but why would that deter me?

Finding Inspiration

This past May I had the opportunity to attended the West Michigan Lean Startup Conference. I originally hadn’t planned on attending. I thought the event was sold out before I had the inkling to go. Fortunately for me I was able to attain admission.

And I’m glad I did. It was an excellent conference, and I came out of it understanding how modern businesses are created.

I took some of what I’d heard with a grain of salt. I’m a skeptic by nature, and some of the things they were talking about seemed un-applicable to a tech climate like Grand Rapids, MI.

After all, several of the speakers were from “The Bay”. My impression of California is that you can’t throw a rock down the street without hitting a VC or angel investor willing to take a risk on your rock throwing startup. While West Michigan has a growing tech scene, it’s a far cry from the leviathan out west.

Lessons Learned

Skepticism aside, I did walk away from the conference full of ideas and inspired. Much of what I did take away from it was the essence of what everybody discussed.

First and foremost build something and show it to people. I’m a developer and as such, I build things. I can’t count how many times I’ve built something an never shown it off because “it’s just not that good”.

If you show your product to people and elicit feedback from them, then you can determine why it’s not good. You can then tweak it until it is a product that somebody wants.

Who cares if it’s a failure? As long as you minimize the cost of failing, your return on investment is the knowledge gained from doing things wrong. You can always try again, but with the lessons learned from your past mistakes.

The Ground Rules

So I’m going to apply the lessons I learned at this conference and flesh out an idea I’ve had for some time.

This idea is a video game for the iPhone. It’s going to be a casual game very simple. I intend on marketing it for 99¢ on the iTunes App Store. I want to make it something I would play, and something that others would enjoy playing.

My main goal is to break even (on actual costs) within the first month. Right now my only cost is paying for the Apple Developer Program ($99). If I make 70¢ per unit that means I need to sell 143 of them. On the 11th day I will submit whatever I have to the iTunes App Store (regardless of done-ness).

As it goes without question, my family and career come first. I have a 9-5 at Mutually Human Software that I need to stay sharp for. So I need to be cautious about how much time is spent on this so as to avoid burnout.

I’m hoping that these constraints will help me get things done faster as opposed to thinking about things I need to do and leaving deadlines open ended.

Stay Tuned!

Each day I plan on blogging about my progress. This is very much a learning experience for me. Not only because of the technical hurdles I’ll have to bound, but also because it’s my first experience with marketing and customer development.

Setting Firebug Ablaze With 'debug;'

2010-12-02T00:00:00Z

Firebug is a tool well loved by all web developers. You can modify CSS on the fly. You can view your DOM. You can easily view JavaScript errors. You can even debug JavaScript. I’ve never really used it for that though. I’d always found setting breakpoints in Firebug to be tedious. But after today, things have changed for me.

Setting Breakpoints Within Firebug

Whenever I wanted to set a breakpoint, I would first have to click through a file list in the script tab, then scroll through the source to the line I wished to set the breakpoint on, click on it, then reload the page. Too many steps. I’ve always opted to litter my code with console.log(); instead. That much simpler to do than setting a breakpoint. This console technique has served me well for the past several years.

Setting Breakpoints Within JavaScript

While working on a project with my fellow developers at Mutually Human Software, I found myself having to set several brakpoints for some JavasScript. Tired of this, I did a Google search for “setting a firebug breakpoint in code”. The Google gods smiled upon me and blessed me this this little gem: how to set breakpoints from within JS code?.

Amazing! You can set breakpoints from within your JavaScript. Simply call debugger; in the place where you would like the browser to stop executing the JavaScript and hand control over to you.

Here is a small example. Say you have an HTLM file that loads the following JavaScript file hello_debugger.js:

If you start Firebug and view the HTML file, the “debugger;” keyword gets interpreted and Firebug breaks the execution of the code.

You can set a watch expression or peek at the status of DOM elements at this point. In addition, the console has the same context as the location of the breakpoint.

In this snapshot, you can see that the console has full knowledge of anObject and anArray. This is the same context as the closure that lexically scopes the contents of the hello_debugger.js file. From the Firebug console, if you type in:

Then you’ll see from the alert that the object is in-fact the one you defined in your file.

I like this method of using console rather than setting up watches. Since I’m a rubyist, using the console feels more like using the Ruby debugger as opposed to using the GUI based tools provided by Firebug.

Calling debugger; from code also works in Google Chrome. I haven’t tried this with any other browsers though. So give it a try. Hopefully you find this to be a useful item to have in your toolbox too.

Obviously, You're Not a Golfer

2010-08-19T00:00:00Z

JavaScript is production code and should be treated just like your server side code. It helps define the user experience of your web application, so it’s important to write robust JavaScript. In the past, web applications were essentially server driven front ends for databases. JavaScript was used to add a little polish to these front-ends. But with HTML5 gaining traction, web applications are becoming rich client-side tools available not only to web browsers, but to mobile devices as well. JavaScript will play a much larger roll in your day-to-day development of web applications in days to come.

TDD and JavaScript

For the longest time, I didn’t use TDD when developing in JavaScript. At the time I only needed to use JavaScript to do minor DOM updates. Eventually I had to code forms that included business logic. As the complexity of the code increased, the likelihood of my code being altogether broken increased as well. I had to re-evaluate how I was using JavaScript.

For a majority of my professional development career, I’ve practiced Test Driven Development for all of my server side code. TDD is something I feel very strongly about. I write better code when I practice TDD. It makes me think in advance about how to design my code. My code becomes more modular as complexity increases, which makes it easier to maintain. Most importantly though, TDD give me confidence about my code. So why didn’t I originally feel the same way about TDD with Javascript?

The root cause was that I didn’t understand the language. Being a Rubyist, I’d treated JavaScript much like ruby. I’d become accustomed to the hand holding that the Prototype framework provided since it was included with Rails. My code was a mess and it would take me significantly longer to develop in JavaScript than Ruby. So I broke down and bought (I hate purchasing technical books for specific technologies) JavaScript: The Good Parts. It was very insightful and for me it was shocking to see how incredibly incorrect I was about how to use JavaScript.

Now I’m able to think and code in JavaScript. I then applied the same principles of test driven development to my JavaScript work-flow. I tried a few testing frameworks (JSUnit, and ScrewUnit) but eventually settled on JSpec.

JSpec is a behavior driven development framework based on RSpec. Snice I do all of my unit level testing with RSpec, JSpec was a comfortable fit for me. It has a DSL to define specifications (before, after, describe, and it blocks). And also a matcher library to add some syntactic sugar to your assertions.

…let’s go bowlin'!

The following is JSpec in action. It uses the Ron Jeffries' bowling game as an example. This is generally the first bit of TDD a developer sees. It explains the general red-green-refactor workflow of TDD, and stresses the importance of keeping your code clean.

To begin a JSpec project needs to be created.

First, install JSpec and set up the project:

The library file and its spec file get renamed to something that has meaning. The test runner also needs to get updated to reference the renamed files:

Now, start the spec watcher:

This starts a process that detects changes in the spec or implementation files then opens a Firefox tab that runs all specs for the project.

There needs to be a place to hang the code, so the initial test will ensure that the library exists.

It fails with “ReferenceError: BowlingGame is not defined”. Make it pass by adding a factory to generate a BowlingGame object:

Then create a spec to excercise the game logic. The simplest game a player can roll is all gutterballs:

And this fails with “TypeError: game.roll is not a function”. So define the methods under test on the BowlingGame lib:

And the spec passes. The next simplest game is one where the player rolls all 1s.

In this iteration I extracted the “player rolls” part of the describe blocks into a shared describe block. The output still has “player rolls” in it. I also pulled the for loop into the “roll_a” helper located in the spec.helper.js file. This file gets loaded before any of the specs run.

Now make the spec pass:

So far the design is simple. There is an accumulator variable that gets incremented by the number of pins felled for a roll.

The next case to test is when the player rolls a spare:

This fails with the message “expected 15 to eql 18”. Now the design needs to change. In order to detect that the player rolled a spare, the code needs to be able to look forward and backward in the history of rolls.

This design changes satisfies the previous specs, but it doesn’t satisfy the case that exercises a spare. It needs further refinement.

In this iteration, the score is calculated by frame (like any good bowling game should). This allows for the game to detect if the player has rolled a spare. It can also look ahead to calculate the bonus for the spare.

Now to test for a strike:

And it fails with ‘expected NaN to eql 28’. There’s an indexing error. And the fix:

Success! Now for the grand finale, the perfect game:

Our game logic satisfies this case. We’ve made some manly code! Even if JSpec isn’t a good fit for you, at least give some form of TDD a try. The final code for this exercise is available on my github account.