Beyond Mobile Makers @webbcode - Tumblr Blog

Mentoring: Episode 1

It seems kind of ridiculous to me that I'm already mentoring two Mobile Makers students in the May cohort - with one other cohort separating them from my own.

And yet, looking at the challenges they face, I think their nightly challenge last evening would take me about 20 minutes to complete. It took me 4 hours on January 20th, 2014, which was a mere 129 days ago.

It's hard to believe that it's been that long, that I've lived near-exclusively in SpriteKit-land since, that I hadn't touched a storyboard in 4 months until Saturday night, and that, despite the limited API, WebView, or TableView work I've handled in the interim, my estimated speed on that challenge has increased 1200%.

It's also really interesting to realize that that challenge in particular is essentially a tiny baby version of, well, 90% of client app projects. It pulls data down from an API that wasn't built with you in mind, digests and displays it, pushes you to a more detailed view of specific bits you want, and can push to a WebView to display external data. We at Eight Bit have multiple projects right now that do exactly this, only with more screens, more error handling, user accounts, and a lot more design.

In other news, both Eight Bit and Don Bora are up for Moxie Awards this year, so you should go vote for them right now (and again tomorrow, and so on and so forth) at http://moxieawards.builtinchicago.org/vote

Goodness, it's been a while!

It's been long enough since Mobile Makers graduation that I've gotten to watch an entirely new cohort through the 8 week process!

It's a pretty impressive experience from the outside in as well. I almost forgot how fast everything was thrown at us, and I definitely forgot how fast things became easier. This is an awesome industry.

My plan after graduation was a simple one - head down to my parents' condo in Florida, sit on the beach for 10 days, redoing some of the early projects and cleaning up my Github account, and then begin the job search process.

I managed to get 4 days in before starting my new job as part of the amazing team here at Eight Bit Studios. I love this place.

Day 32: Waking up to giant red Xs and graduation.

So one of the things I did last night when Joe was feeding me all of the art was to put everything into image atlases, which are a fancy new SpriteKit thing that optimizes memory and file size by combining all of your images into 2000x2000px sprite sheets.

Somehow, magically, it maintains memory of what's what and how it was originally rotated, and extracts assets as-needed to throw them up on screen, without you needing to change the code at all.

But either something is not working correctly yet, or they don't play nice with Testflight.com (which Apple just bought!), because the testflight version I uploaded at 2am without testing definitely doesn't have anything but giant red Xs in place of all of our art.

Fletcher, Don, Max, Ellen and I spent the better part of 2 hours this morning trying to fix it, before giving up (for now!) and just pulling the art back out of the atlas files (which took approximately 3 seconds).

And then I spent the last 15 minutes before pushing live to the app store swapping out fonts and text colors, and Fletcher built the tutorial and credits screens.

It's a bit of a blur from there. We pushed, we helped other teams, we added birds to the background of the game, we swapped out the play/pause buttons for new things Joe sent, and then recruiters, friends, family, and other developers began to pour in to see our products.

A lot of people had a lot to say, and I was thrilled at the generally positive reaction our game got! It was a risk, because many business folk tend to dismiss games out of hand, regardless of what percent of the app score revenue they're responsible for. And also because their visual appeal is so integral to their success, while more utilitarian applications can slide through with far simpler design. Still, it looks finished, plays well, is fun, and neither too difficult nor too easy.

My favorite conversation though, was Don's dad requesting a copy. I'll make sure Don helps him get one!

Please head over to spritekitchen.com and keep an eye out on the app store for Objective:Seafood - though - who am I kidding, I'll update you here as well.

Thanks everybody for all of your support!

Day 31: Avast ye scabrous bugs!

We came in this morning all with the same realization: our game crashes.

It didn't used to. It used to run flawlessly at 60fps. Now it's at 16.

We enlisted Max's help, enabled zombie objects (because those are a thing), and went into full-on debug and optimization mode.

There were a few culprits. One was a mutable dictionary being referred to as non-mutable, but the main one seemed to be our bloated Update method.

