Archive for the ‘Technical’ Category

Finger Tied: A History

Yesterday I released a big update to Finger Tied (get it on the App Store) which enables the sharing of levels in the game. You can now share the levels you create, and download levels created by other players. I think it’s pretty cool, and I hope the players do too.

As I was working on the update, I started thinking back on the process of creating the game from start to finish. I like it when other people talk, in detail, about the process of creating their games, so I thought I’d do something to share the process of making Finger Tied. I wished I’d kept a diary or journal about the development of the game, but then I realized that I had the next best thing: my commit logs from my Git repo for the game. Every time I check in code or art, I add comments about what I accomplished.

With that in mind, I exported the logs and wrote a little PHP script to generate HTML code of all the commit comments. I’ve also gone back through my screenshots and pulled some that are relevant to given dates. I haven’t edited any of this, so you’ll see references to features that don’t appear in the finished game, because I decided to cut them.

The first commit comments are from Guelph Game Jam 3, in April, where I first prototyped the game. It was a game about planting flowers, called Trillium Fillium. From there you can see it involve into something more abstract and into the final game.

This post is long. I wouldn’t blame you if you don’t read it. I hope one or two of you find it interesting. 😉

Finger Tied: From Start to v1.1

Wed Apr 11

  • Adding cc2d files. Adding shell project for GuelphJam3.

Sun Apr 15

  • Background renders.
  • Drawing dirt.
  • Adding some flowers
  • Starting condition.
  • You can draw flowers.
  • Lose condition
  • art & sounds
  • Broken attempt at 2 touches
  • Multitouch mostly works. There’s some buggy behaviour, but it’s somewhat playable.

Original Prototype created for Guelph Game Jam 3 (Apr 15, 2012).

Fri Apr 27

  • New artwork. Removing 2nd touch for now for testing in sim.

Mon Apr 30

  • New artwork, start of json data implementation.
  • Passing level data through to the game scene, but not using it yet.
  • Added triply animation to the stripes…not sure if it’ll stay or not…
  • Experimenting with changing the speed of the frame animations on the fly.
  • Crazy colour anim experiment.
  • Fixing size values used for the experimentatl animations

Tue May 1

  • Tying the animations to the percentage complete. Tying the colour animations to the colours of the touches.
  • Doing a bit of refactoring to set up for tracking touch history.

Wed May 2

  • Limiting how much of the screen fills with colour.
  • Committing for posterity: Trying out a moving stripes colour animation. WAY too distracting.
  • Loading all the level data from the json file and using it to build the starting conditions for the level.
  • Tying touch index to the start point index, instead of the order you touched the screen.
  • Fixing a lot of problems with the multi-touch handling logic.
  • Adding a separated level. Fixing some of the math that a split level exposed.

Fri May 4

  • Properly handling highlight state updating.
  • Fixing bugs in multi-touch
  • Fixing ending the level if you work yourself into a corner.
  • Fixing starting presses logic.
  • More multitouch fixes.
  • More multitouch fixes. Multitouch *seems* to be working like I expect it to now? Hopefully…
  • Added a four touch level. It’s showing some weird behaviour starting the level, though…
  • Fixing a bug where all starting fingers needed to happen without any movement.
  • Added spin animation to show history.

Sat May 5

  • Splitting the game scene up into play/edit classes in prep for an editor.

Mon May 7

  • Getting the main editor UI flow working.
  • Adding start highlight markers so you can see which fingers are active on start.
  • Adding easing equations to the animations for little tweaks.
  • Refactoring some code, and fixing a bug that would allow multiple touches to start in the same tile in editor mode.
  • Improving the editor start touch stuff. Fixing some bugs in the multi-touch stuff in the editor start stuff.
  • You can now draw your areas in editor mode.
  • Handling end tiles in editor.
  • Unhighlighting in editor after done editing.
  • Starting to work on generating level data from the editor.
  • Fixing a bug where you could take your finger off the ipad once you had no more options to move without ending the level.
  • Working on more level data output.
  • Start/end points exporting.
  • Writing the tile histories to the json data.

Tue May 8

  • Fixing a bug where you could move your finger around (without lifting it) once you’d backed yourself into a corner with one finger. Now you can’t.
  • Adding some rough sfx for select/cancel.
  • Starting to rough out the UI flow.
  • Colour theme support/implementation added.
  • Changing the history animation so that it only starts once the whole previous anim has finished.
  • Adding some transitions to the FE screens.

Wed May 9

  • New buttons in the play menu, and pagination now. Yay!
  • Copying the play menu code into the level editor menu.
  • Adding ability to delete levels created with the editor.

Sun May 27

  • UI mockups file.

Wed May 30

  • Lots of UI mockups and colour changes.
  • UI mockups and font projects.
  • Starting to work on the new front end. NOTE: You CAN NOT launch the game in this build. I removed some art from the texture atlases, so we get crashes going into the sub-menus for now.
UI Mockups:


Fri Jun 1

  • Playing around with a texture applied to the game in the UI mockups.
  • Solid implementation of the square button.
  • fonts galore!
  • Setting the clear colour to magenta to make it obvious where I’m not drawing.
  • Making the BM font label pay attention to padding values.
  • Default colours.
  • Adding fonts to project file.
  • Main menu buttons hooked up. New fonts in.
  • Some quick fixes to stop the missing art crashes in the play/editor menus.

Mon Jun 4

  • Switching the FE implementation around so that screens aren’t scenes, they’re nodes. WARNING: This build crashes if you go passed the Main Menu then try to get back to it.
  • Font padding tweaks.
  • Playing with a “stamped ink” effect over the screen.
  • Screenshots.
  • Converting all the remaining screens to the new class format to get rid of the crashes. Also handling the colour changes better.

The style of the game is starting to come together.

Tue Jun 5

  • Refactoring FE “scenes” to “screens”. Setting up zOrder on tiles so that they mask the FE contents. Reworking the Main Menu squares to centre anchors so they can be scaled for intro animation nicely.
  • Main menu intro animation, but also broke screen-to-screen transitions somehow…
  • tweaking spacing on sd-font
  • Fix for broken MM buttons
  • MM outro anim (for now). Also put in temp code for other screens to handle exit properly now that the hack code isn’t in the base class.
  • Tweaking MM anims
  • Play menu. Setting it up for the 4 finger buttons. Just animating them in and out right now. Set up a back button for all screens, managed by the FrontEndScene.

Wed Jun 6

  • Switched MM animations to move-based instead of scale-based
  • Disabling input during screen transitions. Disabling multitouch in the FE.
  • Adding text and finger icons to the play menu buttons
  • Changing the back button’s highlight colour when the theme is changed.
  • Hooking the play menu up to load the level select screen and pass a variable that tells it which file it should load (not used yet).
  • Changing the squarebutton to use standard touch delegate instead of targetted, so that I can get it to play nice with the scroll node. Starting the scroll node implementation.
  • More work on the scroll node.

Thu Jun 7

  • Non-dragging scroll works.
  • End bounce working.
  • Cancelling input to children of a scroll node once movement starts.
  • Fixing the case where the innersize was smaller than the viewsize. It was causing weird bounce behaviour.
  • Fixing gaps between scroll view elements by setting “Extrude” to 1 in TexturePacker. Setting 2D projection.
  • Better spacing on the 40pt font
  • Working on the level select screen.
  • Hooking the level select buttons up to the game to launch the appropriate level. Fixing a crash that resulted.
  • Font spacing
  • Adding more things to the level select buttons.

Fri Jun 8

  • New editor UI screens implemented. Main FE flows now working.
  • Lots of new colour schemes, mockups, things tried, fonts. Progress with visual style!
  • Tweaking position of screen titles for new font.

Main Menu design is largely what shipped, though obviously with different colours.

Tue Jun 12

  • ASL fonts and new UI designs.
  • Adding ASL letters to MM
  • Swapping finger icons on Play Menu for new ASL font.
  • New ASL font and layout in Level Select screen.
  • Playing with title text colours…
  • Applying text colour to a few labels in the level select screen that were missing it.
  • Adding a whole bunch of new colour themes.

New colour palette is in the game.

Wed Jun 13

  • Splitting levels into their respective json files based on num fingers used. Adding a bunch of new levels.
  • Create now launches straight into the level editor. Adding a “My Levels” button to the Play Menu. New animations for the Play Menu. Quitting to appropriate FE screen from inside the game now.
  • saving some level editor json files.
  • Fixing bug in level select where extra row of space would show up in scroll view when even number of levels present.
  • Bug fix: colour animation was kicking in full-blast if you sat at 25% completion
  • Bug fix: you could move a finger onto an end point that wasn’t appropriate for that finger
  • Adding a one-tile buffer around the play area for the “audience” animations
  • Bug fix: resetting tiles to the background colour (instead of white) when stopping the colour anim. Also tweaking the math that calculates how much of the screen to use for the anim to take into account the new buffer around the play area.
  • bug fix: flicker on startup. failure animation (breaking glass) added. added a buffer to touches so the game feels a bit more forgiving.
  • Failure anim only plays on tiles playing colour anims.

Fri Jun 15

  • New start/end point art
  • Switching the start/end icons. Playing with the colour/lines animations to make them come in sooner, appear right away as the user completes the level. This makes the tiles dropping off feel a lot cooler.
  • Save implemented for percent complete progress on both built-in levels and created levels. Also painting the preview using the background colour.

Tue Jun 19

  • Hooking up the Testflight SDK and adding some checkpoints.
  • Adding a few more one-finger levels
  • Tuning FE animations.

Wed Jun 20

  • Adding in scroll-to animation functionality to the scrollnode class.
  • Limiting the level creation area to a 12×12 centred grid. This gives room for UI elements that are guaranteed not to overlap gameplay area.
  • Colour palette inspiration from wes anderson movies
  • Creating new button class. Replacing the back btns with the new btn class to make sure it works.
  • Converting the custom buttons to use selectors instead of delegates. Changing all relevant code. Added a temp “back” button to the game that returns you to the FE immediately. This will become the pause button.
  • Removing several unneeded source files.
  • Starting work on the pause screen class. Cleaning up a bunch of compile errors.

Thu Jun 21

  • Removing the stars hand and percentage complete when user hasn’t completed the level.
  • New pause button art. New art and positioning code for the stars on the level select screen.
  • Functional pause menu. Needs some new fonts. Needs intro/outro animations.
  • Pause menu for main game play complete?

Fri Jun 22

  • WIP: Batching tile draw calls. NOTE: FE is currently broken as the background tiles render in front of the FE buttons.
  • Changing the tile default bg to be the on-square with a colour tint as a lighter version of the bg colour. This looks really nice when the tiles fall away on failure.
  • Fixing the FE drawing by splitting the tiles in the bg out into a separate batch node.
  • Adding classes for the other soon-to-be in-game menus. Hooked the existing pause menu up in the editor scene.
  • Building new post-level-play menus. Buttons all quit for now.
  • Level retry implemented.
  • Fixing a couple of compiler warnings causes by method name changes.
  • Implementation for the post-edit menu.
  • Adding a new, really hard, 3-finger level.

Wed Jul 4

  • New created levels.

Mon Jul 16

  • Most of the failure cases are displaying the fail point (except back-tracking). Build Target renamed to “FingerTied”. Game display name now “Finger Tied”.
  • Handling showing the failure marker for backing up over a tile already added to the path.
  • Adding an animation to the failure point sprite.
  • Splitting fail point sprite into two sprites, that can be colour tinted…though not sure how to get the colours to them properly, yet…

Tue Jul 17

  • Tinting the fail point to be in the same colour family as the touch that caused the failure. Doing conversion to HSL so I can adjust the brightness.
  • Saving a few new created levels.
  • Reskinned the editor “how many fingers” menu.
  • Starting working on the tutorial.

Wed Jul 18

  • Lots of work on tutorial system. You can launch it now and run through the tutorials. A bunch of bugs to do with retry levels, or actually finishing the tutorial, though.
  • Fixing some colours in the tutorial post screen.

Fri Jul 20

  • Checking in progress on the tutorial, but I’m about to rip it out.
  • Removing all tutorial code.
  • Pulsing all the starting points to make it more obvious that you have to touch them. To do this meant switching the main game atlas to an anti-aliased texture…no side-effects so far…
  • Tweaking start tile pulse anim time. Adding a pulse to the end points once all start points are activated.
  • Displaying a reason message for failure and reworking the success message for when I have timing working.
  • Implementing the “next” button on post-game screens.

Mon Jul 23

  • Removing “next” from the play fail screen. Timing levels and displaying the time in the success screen. Times are not saved yet.
  • Tutorial levels json file. New screenshot.
  • Saving and retrieving per-level best scores.
  • Changing time format strings. Displaying total time for a level pack if the whole pack of levels is completed.
  • Fixing some labels that weren’t using the same naming convetion as other places.
  • Adding the tutorial levels to the start of the various level packs.
  • Saving the scores for the user created levels properly by adding a -1 score when the level is created to the NSUserDefaults.
  • Bug fix: levels with start/end point on the same tile would show the failure marker even though level had been properly completed.
  • Hiding pause button when pause/postgame menus are up.
  • Adding a whole bunch of created levels to the appropriate level packs. These are NOT in any particular order yet.
  • Fixing missing comma in one of the level files.

Post Game screen. It’s becoming clear that lanscape orientation is becoming problematic.

Tue Jul 24

  • Bug fix: changing colour theme would reset all the tiles in the FE so the black background would disappear.
  • Fixing font spacing for non-retina chunk 18pt.
  • Disabling the fps counter.
  • Adding temp app icon so testers have something to see at least.
  • Better testflight beta tracking points. Anonymizing TF tracking data.
  • Reordered all level packs based on some difficulty testing play-throughs.