SpriteKit's main game loop calls three methods every frame, which is, optimally, 60 times per second. The first of these is the Update: method, which makes it a convenient place to put any logic that always needs to be checked. But convenient doesn't always mean smart, because our game score or currency isn't changing 60 times per second, it's changing only when specific things happen, such as killing monsters. And upgrades only become available at specific currency amounts, which themselves only occur after killing monsters.

So I was able to move almost 200 lines of code out of the update method, reduce it to 9 lines of code, and put it in the places those conditions really should be checked - the only place in the code that can cause them to be true.

Just like that, we were back to 60fps!

Joe spent 5 hours with us tonight finishing all of the art, and the game is now beautiful. I really can't thank him enough!

Day 30: Have you noticed how out-of-order my posts are yet?

So yesterday (for certain definitions of yesterday), I said three to go. I'm realizing that was pretty incorrect -- we have to be done BY Thursday, not by the end of Thursday, which means this is our second-to-last day to actually work on the project.

SpriteKitchen.com is live - and you can see some more of the concept art for the game on it:

I'm really proud to say that today I re-worked the scene flow of the game, turning the menu into a SKScene instead of a UIViewController, making a skeleton of the tutorial and credits scenes, transitioning to the game scene, which transitions to a new Game Over scene upon completion, which pops open the Game Center Leaderboard, and then transitions back to the main menu. That's not that complicated, really, so why am I proud of it?

I wrote the Game Center leaderboard code first, at 9am, but didn't have the rest of the transitions in and working until mid-afternoon, but Game Center integration worked, successfully, the first time I was able to test it.

Why did it take so long? Surely SKTransitions aren't that complex (they're one line of code)! Sure, but to implement Game Center at all, the program has to be registered on iTunes Connect, which is definitely a needlessly complicated process.