Wed Jul 25

  • Various project/code changes readying the first tester build.
  • Making the available tiles highlight significantly more subtle, as it was confusing some testers.
  • Trying a new version of the play menu that shows two hands instead of single hands for multi-finger level packs.
  • Working on a popup message for multitasking gestures warning. Works when returning to gameplay, but not if the game is quit while it’s in the background…
  • Multitasking Gesture warning is implemented. It gets stored that a gesture was made and displays a message next time a 4-finger level is launched.

Fri Jul 27

  • Adding random tips to the menus.
  • Increasing the fudge factor by a few pixels to make it a bit easier to larger fingered players.
  • Wasn’t comfortable with how much I increased the fudge factor. Slight decrease.
  • Applying a fade to the non-active start/end pieces. So end pieces start faded, then start pieces fade out once all active.
  • Removing testflight SDK, adding Flurry for beta testing analytics.
  • Tweaking some tips wording.
  • Post-level screenshots for doing mockups.
  • Conversion to Portrait mode, step 1: Front End
  • Portrait step 2: post-level screen and pause button.
  • Portrait step 3: level editor.

Game has been reworked to render in portrait orientation, making everything better.

Mon Jul 30

  • Better flurry event names.
  • Adding first pass at music loop to the game.
  • Disabling the history animation during gameplay and playing it as soon as the user finishes a level instead. Several testers mentioned the animation was confusing/distracting during gameplay. This feels much nicer.
  • Applying the stripe animation to all FE tiles.
  • Adding some interactivity on the menus. Touching the background tiles plays a one-time colour tint animation.
  • Attempt at new finger icons for the play menu, but I don’t like them. Checking them in, but will be removing them.
  • Reverting to the ASL letters on the Play Menu screen.
  • Fixing an animation in the Main Menu. One of the squares was sliding in slightly faster than an adjacent square.
  • You can set mandatory and directional tiles and they render properly. There’s no UI and the values aren’t stored yet, but you can draw them.
  • New music loop from the composer. No sax.
  • Bunch of artwork that needed adding.

Tue Jul 31

  • Created new flurry api key.
  • Special tiles can be saved and loaded from json data.
  • Making the square button class toggle-able.
  • Adding top menu for the post edit screen that has buttons for directionality and mandatory tiles. Buttons do nothing yet.
  • Exposing whether the square button is on/not on as a property. Allowing other code to set the state of a square button.
  • Post edit UI hooked up and functional. Allows full creation of levels with special tiles.
  • Gameplay now has rules for special tiles. However, failure reasons not implemented yet.
  • Adding all the logic to detect new failure reasons: diagonals, directionals, mandatory colours, slipped end points, and a catch-all. Adding help text to the failure screen for the new cases.
  • Bug fix: post editor screen wasn’t dismissing properly when Erasing or Quitting

Wed Aug 1

  • Removing the upside down screen title text (doesn’t work in portrait) and moving the tip text up into its place. Shortening the tip text (and adding some new tips) so that they fit into the new space next to the back button.
  • Tweaking the sizes of the mandatory square markers. MUCH nicer now that they all feel the same size.
  • Removing unused iPhone icon sizes.
  • Adding some temp code to kill any level progress save data for this version because the level ordering will change.
  • Fixing button order dismiss for fail screen.
  • Upping version number to 0.2
  • Not sure what’s changed in this PSD, but checking it in.
  • Adding new levels with special tiles to the level sets.
  • I had broken the FE when switching colour themes during the switch to portrait. Fixing.
  • v0.2 build sent to Testflight.

Fri Aug 31

  • Latest music loop. GameCenter implementation (no icon in main menu yet).
  • Latest adhoc build.
  • Game Center leaderboard icon art.
  • Custom game center icon added to the main menu.
  • Disabling the GC icon on the MM when the player isn’t authenticated. Also, setting up a notification to the MM to let it know when the state has changed, so that it can enable/disable based on the async event.

Tue Sep 4

  • Adding the “More Games” popup.
  • Replaced the AAC music loop with an AAC-compressed CAF file. This eliminates the stutter when looping.
  • Build the UI for the Options screen. Still needs to be connected to things…
  • Hooking up a few of the options menu items.

Thu Sep 6

  • Adding icons for the music/sfx controls in the options menu. Properly updating them based on state. Initializing music/sfx on launch based on saved states.
  • Uncompressed WAVs for the various versions of the music loops.
  • Credits screen implementation. Needs final credits list.
  • Adding particle effect on level completion. Needs tweaking, but looks pretty good so far.

Fri Sep 7

  • Finished tweaking the level complete particle system.
  • Various screenshots.
  • Improving the “fail” icon animation. Is much more obvious now, which should help people recognize a fail state has occurred when playing.
  • First pass at a “select” found effect. Still a bit too loud, but a good start.
  • Tweaked volume on the select sfx. Added new “back” sfx. Changed the button class to expose the sound it plays on trigger.
  • First attempt as lose SFX.
  • Fixing bug where launching in upsidedown portrait didn’t launch in proper orientation. Upping version to 0.3
  • Changes to credits.
  • Fixing bug where returning to game from multitasking to a FE screen outside the MM caused a crash because it wasn’t cleaning up its NSNotificationCenter registration.
  • Some new screenshots.

Mon Sep 10

  • Bug fix: leaving a directional from the wrong edge generated an “incomplete” fail state instead of a “directional” fail state.
  • Bug fix: if finger 1 is stationary and finger 2 boxes finger 1 in, the game didn’t end.
  • Final music track!
  • First pass at COMPLETE LEVEL REORGANISATION. UI still needs work, and level progression needs extensive play testing.

Tue Sep 11

  • Adding additional “trumpet” particle systems to the sides of the screen. Had to convert blend mode back to additive after discovering I was using an invalid blend fun parameter in previous blend.
  • Only playing the new side-of-screen fanfare particles if you set a new record on a level. Otherwise you just get the end points bursts.
  • Bug fix: Game would slow down significantly the longer you played it. Discovered the post-puzzle screens weren’t being cleaned up, so were still be rendered and reallocated every time you finished a puzzle. Eventually caused massive slow down. Now being cleaned up properly.
  • Improved the handling of mandatory and directional tiles. These could produce “blocked” fail messages, which were confusing. Now lets the user move incorrectly onto them first so that they get a more useful fail message.
  • Starting to reorg the layout of the level select buttons.
  • Finished new layout for the level select screen.
  • Two-pixel tweak the positioning of text on the level select screen.

Final layout of the Level Select menus.

Wed Sep 12

  • New stars art. Positioning stars. NOTE: this build displays random stars for every level, just for positioning testing.
  • Only displaying stars in the level select screen if you’ve completed a level, and displaying the correct star based on the par times.
  • Par times for beginner levels
  • Displaying target times on post-level success screen.
  • Adding animated star awarded for your current time. Fixing case where 3rd significant digit would prevent you from winning a star.
  • Par times for easy levels.

Thu Sep 13

  • Only showing the goal stars above what you just earned. So you just got silver, it only shows you the gold target time.
  • Post game screenshot.

Fri Sep 14

  • Adding the star target times to the play fail screen.
  • Making the centre of the screen tappable to restart on fail. Has a 0.5s delay before activating to try to prevent mistaken triggering at the end of a level.
  • Allowing user music to play instead of game’s music.
  • Par times for Medium and Hard. Rearranged a couple of levels.
  • Bug fix: double play music on startup.

Mon Sep 17

  • Returning the play menu screen to use single-handed icons for different difficulty packs.
  • Adding trash can buttons to the level select screen when viewing your created levels (but they don’t actually delete yet).
  • Converting the SquareButton to use either standard or targeted touch. Adding new input blocker class. Adding popup for delete confirmation to the level select screen. Delete still not actually being done.
  • Actually deleting levels and their associated save data!
  • Touching up the font bitmaps: fixing holes and funny spikes.
  • Updating music/sound credit.
  • New launch screen.

Tue Sep 18

  • Locking level sets until prev set has 10 levels completed. Added lock icons and lock explanation text that fades in when a locked button is pressed. Reworded the “incomplete” text to show how many levels have been completed.
  • Adding a compile-time cheat to allow me to unlock all the level packs.
  • Displaying stars for each level pack on the Play menu. Displays the star for the lowest star level you’ve got across all the levels in the pack.
  • New tips.

Fri Sep 21

  • LOTS of work on the icon.
  • Lots of new icon art, including final icon designs!
  • Copying final icons into the project.
  • Adding first pass at SFX files. Adding in hookups for the FE sounds.
  • In-game sound hookups for first pass SFX.

Sat Sep 22

  • Applying a tiny random pitch to the soundOn SFX so that they give a bunch of really subtle variation in the sound.

Mon Sep 24

  • Adding promo popup code in case I ever need it.
  • Some screenshots
  • New SFX files.

Tue Sep 25

  • Bug fix: side particle effects systems were not cleaning up on restart. Resulted in big slow downs on iPad 1 after playing many levels.
  • Adding SFX hooks to the editor for edit start and end.
  • Some new raw level files.
  • Tweaked SFX files.
  • Icon design progression image.
  • Final raw SFX from audio guy.
  • Increasing default capacity of sprite batch nodes since they were overfilled every time, which caused a realloc.
  • Adding in final levels and doing some removal and rearranging for difficulty tuning. No par times for new levels yet.
  • Created levels.
  • Tweaking the character padding on the 18pt font for non-retina iPads, as it was rendering too wide in the UI.
  • Fixing some buggy behaviour in the scroll node. Touching it wasn’t stopping an scroll in progress. And performance dips on 1st gen iPad would cause really messed up behaviour because of where the dt was being used.

Evolution of the icon design.

Fri Sep 28

  • Made the silver/gold targets for beginner levels easier to achieve.
  • Fixing float rounding display bug on the play success screen and level select menu.
  • Tuning target times for all easy levels.
  • Tuned the Medium difficulty target times.
  • Replaced accidental dupe level. Tuned target times on Hard up to level 28.
  • Finishing the tuning of the hard level target times.
  • Tweaking the ‘tap to retry’ time on the fail screen. Needed to be slightly shorter delay.
  • Bug fix: Disabling input to the game when the pause menu is up. Also disabling the pause button while fingers are playing a puzzle.
  • Bug fix: play menu lock text was displaying incorrect instructions (wrong level pack name displayed)
  • Upping project to v1.0 in preparation for submission.
  • Upping reset value to 1.0 so it resets beta testers’ builds because all levels were reordered.
  • Rewording some tips text.
  • More levels exported from ipad.
  • xcode scheme file changed?
  • Release Candidate ad hoc IPA.
  • Thanks sections added to Credits screen.

Sat Sep 29

  • Adding help message for players to the My Levels screen if they haven’t created any levels yet.
  • Removing a bunch of unnecessary flurry events.
  • Repositioning the multitouch gesture popup for portrait layout.
  • Pointing the twitter button to the new @FingerTiedGame account.
  • First draft of app store description.

Sun Sep 30

  • App store screenshots.
  • Updated description and keywords.
  • Screenshots PSD file.

Tue Oct 9

  • FT description updates.
  • PressKit WIP
Thu Oct 18
  • Launch Day!

Fri Oct 19

  • Displaying Multitasking Gestures popup *as soon* as a gesture is detected, instead of on next launch. Should help with people getting confused.
  • Sound files show as modified, but not sure why. They appear to be correct, so maybe I forgot to check them in?
  • Lots of finger tied ads and screenshots.
  • A whole whack of screenshots.
  • Archived builds.
  • Latest changes to the FT app description.

Wed Oct 24

  • Added Parse framework and started working on level sharing. Realized how huge this is going to be. Going to set this aside for now and come back to it later.
  • FT description changes.
  • Created an iPhone target. Builds and deploys, ready to start work on iPhone version.

Fri Oct 26

  • Main menu converted. Loading iPhone textures. I think I found a good size for the tiles, but it’s hard to tell yet.
  • Rough pass at Play menu for iphone. Functional, but not pretty.
  • Level select screen working on iPhone. Editor basic functionality working (but not UI)
  • Working on the editor post edit screen for iPhone.

Mon Oct 29

  • Editor post screen layout works, but still needs tweaking.
  • Better layout on the editor post screen.
  • Pause menu updated for iPhone
  • Play fail screen for iPhone.
  • Success screen for iPhone

Tue Oct 30

  • Centering the completion time lbl on success screen when no star to render (iPhone)
  • Duplicating the levels json files and splitting them into iPhone/iPad folders. And apparently I forgot to
  • Options screen for iPhone
  • Credits screen for iphone.
  • TexturePacker 3.0 file for the game atlas.
  • Better layout for play menu screen (iphone) and intro/outro anims
  • Splitting tips into iPad/iPhone. Customizing iPhone tips. Reducing tip display time from 10 to 7s.
  • Some first iPhone level designs.
  • Adding button for 4 fingers in the editor for iPhone.
  • More iPhone levels.

Wed Oct 31

  • Temporarily putting all created levels into Beginner so I can send an iPhone build to testers.
  • Fixing the More Game popup for iPhone.
  • Changes to prep a test build for iPhone.

Fri Nov 2

  • scheme files.
  • Some debug code that forces the iPad build to run at iPad Mini size. Committing inactive.
  • Fixing a few UI glitches introduced to iPad code during iPhone porting.

Tue Nov 6

  • Adding “more levels” button to the main menu.
  • Stubbed out the more level screen.

Fri Nov 9

  • Working on level sharing stuff. Built a popup widget I can use for general popup messages now. Converted the level select screen to use the new popup. Adding Parse code back in.