Still, this will give us a heads-up on the other teams when it comes time to push to the store (aaand here's another obvious chronology fail), because all we'll have to do is replace the placeholder screenshots I used and upload a binary.

Joe has started feeding us assets - we now have the captain, his boat, and the kraken! And moving water! I'm excited :)

Objective: Seafood has been pushed to the app store!

After some late nights and hard work, we've finalized the project (for version 1!) and have pushed it to the app store. Look for it soon!

Day 29: Three to go.

We're really close now. I can taste it. We still need a leaderboard, probably need to shift around our game over screen a bit, and have a small number of bugs we need to chase down. But mostly right now, we're waiting on Joe *cough*. Darn, that didn't summon him. Still, we're incredibly grateful for all he has provided to us and totally didn't expect outside graphic support at all, so it's substantially better than having to do it ourselves!

SpriteKitchen.com is registered, and pointing towards another tumblr page that's all set up, but of course the DNS servers take their sweet time to update.

Weekend Seven: Persistence, Waves, Upgrades, Oh my!

We got a lot done this weekend. Our game now saves progress every time you complete a level, so that if you leave and come back, you only have to re-start the current level, rather than the whole game.

This is an intentional choice. We could write some pretty complicated code using NSCoding to save/resume the entire game-state, but to be honest, i've never seen that behavior in a tower defense game. So, to be true to the genre, we're forcing users to re-start the current level.

Fletcher has worked a lot this weekend on getting the upgrade system working, and it's looking great. We will probably have to iterate on the gold generation curve, as the game is really, really hard at the start of wave two until you can upgrade your fireball.

Which of course references the wave structure, which is now working correctly, storing monsters in an array until they're needed and then spawning them.

Day 28: Oh what a difference a week makes!

Today was the second round of showing off our apps and getting to see what the other teams have accomplished, and I have to say, some of these projects look really, really amazing. I have personally downloaded many substantially worse apps from the store. This is awesome.

I am very happy with the progress SpriteKitchen has made over the last two weeks, but we still have a ways to go - persistance, re-playability, tuning game balance, and gameCenter leaderboards are all on the list still.

Let's go code those now!

Day 27: Here there be Dragons: Redux.

But they're adorable and fire-breathy!

And, of course, they're pretty unlikely to make it into the final game.

More likely to make it in, however, are the fireballs, ice-balls, and split-projectile which are now working, complete with different sound-effects and damage numbers!

Day 26: Ridiculously cool concept art.

Today we added in a HUD which displays a health bar, score, and currency, as well as some placeholder buttons that will eventually play/pause the game, turn music on/off, and swap between projectiles.

And Joe revealed some goodies from his sketchbook, one of which is now most definitely our theme. I'll just leave this here:

Day 25: Turn-based schmurn-based.

I'm not so sure that turn-based enemy movement is going to happen. There's a few key issues at play, but the key one is thus: once an enemy is set to move along a path, it's impossible to pause/resume that movement without stopping all other actions/animations from interacting with that enemy's node as well.

Pausing and resuming nodes is actually incredibly simple, as every node has a "paused" boolean property, which does precisely what you'd expect it to. But we are using custom actions for causing enemies to flash red when hit, explode when killed, etc. So pausing them makes these actions either not run, or wait to be ran after we have re-started movement, which is pretty awkward.

And, thinking about it further, we're unconvinced that the turn-based nature would have been more (or less, to be fair) fun than real-time enemy progression. We'll just have to be careful with how we tweak the paths and speeds and spawn-rate so that the player is neither bored nor overwhelmed.

Day 24 / Weekend Six: Slingshot Mechanics

After finally understanding (sort of) Bezier curves and getting the monsters to move along the CGPath we set up, the next task in the logical list is to mimic the angry birds slingshot, where we pull the projectile back and then launch it with a direction and force proportional to the distance and angle between the origin and where the projectile has been dragged to.

Turns out, this isn't as hard as you might think. Before, the code was already creating a line between the origin and where the user tapped, finding that vector, and launching the projectile towards that location, with a static amount of force that we tweaked to achieve the desired arc length. Now, the only real difference is that the vector created is inverted, since we're dragging the projectile backwards, and the force applied is proportional to the length of the line, while still being tweaked to feel right on our screen.

We also began to add new enemy types, and gave different monsters different amounts of health.

Day 23: Bézier Curves, Slingshots, and Parallel lives.

Today Gule and I continued to struggle with the CGPath construction process, and ultimately came to the realization that SpriteKit uses a completely different coordinate plane system than UIKit. In UIKit, 0,0 is the upper left corner of your screen. Adding to the X direction goes right, adding to the Y value goes down. In SpriteKit, 0,0 is the center of the screen, and all four quadrants familiar to us from algebra class are available.

Next, we need to mimic slingshot mechanics, limit enemy movement to be turn-based, add health to both the player and enemies, create multiple varieties of enemies, currency, points, a high-score board, persistence, levels, difficulty settings, upgrades, and multiple projection types. So we're almost done!

Our speaker today was another fine gentleman from Vokal, Sean, who described his previous life, almost exactly like mine, Matt V's, and Fletcher's. I can only hope things work out as well for me as they have for him! Well, that's not the only thing I can do. But hope is among the things I am doing towards achieving that end!

Goodnight, fair readers!

Day 22: CGPaths and Paper Airplanes

With the literally thousands of convenience methods Apple has provided to us within SpriteKit alone, it's really strange to me that there isn't one to create a CGPath from an alpha mask. Gule struggled pretty much all day with creating a path for our monsters to follow, and we re-watched the WWDC videos, which I feel was productive now that we've dabbled a bit with the framework.

So far, the game looks the same as yesterday, but I've added in a new monster/snowman death animation, sound effects, and adorable background music.

Our guest speaker today was Vokal's ScrumMaster, Nick Ross, who explained the basics of Agile development and Scrum in particular, and illustrated the advantage of separating projects out into multiple sprints by giving us 3 rounds of short iterative bursts of time to spend planning, building, and testing paper airplanes. As a group, our first round had both the worst production and the worst test results, and the third round had double the output and 94% of the planes flew at least 10 feet on the first throw.

Some of the core concepts of Agile make a lot of sense to me, and it's weird to think how many corporations still design products and policies without including delegates from each discipline involved in the decision-making processes, or obfuscate the product from the client until launch-time. And by weird I mean terrifying.

After several more hours of code, a bunch of us walked over to the Michigan Ave. Apple Store for the local CocoaHeads meetup, which meets in the not-very-well-kept secret conference room on the 4th floor of the aforementioned Apple Store. We were welcomed with open arms and pretty much everyone familiar with Mobile Makers seemed thrilled by it, which isn't surprising, but is still nice to hear.

The speaker-of-the-night, Vinayak Badrinathan (@VinnyBad), explained all of the magic behind CocoaPods, which really confounded us all when we learned about Parse last Tuesday. I'm realizing now that I left that out of the blog, but here's the entire process for downloading and installing CocoaPods:

Open a terminal window

type "gem install CocoaPods"

What on earth is gem, why did it come pre-installed, and how does it know where to find CocoaPods? I'm glad you asked.

Well, while CocoaPods is the unofficial objective-C dependency management system, gem is the official Ruby dependency management system. Ruby is another popular programming language, and OSX comes with gem pre-installed as a command-line tool. I'm still not really clear on how it finds CocoaPods, but Max says it's pixies, so it must be pixies.

Next, to add a given "Pod" (or multiple pods) to an xcode project, we merely make a text file in a project directory named "Podfile", and put something like "pod Parse" in it, save, and go back to terminal to type, "pods install." More darn pixies, and then the Parse framework is embedded in your workspace file.

Vinny showed us where to look to see all 3800+ pods available, and also explained how some of the magic is done, but who am I to ruin it?

Day 21: Snow and Projectiles!

So our goal going in to the day was to get something to shoot something at something, with the middle something being affected by gravity. Mission accomplished!

We also had an excellent conversation with one of Vokal's designers, who hinted that they might be able to help us out with some basic art assets for the game - which is awesome, because otherwise we're stuck with hilariously bad snowmen stolen from the internet:

I'm quite proud of the snow effect, though!

There's a few bits of code involved that I really don't understand, even after using...I pretty much brute-forced it by tweaking the physics numbers until it worked the way I wanted to, without knowing why it's working that way. Gule tried out some of the Wenderlich spritekit tutorials and really seemed to learn a lot, so I'll try that out before bed.

Day 20 / Weekend Five: Who wants to make a Game?

On Thursday, after discussing the instagram experience and demoing our products, we had a few hours to think about what we'd like to do for our final projects, and then we pitched ideas.

I'd thought about it, and discussed with other members of the cohort, and with friends and family, but didn't have any one particular stand-out concept.

The common failing of app ideas offered to me is that the concept isn't actually about code. Some are business concepts, where the actual service provided is far more vital than the app. Some are a means of presenting interesting or important data, where weeks could be spent on nothing but obtaining said data, only to dump it into a UITableView in the final 20 minutes. Others rely heavily on a backend existing that is not in my control and would be beyond the scope of Parse.

These aren't necessarily bad ideas for production apps, but for the purposes of this course, even with my design background, I have no interest in spending three weeks manipulating images or collecting data. I want to write code.

And there's one genre, which I happen to have an obvious passion for, which is nigh-infinitely expandable with new features, should any piece of coding wind up being easier than we thought: games. Of course, they require some design work too, but less than you'd think. All of the art and sound effects for Super Mario Breakout took me significantly less than an hour (because it was stolen from the internet). For this, that's still the plan, but the goal is to grab assets from free, open-licensed art and music repositories, which will take a little more care.

So, after nearly everyone else had given excellent 10 minute pitches, detailing precisely what their app would accomplish, I stood up and said, "I don't have a clear concept, but I want to go crazy with SpriteKit. Details are up to you; I'd be happy making a platformer, an infinite flyer, a RPG, a tower defense game, an educational game for kids, or an old-school classic game like tetris or galaga. Who wants to play with me?"

And my single-paragraph pitch was highly successful, even catching Ryan Striker's attention, as our unofficial 4th man. I am thrilled to be working with Fletcher and Gule again, and to have worked with nearly every member of this cohort along the way (with the very sad exception of Josef, but pairing the two of us together would perhaps have not been fair to anyone else...he's a pretty incredible developer).

Without putting out too many spoilers, here's the design we landed on:

A single-tower, turn-based hybrid of the tower defense genre with...whatever you'd call Angry Birds. I'll even enable answering for that one. SpriteKit here we come!

Trending Blogs

Recently Viewed Blogs

Beyond Mobile Makers