Tue Nov 20

  • GC sign in popup when trying to share a level if not signed in.
  • A whole whack of Finger Tied related files. Not sure why some are marked as modified, but checking ’em in.
  • Uploading levels and tying them to a player object works. Tracks which levels have been uploaded. Does not handle the errors well yet.
  • Starting to work on loading “more levels” data from parse server.

Mon Nov 26

  • More Levels screen properly loading/closing without generating extra buttons.
  • Added buttons for filtering results with stubbed out calls.
  • Implemented 3 of the 4 queries we want for filtering. Search needs more UI. No caching yet.

Wed Nov 28

  • Displaying search UI in more levels. Non-functional yet. Textfield needs property tweaking too.
  • Properly positioned/sized search field. Not doing proper attributes yet.
  • Proper text field attribute settings.
  • Two search fields now. Search works.
  • Caching the queries. Handling network failures nicely. Canceling queries when moving between filters.
  • Adding a constant upward counter for created levels. Renaming levels player has already created to conform to the new system on first boot after update. Adding proper level naming to editor code.
  • Killing active queries when leaving the more levels screen.

Fri Nov 30

  • Built the popup menu for settings on the My Level screen. Upload/delete now done via this popup.
  • Bringing up a popup when a level is selected in the More Levels screen. Buttons just call callbacks, but don’t do anything yet.
  • Fixing a bug where the game became unresponsive if you closed the keyboard from the search page and attempted to back out of the screen. Also added some text to the screen in cases where no results are returned from the server.
  • Likes and Reports working. Game auto-ignores any levels with 3 or more reports.
  • Implementing the download button in the More Levels screen. Though you can’t actually view the levels anywhere.

Sat Dec 1

  • Adding a downloads screen, and a button to the play menu. Seems to be a crash trying to save best time on downloaded level. May be bad data in the NSUserDefaults? Need to update the level buttons in More Levels screen to use the new font/level name stuff from Downloads screen.

Sun Dec 2

  • Fixing the crash after completing a downloaded level. Handling deleting best times on downloaded levels properly.
  • Displaying proper levels names for More Levels screen. Displaying # likes on More Levels. Fixing some bugs with incorrect Setttings displays.

Mon Dec 3

  • Implementing pagination of search results.
  • Displaying a “loading” animation when a query is running.
  • Displaying game center message to user when going to “my levels” sub-screen. Shrinking button text on the FEPopup slightly to accomodate slightly longer text.
  • Displaying network errors as popups in More Levels. Fixing a bug where some queries weren’t being cancelled.
  • Fixing a bug in the More Levels where rapid tapping would result in a duplicate copy of the level data.
  • Fixing a bug where tapping the Refresh button when search boxes were showing caused a crash.
  • New settings button art.
  • Implementing deletion of shared levels.
  • Fixing a bunch of potential crashes. Better network error handling and display. Not displaying Like/Report buttons if already liked/reported. Displaying proper level names in popups.
  • Created new art for more levels filter buttons (but they’re not in-game yet). Removing some unused art from the atlas.

Tue Dec 4

  • Added icons to the filter buttons for More Levels screen.
  • Delete/settings popups on My Levels were showing incorrect level name.
  • Adding delete confirmation when deleting uploaded levels. Making popup msg scale to fit text that’s too long. Fixing some calls to open vertical popups that were displaying level name incorrectly.
  • Adding instructional popups on upload/download telling the player where to find the levels.
  • Ordering the user level’s query by creation time so they see their most recent uploads first.
  • Adding a “new” icon to the More Levels button on the main menu that disappears once clicked.
  • Improving the promo system so I can show popups with users with specific builds. Will be used so I can show players who haven’t updated a popup announcing the update.
  • Upping the build version to 1.1.
  • Parse requires iOS 5.0 or higher, so upping the min supported version to 5.0 from 4.3.
  • Adding version (read from info.plist) to the credits. Pointing the twitter button to my own account instead of the FingerTiedGame account.
  • WIP: Level sharing and custom URLs.

Wed Dec 5

  • Handling custom URLs to load into the search page properly.
  • iOS 5 pasteboard sharing.
  • New splash screen.
  • Doing proper copying to pasteboard for iOS5 (previous version wouldn’t copy both text and images).
  • Removing the level id search box. Making the level sharing shorten the fingertied level link with tinyurl. Made it async so it doesn’t hang things.

Fri Dec 7

  • 1.1 build and what’s new notes.

Detecting Multitasking Gestures

Wow, it has been a really long time since I wrote up a technical post here. But I finally had a technical challenge today that felt worth sharing, so here it goes!

As you may know, I’m working on a new game called Finger Tied. The game is a multi-touch puzzle game. Some of the levels require that you drag 4 fingers around on the screen at once. I sent an early build out to a limited set of testers yesterday afternoon and a few reported problems playing the 4-finger levels. This is why: Multitasking Gestures.

A while back Apple added a feature to iOS called Multitasking Gestures. This feature is turned on by default on the iPad, I believe. When it is active, you can use 4- or 5-finger gestures to do things like switch between running apps, close the active app, or bring up the multitasking bar. The problem is, as developers, we have absolutely no control over this. As far as I can tell, we can’t even query the OS to ask it if the feature is turned on, and we certainly can’t temporarily override the behaviour.

So testers were running into problems where they would start to play a level with 4 fingers, and the app would close. Or their iPad would switch to another app, etc. I had seen some other games bring up a message on first launch that say things like:

“Please disable Multitasking Gestures to play this game properly.”

But I don’t like the idea of ruining that initial play experience with a text-heavy popup that might not even be needed. I figured there had to be a way to detect when one of those gestures has happened. I started looking at what events I get in the game just before the gesture is captured at the OS level. It turns out, your app will receive a touches cancelled event when one of these gestures is captured. I realized I could use this in the game.

Here’s some pseudocode that runs inside touchesCancelled:

if (number of touches cancelled >= 4)
    save a BOOL that says a gesture was used

Any time I get 4 or more cancelled touches at the same time, I’ll save out that boolean value to NSUserDefaults. Now, the next time the user launches a level I do this:

gestureUsed = get saved BOOL value
if (gestureUsed && level requires >= 4 fingers)
    display a popup explaining how to turn off Multitasking Gestures
    clear the saved BOOL value from the save file

This means that the user can play through levels that don’t require 4 fingers to play without ever seeing that message. It also means if they never use a multitasking gesture (or have them turned off), they’ll never see the message. It’s only if they use a gesture and then try to play a level that needs 4 fingers that they’ll see it.

I also force the same check on applicationDidBecomeActive so that I catch the cases where the Gesture happened mid-level and the user was dumped out of the game. This means that in the case where the user has Gestures turned on (but doesn’t use them), then tries to play a 4-finger level, if they accidentally trigger a Gesture then return immediately to the game, the game will immediately pop this message up giving them an explanation of what happened.

However, this is not foolproof. Because I want to try to catch as many cases as possible, this code can generate some false positives in the following case:

  1. Player has Gestures enabled
  2. Player enters the game, then uses a Gesture to switch to another app (this will save that a Gesture occurred)
  3. Player returns to the game, realizes their Gestures will interfere with the app
  4. Player quits the game and turns off Gestures in the OS settings
  5. Player reenters the game, plays a 4-finger level
  6. The game will present the Gesture warning dialog

The other false positive that could happen occurs when a player places 4 fingers on the iPad, then drags all 4 fingers off the screen in the same frame of execution. In that case you would also get 4 touches cancelled in one event, but it would be extremely rare.

Update (2012-07-27): As Alex pointed out in the comments, you’ll also get 4 touches cancelled in the case where the user has 4 fingers on the screen then presses the Home button on the iPad. Again, I believe this is a rare enough occurrence that I’m OK with a few potential false-positives in order to catch the real ones.

So, it’s not perfect, but these are cases I can live with.

Finally, since I haven’t ever submitted this code to Apple, I make no guarantees that it will pass review. This is also untested against iOS 6, so it might fail down the road. Use at your own risk. 🙂


Prototyping with Codea

UPDATE: Since writing this, the developers of Codea have released an impressive number of huge updates to Codea. They have implemented many of the features I was hoping for, as well as many others. Go check it out if you’re at all interested.

It’s not very often that I talk about other games or apps on my blog, but I want to make an exception today to talk about a cool iPad app called Codea by developers TwoLivesLeft. This is a new iPad app that lets you write Lua code on your iPad and run it in-app. This means that you can use Codea to write and play game prototypes on your iPad. Say whaaaat?! Yes, on your iPad.

I first started hearing about the app on twitter a little before release, as some friends of mine were beta testing it. When it launched, I decided to check it out, long having wished for some way to write and run code on my iPad. I’ve spent several hours with it, and I’m quite impressed so far.

The first thing you need to know is that this will not let you create incredibly complex stuff. It’s 2D only, and it has a limited set of API calls available. However, what it is, is a fantastic prototyping tool, as long as you don’t mind typing on your iPad. They provide APIs that allow you to handle touches, and even accelerometer input. They also provide some basic vector graphic drawing tools (draw lines, rectangles, and ellipses). They even include Daniel Cook’s open source sprite collections, so that you can do some basic sprite work.

When I started playing around with it, two things annoyed me almost immediately:

  1. There was no font support
  2. There was no way to add my own sprites to the app

However, in reading through the (very active) forums, I discovered a bunch of people sharing code to solve problems. One person wrote a vector-based font rendering class and shared it. I’m now using that and it’s great. Others pointed out that by using tools like iExplorer to access the iPad’s file system, you can dump folders of sprites into the app and have them show up. However, I quickly discovered was that I find myself using vector graphics for eveything instead of sprites. This keeps me focused on working on gameplay prototyping instead of getting bogged down in Photoshop doing pixel pushing to procrastinate. TwoLivesLeft say they’re also working on getting a bunch of this stuff working in future updates, so I can only see it getting better.

However, there are still some things you should be aware of:

  1. Right now there’s no way to get code to/from the app, except via copying/pasting, or using iExplorer
  2. Support for Undo/Redo is pretty limited right now
  3. You can’t (nor will you ever be able to) export a game right from Codea to the App Store
  4. There’s no way to share code/projects with anyone else from within the app

But these are limitations I’m OK with. Having some way to retrieve files and drop new files in from my computer would be pretty great, though. I’m missing not having any kind of source control on my files. 😉

Finally, I thought I’d share a screenshot of the game prototype I’ve been working on in Codea. This is for a word game concept I’ve been playing around with. What you see is about 4 hours of work. I have built a working button class, I can build words out of letter tiles, and the words detect touches.

Codea Prototype

Screenshot of my word game prototype running in Codea

The other cool thing is this is only 4 files of code, each no more than 100 lines of lua. The vector graphics make it very fast to get stuff quickly drawing, and with prototyping, that’s extremely important. And let’s not forget that I can now write code while I’m not at my computer!

So yes, colour me impressed. The app is still a little rough in places, but the developers seem to be actively working on improving it. Even still, at under $10 it’s an amazing prototyping tool to have on my iPad.


* I chose to write this review on my own. I did not receive a review copy from the developer, nor did they request that I write anything. I just think their app is cool. 🙂

Universal OpenGL Apps

I recently took part in the 360iDev Game Jam remotely from home. The game jam is always a lot of fun, even if you can’t get yourself to the 360iDev conference itself (which you should totally do, by the way, if you can. It’s an amazing conference). I created a game in 8 hours which I’m calling “Dirty Diapers”, you can see the details of its creation on the Game Jam site. There’s a video of the game in action at the end of that page.

The game is about keeping a room full of babies happy. Over time, babies become unhappy because they either want to be fed, changed, or rocked. It’s your job to drag an action up from the bottom of the screen to make the baby happy again. As time goes on, they get more unhappy more frequently.

I think it turned out quite well, so I’ve decided to try to get it into the store at some point. Right now I’m extremely busy with some contract work, but I’m trying to find a few hours here and there to finish it up and submit it.

One of things I decided to try with this game was to build it as a universal app (that is, one app that runs on iPhone/iPod touch, and iPad, instead of separate apps for iPhone and iPad). The game is 100% OpenGL on the rendering side, so I needed to figure out how to set up my frame buffers for a universal app. I thought I’d go through that today. (Holy moly, a technical post instead of an indie lifestyle post! Hold on to your hats!)

Project Setup

The first thing you need to do for a universal app is set up your Xcode project so that it knows to build the app as universal. I went to Jeff LaMarche’s excellent blog and followed his instructions to do this part (and read the follow-up post for a few more details).

Once you’ve done that, you should have a project that can at least compile for iPad or iPhone. Good.

Frame Buffer Setup

Now that you’ve got your app building for multiple devices, you’re going to need to do some work to support multiple screen resolutions. As of this writing, there are three different resolutions to worry about:

  • iPad: 1024 x 768
  • iPhone/iPod touch (non-retina display): 320 x 480
  • iPhone/iPod touch (retina display): 640 x 960

However, Apple does some clever stuff to help you with the retina displays. If you query the size of the screen:

CGRect screenFrame = [[UIScreen mainScreen] applicationFrame];

You’ll get 320 x 480 on both retina and non-retina displays. This is because they measure the screen in “points” instead of pixels now. On a retina display, there are 2 pixels for every point. The nice thing is that it lets you treat all iPhone/iPod touch screens the same way, with the same positioning code.

Ok, so we’ve got these different screen sizes, we need to tell OpenGL to create different sized frame buffers. Somewhere in your code you’ve probably got something like this, which creates a render buffer from an EAGLDrawable CAEAGLLayer:

glBindRenderbufferOES(GL_RENDERBUFFER_OES, buffer.m_colorBufferHandle);
[oglContext renderbufferStorage:GL_RENDERBUFFER_OES fromDrawable:drawable];
glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_WIDTH_OES, &buffer.m_width);
glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_HEIGHT_OES, &buffer.m_height);

If you build and run, what you’ll find is that your render buffer will be created with the proper size for iPad and non-retina displays, but you’ll end up with a 320 x 480 render buffer for retina displays (which need 640 x 960), and your retina display game will look awful. This is because the CAEAGLLayer is telling OpenGL that it’s dimensions are 320 x 480 on the retina display.

In order to remedy this, we need to make use of two new UIView properties found in iOS 4.0 and up called: scale and contentScaleFactor.


The new scale property will tell you the amount the point values of the UIView are being scaled. If you’re running on a non-retina display and query a view’s scale, it will be 1.0. If you’re running on an retina display, you’ll find that it’s 2.0. This gives you a way to test which kind of display we’re working with, and we’ll use this later.


The contentScaleFactor is a different beast. This will always be 1.0. However, if you’re running OpenGL in a view on a retina display, you need to set this value to match the scale value of the view. This will tell the CAEAGLLayer to update its dimensions to match the actual pixel size of the screen, allowing you to create an appropriately sized render buffer.

Now, if you’re planning to support iOS versions prior to 4.0, these properties won’t be available, so you need to do runtime checks for them.

This is what I do inside my EAGLView’s -layoutSubviews method to set the contentScaleFactor on the view:

// Set the scale factor to be the same as the main screen
if ([self respondsToSelector: NSSelectorFromString(@"contentScaleFactor")]) {
    [self setContentScaleFactor:[[UIScreen mainScreen] scale]];

Now, when I tell the render buffer to create itself based on the size of the layer, it will create a 640 x 960 render buffer on a retina display, but a 320 x 480 buffer on a non-retina display. Hooray! But, we’re not quite there yet…

Viewport Setup

We’ve got our render buffer set up to create itself at the proper resolution now. It will match the screen dimension and contentScaleFactor of the EAGLView, which is what we want. Now we need to tell OpenGL to create an appropriately sized viewport. This code is for a 2D game, so adjust as necessary for a 3D game.

You’ll need to create a viewport that matches the frame buffer size for the given screen. Something like this:

glViewport(0, 0, buffer.m_width, buffer.m_height);

For a 2D game, you then need to set up an orthogonal projection. There’s a good chance that you have a line in your code somewhere that looks like this:

glOrthof(0.0f, 480.f, 320.f, 0.0f, -1.0f, 1.0f);

Clearly this isn’t going to work. Now, there are two options here for creating the transform:

1) Create the transform based on the UIScreen size

The code for this is simple:

CGRect appFrame = [[UIScreen mainScreen] applicationFrame];
glOrthof(0.0f, appFrame.size.width, appFrame.size.height, 0.0f, -1.0f, 1.0f);

However, let’s look at what this does. On iPad, it creates a 1024 x 768 sized viewport. Great, that’s what we want. On a non-retina display, it creates a 320 x 480 viewport. Also good. But, on a retina display, it also creates a 320 x 480 display. Now, this is OK. The framebuffer is 640 x 960, so the pixels are there. So what does this mean?

The Good

You only need to write two code paths for positioning sprites on the screen: one for iPad, and one for iPhone, and let OpenGL handle matching the render buffer to the viewport appropriately for you. The only caveat here is that you’ll need to manually scale all your sprites’ sizes by 50%. If you do this, you’ll scale them down to the correct point size, and then OpenGL will render them at 100% resolution when it pushes the textures through the render pipeline.

Confused? Think about it this way: you’ve got a view port of 320 x 480 but a render buffer of 640 x 960. Take a sprite that’s 100 pixels x 100 pixels and render it as a 100 x 100 point sprite in the viewport. This is actually 200 x 200 pixels in the render buffer. So in order to render it as 100 x 100 pixels, you need to scale your vertices down by 50% to a 50 x 50 point sprite.

The Bad

You’ll need to write some code into your sprite system (and bitmap font system) to scale things to 50% if you’re on a retina display.

This is the approach I use. At app startup, I get the screen scaling factor, and then use it to scale all my sprites:

if ([[UIScreen mainScreen] respondsToSelector: NSSelectorFromString(@"scale")]) {
    ScreenScaleFactor = [[UIScreen mainScreen] scale];
    InverseScaleFactor = 1.f / ScreenScaleFactor;
2) Create the transform based on the layer size

The alternative is to create a different viewport size based on the actual pixel size of the screen. You can do this by getting the size of your created render buffer. Something like this:

glOrthof(0.0f, frameBuffer.m_width, frameBuffer.m_height, 0.0f, -1.0f, 1.0f);

This will give you a viewport that matches the screen size in pixels, not points.

The Good

The advantage here is that you don’t need to do any sprite scaling. You just render everything at 100%.

The Bad

You’ll need to have three different code paths for sprite positioning, based on the size of the screen, as you’ll now have three different sized viewports to worry about.

Art Work

You’ll probably want to have different sized artwork for non-retina displays than for iPad and retina displays. For Dirty Diapers I’ve got two game texture atlases: one for iPad and retina displays, and one for non-retina displays. The non-retina atlas is identical to the larger one, it’s just scaled down 50% in Photoshop. You could scale your graphics in OpenGL, but it will never look as good. If you’re like me, the imperfections will just drive you nuts.

So I have two texture atlases, but there are 3 possible screen sizes to worry about (see the next section). I do a check like this to determine which texture atlas to load:

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad ||
    ScreenSizeConsts::ScreenScaleFactor > 1.01f)
    // Load texture atlas for iPad/Retina display
    // Load texture atlas for Original iPhone display

If you want to load 3 different textures (iPad, non-retina, retina), you can use the @2x.png file naming convention (depending on how you’re loading your textures) and just check for iPad or not, but now you’re dealing with 3 sets of textures. The choice is yours. If you’re loading textures manually and the @2x trick doesn’t work, you can split things out like this:

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
    // Load texture atlas for iPad display
else if (ScreenSizeConsts::ScreenScaleFactor > 1.01f)
    // Load texture atlas for Retina display
    // Load texture atlas for Original iPhone display

Finally, Positioning

Now you’ve got your different artwork loading, you’ve got your render buffer set up, and your viewport set up. Now you just need to tell your objects to render in different positions, based on the screen. To do this, I set up a bunch of member variables for positioning code (for static items), and then on init, check the device and screen scale factors and adjust them accordingly. This is necessary for 2D art layout, but if you’re working with a viewport into a 3D world, you may not need to do nearly as much work here.

That’s it…

There you go. I hope you were able to follow along and I wasn’t too confusing. If you’ve got better ways of doing any of this, feel free to post suggestions in the comments.


Game Dev: Getting Started

A friend of mine sent me a message on Twitter the other day asking if I had any tips for someone looking to get started in game development. I mentioned this was quite a large question, so I asked him to narrow the scope of his question. He came back with “between idea and prototype.” That seemed like a good subject for a blog post!

So, you’ve got some programming under your belt. Maybe you’ve been building web site back ends, or accounting software, and you’d like to try your hand at games. Where do you start? If you’ve got an idea, how on earth do you approach the process of turning that idea into a prototype?

1. Consider Scope

I’m putting this right up front, because it’s the biggest and one of the most common traps a new developer can fall into: your idea is just too big. It’s very easy to bite off more than you can chew with a game idea. If you’ve never made a game before, don’t try to build a huge RPG in a massive world for your first game; you will almost certainly not finish it. What about something like tic-tac-toe instead? Or your favorite card game? Or a match-3 game (my first game, Dapple, was chosen because it had a very defined scope, and it still took nearly 6 months to make).

To put things into perspective: a triple-A Xbox 360 or PS3 game will have a team of 100-200 people working for 1-3 years on it. If you’re one person expecting to work on a game for six months, you need to make sure you’re working with an idea you can finish. You can’t build Halo by yourself. That’s ok. Pick a game idea you know you can finish; it will be challenging enough.

Also don’t forget that there are lots of parts to making a game that aren’t immediately obvious that you’ll need to build: menus, save systems, high score boards, platform specific requirements, etc, etc, etc. If you think your game is going to take you three months to make, bank on it taking six. So if you only have three months of savings to live off, maybe pick a game idea you think you can complete in a month and a half.

2. Learn About Games

This is a tough one, are you ready? You need to learn more about games. This means, yes, even playing other games for research. It’s a tough job, but someone’s got to do it. Take a look at other games in the genre that you’re targeting. Look at what they do well, and more importantly, what they don’t. What bugs you about the way they implemented things? What stands out as being done well? Are their menus clunky? Do the animations add that extra punch to really augment the gameplay? Does the music help draw you in? Take notes. Remember that you’re playing to learn, not just to have fun.

If you’re coming at this from a background other than game design, you may also need to do some reading. There are lots of great books written on the subject, and more being written every day, as the industry grows. See what expert game designers can teach you about designing games by reading their books.

One of my favourites, which is also a very quick read, is Raph Koster’s “A Theory of Fun for Game Design“. It’s great book to get you started thinking about designing games and what makes games fun. Another book I haven’t read yet, but have heard a lot of great things about, is Jesse Schell’s “The Art of Game Design: A Book of Lenses“. There are many other great ones, I’m sure. The important thing to remember is that making games is a constant learning experience, so get learning!

If you’re already a game developer reading this, what about you? What are you favourite books? What developer forums do you read? What blogs are the most useful?

3. Choose a Prototyping Technology

So you’ve got your idea and you’ve got some ideas about how to make it work as a game. Now you need to choose your technology for implementing a prototype. I gave a talk in April at the amazing 360iDev conference (their fall conference starts today in Austin) on rapid prototyping. One of the things I talked about is that when you’re prototyping, use whatever technology you are most comfortable with. This doesn’t have to be the same technology you’re going to implement the game with. If you’re targeting releasing an iOS game, but you’ve never touched Objective-C, but you’re a Flash wizard, prototype in Flash. If you’re an expert in javascript, prototype in javascript. If you’re not overly comfortable in any technology, prototype with pen and paper! Do whatever you need to do to get a working version of the game as quickly as possible. All the planning in the world won’t tell you whether or not the game is fun. Playing it will tell you that instantly.

If you’re doing iOS development, cocos2D is a fantastic platform with which to do 2D game prototyping. Flash is a great prototyping tool. If you’ve used Unity, I’m told it’s also great for prototyping. If you’ve got your own engine you’ve been building, use that, just be careful not to spend your prototyping time implementing engine features.

4. The 2-Minute Guide to Game Architecture

Ok, so what I’ve talked about is all well and good, but if you’ve never looked at game code before, you may be wondering how on earth a game works. This is obviously a HUGE topic, one that’s covered in immense detail in many books. However, I will attempt to give the extremely high level overview of how a game works. Ahem…wish me luck.

The Game Loop

At the heart of your game is a loop. This loop executes as long as the game is running. In fact, in many games, it’s a while (1) loop. In iOS development, you’ll be working with an event-driven timer instead. However it’s structured, the important thing is that you’ve got a chunk of code that’s going to execute over and over again. This chunk of code makes up one frame of execution. Most games aim for either 30 or 60 fps (frames per second). This means that your game loop needs to execute in less than 1/30 or 1/60 of a second.

At its most basic, your game loop is going to do two things every frame: update and then render.

The Update

This is where your per frame game logic resides. The update will do things like: pump the physics system (if there is one), update all the active animations, handle collision detection, etc. Basically, it updates the state of the game world in 1/30 or 1/60 second intervals. It says, 1/60 second has passed since the last time I was called, what needs to update? Oh, this character animation needs to be updated, these sprite positions needs to change, these two objects collided, etc. At the end of the update function, your game is in a new state and is ready for rendering.

The Render

Now that the world’s state has been updated, it’s time to render everything to the screen. This means going through all the renderable objects in the world and drawing them. If you’re using a graphics engine, then renderable objects (like sprites) may automatically get a draw() call made on them. If you’re using OpenGL or DirectX directly, then this is where you’ll be making calls into the graphics libraries to do the drawing yourself.

Building a rendering engine that runs quickly is an absolutely massive topic. You’ll need to pick up a book or two (and brush up on your 2D and 3D linear algebra, as well as low-level graphics hardware achitecture) if you’re going to roll your own.


But let’s remember, games are interactive media. This means that at some point you need to handle user interaction with the game. This is often event-driven, in that it’s handled outside your main game loop. You’ll get calls into your code saying “this button was pressed” or “the user touched the screen here”. Some more traditional game loops would have input polling before the update was done. Many modern game frameworks (or platform APIs) rely much more heavily on event-driven code. Much more of your game logic will happen in your event handlers.

At any rate, these events are where you’re going to change game state based on what the user is doing. In a board game, the user might click a button to roll the dice, so your button click event handler is where you’ll trigger a dice roll. In a first-person shooter, you’ll be handling analog stick position updates to update the camera orientation and player’s position in the world.

You may also need to respond to system events, like an iPhone going to sleep, or the user alt-tabbing out of your full-screen game.

The Other Stuff

Those are the basics, but there is so much more that goes into a game: audio systems, user interface systems, front end menus, HUDs (heads up displays), physics systems, animation systems, game logic systems, font rendering systems, save game systems, leaderboard systems, achievement systems, and localization systems (to name but a few). But remember, not every game needs all of these things. That’s why it’s important to remember #1 and limit the scope of your first game.

The hardest thing about creating your first game is finishing it.

It will take dedication to work through the bugs and the tedious parts of building a game (yes, there are tedious parts), but in the end, it’s worth it. You’ll have a game that you made ready for the world to play and enjoy. So what are you waiting for? Start learning. Go make a game!