Cocos2D-x Bootstrapping

This is a brain-dump of my learnings with Cocos2D-x.

I'm using an old 1st Edition copy of Roger Engelbert's Cocos2D-x by Example: Beginners Guide which has several learner projects and resources to download.

The book is obviously a bit out of date with respect to Cocos2D and C++ as well, but the algorithms are sound. Studying the book and updating the ideas to C++17 and Cocos2D-x 4.0 is a interesting learning challenge.



I'm using C++ and Xcode on Mac targeting iOS and Android.

My source code is here in my Github.

Downloads

• Cocos2D-x 4.0
• Programmers doc (bookmark this)
• API doc (bookmark this)
• Download Cocos2D-x (download this)
• for experts: clone the Git repo
• or download a release from GitHub
• CMake 3.16.2
• Install from Kitware or Brew
• I recommend to download the Kitware Mac App
• then add to path as described in this SO post by user "sizzle"
• Dev environment
• Mac OSX 10.15.2 (Catalina)
• Install any updates for the system
• Ensure the Terminal app is in your dock & setup to use
• Android Studio
• Download latest from Google
• Setup as needed
• Note: In the past I used the Android command-line SDK
• It can be downloaded from Google still
• You can use it if certain to never need the IDE
• This is strongly not-recommended 
• Xcode and tools
• Setup of this is beyond the scope of this doc
• Should download latest from the App Store
• Ensure all kits are initialised by:
• File > New > iOS > Game
• Click thru and ensure it builds and runs

Ensure Cocos2D-x is downloaded, but not installed yet.

Get CMake, the dev environment, Android Studio and Xcode all setup and installed.

The commands below use the Terminal - you type what's after the $ - and they assume you have a working Python 2.7 which should be the case for a stock Mac OSX 10.15.x machine.  I use a setup where my build (binary dependencies & downloads) go in to ${HOME}/build and my source code projects are in ${HOME}/depot - use whatever you know & substitute in for what I have.

Then...

Setup Cocos2D-x

• Follow the doc

Assuming the Cocos2D zip file was unzipped into ~/build:

~/build/cocos2dx $ ./setup.py

The above command will detect your Xcode and Android toolchain along with the NDK.  Android and the NDK should have been installed in ~/Library/

After its finished source in the new environment variables the command adds to your profile:

~/build/cocos2dx $ . ~/.bash_profile

Create a new project

From a directory where you normally store projects, eg source code, run the cocos command to generate your new game:

~/depot $ cocos new -p au.com.smithsoft.skydefence -l cpp skydefence

> Copy template into /Users/sez/depot/cocos2dx/skydefence

> Copying Cocos2d-x files...

> Rename project name from 'HelloCpp' to 'skydefence'

> Replace the project name from 'HelloCpp' to 'skydefence'

> Replace the project package name from 'org.cocos2dx.hellocpp' to 'au.com.smithsoft.skydefence'

> Replace the Mac bundle id from 'org.cocos2dx.hellocpp' to 'au.com.smithsoft.skydefence'

> Replace the iOS bundle id from 'org.cocos2dx.hellocpp' to 'au.com.smithsoft.skydefence'

Note that if you've had multiple versions of Cocos2D installed it will be the directory where the cocos command line tool is located that determines which cocos version you use (unless you stipulate otherwise).  If you've run setup.py as above it will have modified your shell for you.

~/depot/cocos2dx $ which cocos

/Users/sez/build/cocos2d-x/tools/cocos2d-console/bin/cocos

Create iOS, Android & Mac

From the project that was created, run the cocos tool which will invoke the Cmake command line to run a generator for Xcode that creates the project files and then builds the project.  Same for Android.

~/depot/cocos2dx $ cd skydefence

~/depot/cocos2dx/skydefence $ cocos compile . -p ios

Building mode: debug

running: 'cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator'

-- PROJECT_NAME:skydefence

-- PROJECT_SOURCE_DIR:/Users/sez/depot/cocos2dx/skydefence

-- COCOS2DX_ROOT_PATH:/Users/sez/depot/cocos2dx/skydefence/cocos2d

-- CMAKE_MODULE_PATH:/Users/sez/depot/cocos2dx/skydefence/cocos2d/cmake/Modules/

-- PROJECT_BINARY_DIR:/Users/sez/depot/cocos2dx/skydefence/ios-build

-- ENGINE_BINARY_PATH:/Users/sez/depot/cocos2dx/skydefence/ios-build/engine

-- PYTHON_PATH:/usr/bin/python2

-- COCOS_COMMAND_PATH:/Users/sez/build/cocos2d-x/tools/cocos2d-console/bin/cocos

-- HOST_SYSTEM:Darwin

-- CMAKE_GENERATOR: Xcode

-- COCOS2DX_LUAJIT_ROOT:/Users/sez/build/cocos2d-x/tools/cocos2d-console/bin/../plugins/plugin_luacompile/bin

-- cocos_mark_code_files: cocos2d

-- cocos_mark_code_files: skydefence

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/sez/depot/cocos2dx/skydefence/ios-build

running: 'cmake --build . --config Debug'

User defaults from command line:

    HideShellScriptEnvironment = YES

...

echo Build\ all\ projects

Build all projects

** BUILD SUCCEEDED **

Build succeed.

• Repeat for Android & Mac

~/depot/cocos2dx/skydefence $ cocos compile . -p mac
...not shown...

~/depot/cocos2dx/skydefence $ cocos compile . -p android

Building mode: debug

Using Android Studio project : /Users/sez/depot/cocos2dx/skydefence/proj.android

Building apk...

running: '"/Users/sez/depot/cocos2dx/skydefence/proj.android/gradlew" --parallel --info assembleDebug -PPROP_BUILD_TYPE=cmake'

Downloading https://services.gradle.org/distributions/gradle-5.1.1-all.zip

........................................................................................................................................................................................................................................................................................................................................................................................................

> Task :skydefence:packageDebug

Task :skydefence:packageDebug in libcocos2dx Starting

Caching disabled for task ':skydefence:packageDebug' because:

  Build cache is disabled

Task ':skydefence:packageDebug' is not up-to-date because:

  No history is available.

All input files are considered out-of-date for incremental task ':skydefence:packageDebug'.

Task :skydefence:packageDebug in libcocos2dx Finished

:skydefence:packageDebug (Thread[Execution worker for ':' Thread 11,5,main]) completed. Took 0.447 secs.

:skydefence:assembleDebug (Thread[Execution worker for ':' Thread 11,5,main]) started.

> Task :skydefence:assembleDebug

Task :skydefence:assembleDebug in libcocos2dx Starting

Skipping task ':skydefence:assembleDebug' as it has no actions.

Task :skydefence:assembleDebug in libcocos2dx Finished

:skydefence:assembleDebug (Thread[Execution worker for ':' Thread 11,5,main]) completed. Took 0.0 secs.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.

Use '--warning-mode all' to show the individual deprecation warnings.

See https://docs.gradle.org/5.4.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 3m 4s

54 actionable tasks: 42 executed, 12 up-to-date

AAPT2 aapt2-3.5.3-5435860-osx Daemon #0: shutdown

AAPT2 aapt2-3.5.3-5435860-osx Daemon #1: shutdown

AAPT2 aapt2-3.5.3-5435860-osx Daemon #2: shutdown

AAPT2 aapt2-3.5.3-5435860-osx Daemon #3: shutdown

AAPT2 aapt2-3.5.3-5435860-osx Daemon #4: shutdown

Move apk to /Users/sez/depot/cocos2dx/skydefence/bin/debug/android

Build succeed.

iOS Device

Building for an iOS actual phone requires a switch to specify the non-emulator (non-x86) SDK:

~/depot/cocos2dx/skydefence $ cocos compile . -p ios -sdk iphoneos

Note that this will overwrite the details in your generated Xcode project in ios-build, so you wind up with a messed up set of libraries and linker errors relating to x86 vs arm for the cocos libraries. I tried using the -o switch to specify a different output directory but this didn't seem to work.

I suggest build for the iPhone if you ever plan to build for a real device (and you should) and then once the iPhone project is running you can start building for an emulator simply by picking an emulator from the device chooser.

Open Project Files in IDE

You should now be able to open the project files in Xcode

~/depot/cocos2dx/skydefence $ open ios-build/skydefence.xcodeproj

Go thru and do the setup you'd do for a normal project, setting your team so that you can build for a real device.  You'll need to add your account info to the Xcode prefs if you haven't done so already. 

Also update the organisation (and if you want class prefix) fields - these control the text that appears in new file copyright headers so its good to do this early.

Fix-ups Required

Update the General tab with a reasonable Target Version for your project.  I usually use about 1 version back from current (today) so for example at present latest is 13.2 so I have 12.2. I found after the cocos tool and CMake ran it was set to 8.0 - this clashes with the Cocos2D-x API's which use calls that are only available in more recent versions of the iOS API's:

 

Problem with missing Info.plist value

I got this error when trying to run the emulator:

Could not install at this time.  Bundle at path <path name> has missing or invalid CFBundleExecutable in its Info.plist.

To fix enter as the name in the Executable File field in the Info tab indicated in the screenshot below:

$(EXECUTABLE_NAME)

Also when trying to run on the device I had a shower of link errors, related to architectures: the compiler was referencing libraries compiled for the iPhone emulator and it turned out to be that a value pathed into the sdk for the emulator was appearing in the Framework search paths.

If you get these errors (likely because of trying to build the emulator first and then for a device) just delete the value so that the Framework path field is blank as below.

Troubleshooting

There's a lot of problems that can occur, but its mostly due to not having all the dependencies up-to-date and properly installed.

iOS Troubles

There's a lot of slight glitches in how CMake as configured by the Cocos2D folks is setting up the iOS project.  I had an issue with running the project where at run time it reported a bad setting in the 

With an issue like:

~/depot/cocos2dx/skydefence $ cocos compile . -p ios

Building mode: debug

running: 'cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator'

-- The C compiler identification is AppleClang 11.0.0.11000033

-- The CXX compiler identification is AppleClang 11.0.0.11000033

System is unknown to cmake, create:

Platform/iOS to use this system, please send your config file to cmake@www.cmake.org so it can be added to cmake

-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang

System is unknown to cmake, create:

Platform/iOS to use this system, please send your config file to cmake@www.cmake.org so it can be added to cmake

-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- broken

CMake Error at /usr/local/Cellar/cmake/3.8.2/share/cmake/Modules/CMakeTestCCompiler.cmake:51 (message):

  The C compiler

  "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: /Users/sez/depot/cocos2dx/skydefence/ios-build/CMakeFiles/CMakeTmp

  

  Run Build Command:"/usr/bin/xcodebuild" "-project"

  "CMAKE_TRY_COMPILE.xcodeproj" "build" "-target" "cmTC_c96ba"

  "-configuration" "Debug"

  note: Using new build system

  note: Planning build

  note: Constructing build description

  error: unable to resolve product type 'com.apple.product-type.tool' for

  platform 'iphonesimulator' (in target 'cmTC_c96ba' from project

  'CMAKE_TRY_COMPILE')

  error: unable to resolve product type 'com.apple.product-type.tool' for

  platform 'iphonesimulator' (in target 'cmTC_c96ba' from project

  'CMAKE_TRY_COMPILE')

  ** BUILD FAILED **

  CMake will not be able to correctly generate this project.

Call Stack (most recent call first):

  CMakeLists.txt:30 (project)

-- Configuring incomplete, errors occurred!

See also "/Users/sez/depot/cocos2dx/skydefence/ios-build/CMakeFiles/CMakeOutput.log".

See also "/Users/sez/depot/cocos2dx/skydefence/ios-build/CMakeFiles/CMakeError.log".

The above is due to CMake not recognising the current version of clang.  Upgrade cmake to the latest version available either via Brew or download from Kitware as above.

Signing not Set Up

If you haven't set up signing in the IDE and run the cocos compile command using the -sdk iphoneos switch you'll get an error like this:

...<other stuff>....

=== BUILD TARGET foobar OF PROJECT foobar WITH CONFIGURATION Debug ===

Check dependencies

Code Signing Error: Signing for "foobar" requires a development team. Select a development team in the Signing & Capabilities editor.

Code Signing Error: Code signing is required for product type 'Application' in SDK 'iOS 13.2'

** BUILD FAILED **

The following build commands failed:

Check dependencies

(1 failure)

Error running command, return code: 65.

Just setup Signing in the IDE as discussed above.

Android Troubleshooting

Android problems mostly relate to not having setup your Android build environment fully.  Ensure you can build a hello world app using Android Studio first, and make sure your Android emulators are also ready.

Make sure that any old Android environment variables are not still in your ~/.bash_profile and that the Cocos2D ./setup.py completed without errors, and found your NDK.

Here not setting up the Android Studio properly - which would have been caught by trying to build a hello world - meant that current SDK licenses hadn't been properly installed:

...

Parsing /Users/sez/android/emulator/package.xml

Parsing /Users/sez/android/lldb/2.3/package.xml

Parsing /Users/sez/android/ndk-bundle/package.xml

Parsing /Users/sez/android/patcher/v4/package.xml

Parsing /Users/sez/android/platform-tools/package.xml

Parsing /Users/sez/android/platforms/android-18/package.xml

Parsing /Users/sez/android/platforms/android-22/package.xml

Parsing /Users/sez/android/system-images/android-22/default/armeabi-v7a/package.xml

Parsing /Users/sez/android/system-images/android-22/default/x86/package.xml

Parsing /Users/sez/android/system-images/android-22/google_apis/armeabi-v7a/package.xml

Parsing /Users/sez/android/system-images/android-22/google_apis/x86/package.xml

Parsing /Users/sez/android/tools/package.xml

Checking the license for package Android SDK Build-Tools 27.0.3 in /Users/sez/android/licenses

Warning: License for package Android SDK Build-Tools 27.0.3 not accepted.

Checking the license for package Android SDK Platform 28 in /Users/sez/android/licenses

Warning: License for package Android SDK Platform 28 not accepted.

FAILURE: Build failed with an exception.

* What went wrong:

A problem occurred configuring project ':libcocos2dx'.

> Failed to install the following Android SDK packages as some licences have not been accepted.

     platforms;android-28 Android SDK Platform 28

     build-tools;27.0.3 Android SDK Build-Tools 27.0.3

  To build this project, accept the SDK license agreements and install the missing components using the Android Studio SDK Manager.

  Alternatively, to transfer the license agreements from one workstation to another, see http://d.android.com/r/studio-ui/export-licenses.html

  

  Using Android SDK: /Users/sez/android

* Try:

Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 28s

Error running command, return code: 1.

Working Around Xcode Server CI Manual profile Issues

There's a few problems and issues to deal with when getting Xcode server to work and they've been mostly dealt with well in other blog posts.

The dreaded error you get with a manually provisioned profile is harder to get rid of:

Provisioning profile "MyApp Development iOS" doesn't include signing certificate "iPhone Developer: OS X Server (VQJ479QQTU)"

It occurs because when the Xcode server runs in the context of the OS X Server it has its own keychain called "Portal" and in that keychain it creates its own new certificates, which are accessible by the server process.

First get your CI server up and running and create a bot as described in the Apple macOS Server documentation for CI services, or a recent blog post.

If you've got a manually provisioned profile you'll get the error above.  Make sure that on your local development machine - e.g. your laptop - open Xcode and use the credentials export feature - it will ask for a password which you'll need to carefully record.

This will create an archive of the credentials including your certificates, keys, profiles and so on.  Copy that onto your macOS Server machine (e.g. using scp or a USB key or whatever) and then as the xcodeserver user that you created for the purpose open Xcode and import that archive, supplying the password created above.

Now open the Keychain Access program - I find its easiest to do this by invoking Spotlight with <cmd>-<space> and then typing "Key...".  Here you need to do the following

• Click on "Portal" top left to open the "Portal" keychain
• Select all the automatically created certificates that are complained of in the error e.g. 
• iPhone Developer: OS X Server (VQJ479QQTU) 
• Set these aside for safe keeping & then delete them.
• Archive these off by choosing "File" > "Export Items...".
• This is in case something goes wrong and you need to re-install them
• Now choose "Edit" > "Delete"
• Now click on "login" to open the "login" keychain.  
• This is where Xcode's import developer accounts tool will have placed the certificates.
• Select all of the certificates and drag them into the "Portal" keychain.
• At the end your "Keychain Access" should look like this:

You should now be able to run an integration and Xcode server will find and use the correct certificates to support your manually assigned profiles.

Burn your GANTT Charts & Deliver Game Releases Like a Boss

We all want to have our teams be treated as the awesome creative people they are, but there's deadlines and as producers & studio founders responsible for making sure the place stays afloat, how can we deliver our games on schedule and not put our peoples feet to the fire?



How about setting fire to your schedule for a damn start?  We all know the dates on those things are a straight-up fiction!  They weren't working anyway right?  The reason they fail is because of the Planning Fallacy - humans are fundamentally incapable of making accurate estimates of work to be done ahead of time.

There's alternative approaches where torching those old traditional MS Project style schedules may well be a good thing, especially if your studio is looking for a clean slate on your team dynamics.  My talk at Seattle's Mobile Game Forum on October 18th 2016 deals with this topic and I'm going to throw a few spoilers here (the image above is a slide from that talk) - but go see the talk if you can, as the full content will be there.

The different way of working is a methodology developed over a decade of working with creative teams.  I use it today at my studio Smithsoft Games.  At its core it's a "kind-of agile" modified for the small, distributed, start-up teams of frequent collaborators which typify my teams.

What works well for my team is ideas that are raided from the agile camp.  

I don't necessarily buy into the whole agile manifesto - because my teams & projects are usually distributed and multi-disciplinary so not always face-to-face.  We respond to players (our customers) but they are not around the table as we typically use metrics & the occasional field test session - so we don't have a customer figure handy as required by agile.

Instead I have found that what works well is to know the agile principles and use their best ideas as far as possible while working in a way that is resilient against breakdowns.  I call this "raiding agile".

Backlogs are the best idea ever, a great takeaway from the agile camp & the first and best step you can take along the road to delivering your game without crushing your people in a schedule hell is to switch to backlog driven development.

The basic approach we take (raiding agile) can be broken down into 3 parts:

• Unleash your People
• Tool up your Communication
• Gamify your Planning

To get your head around the approach we take, basically just use one simple mnemonic - it all comes down to people-power: free your people & empower them to solve the problem of planning your project; communicate constantly and excellently with your people and gamify the planning using backlogs so that every day your people are doing the planning work of keeping your project on track and having fun while they do it.

So how does it work in practice?

Unleash Your People

James Everett talks on "Trust in Game Design NZGDC 2016"

Unleashing your people is about trust.  Trust is a top item in the agile manifesto and something crucial to getting your team working.  Top designers & producers in game development already know this even if they don't use agile.

In the seminal 1999 book “Peopleware: Productive Projects and Teams” Di Marco and Lister explain that management’s job is not to make people work.  Instead your job is to make it possible for them to work.

As a leader, you work to build trust: work to be in a situation where the people who work on your team trust you, and more importantly you trust them.

Your success will be defined not by how carefully you lay your plans; but by how well you recover when they go wrong.  And you will go wrong.  When it happens, your team will be there; if you have built trust.

If you try to impose control from the top, it amounts to a lack of trust that people will work what’s needed for the project.  Having your people waiting around for sign-off, when they could be working is waste.

Having people get into what I call the “Inbox” mentality where they live their work lives like a rat in a cage pressing a bar, checking for the next item of work to be given to them by their supervisor.  That is not how lean effective teams work.  Companies that operate via their inbox, and pleasing bosses, lose the ability to respond quickly; they sacrifice agility and vibrancy for no actual gain.

Tool up your Communication

OK, so we’re going to TRUST our people, empower them to work on the project.  How do we as leaders make sure that the project is on track then?  Isn’t it our job to motivate them?

Imagine the throughput of your team is defined by this triangle - in this model the sides remain in constant proportion.

Once you have hired someone competence is fixed. Lets assume you have a team and you want to make the best of them.

Motivation - You could be forgiven for thinking that comes from being paid.  Some think in a dated way, an authoritarian way that motivation must be imposed from the top.  Let me tell you for creative people it comes from a raft of things, such as accomplishment, and recognition.

But in my experience its the communication which winds up being the restricting factor MOST often.  If you improve communication that you will begin to reach the potential of the motivated competent team.

Technical projects have failures - but those are due to human reasons.  Most often from a lack of shared understanding.  The best bang for your buck, for improving team performance, is time spent on communication.  And that means written, and verbal, charts on the wall, wiki pages - anything that gets a shared message across.

Your job as leader is to filter outside impacts that can derail the team, simplify the view they have of the overall product and provide a compass set on true north.  Provide a consistent drum-beat that gives the project a cadence.  Through that repeated message infect the team with your own enthusiasm for the mission of the immediate project goals.

“We are going to ship the beta in March” - keep talking about what that will mean, and what it will look like.  Check back to see if people understand what that goal is - when it bites, what counts as success.

Have GBC - a great big chart stuck physically to the wall that shows that goal.  If I walk up to one of your team members and ask what is the next big milestone, whats in it and when is it due?  It should roll off their tongue instantly - if not, then that is on you.

Be Precise & Specific

Systematize names for things and use them across the board.  Don’t use vague words like “the build” or worse “IT”.  Make sure your tools, your plans and your verbal communications always use the same terms.  People cannot see inside your head.

When will “IT” be ready?  

Is “IT” done yet?

 If you ask an artist working on a concept for a character when will “IT” be ready, does that mean the concept, or a set of poses, and clothes?  Use the milestone and feature names to avoid the “IT” problem.

Make Sure Communication is Two-Way

So you’re communicating clearly with your trusted team.  Is that communication two-way?  Trust comes when your team knows that they can tell you ANYTHING without fear.  That comes when you admit you don’t know.

Google’s 3 year long study Project Aristotle set out in 2012 to see what made the best teams.  Their leads had believed conventional wisdoms like the teams that did the best were the ones that had the most talented members.  But it had not been studied to find out how true that was.

Turns out that people needed Psychological Safety which is ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up’’

As a leader you have to make sure that members of your team are rewarded for contributing their slice of wisdom.

Have you heard a conversation where there’s that one person who “knows more” than every one else?  Others should “shut up” because the authority is talking?

Knowledge is not a high-watermark.  Even if someone is still learning compared to an experienced person remember this: the contributions of even the most inexperienced member of your team is never submerged by another.  Team members contributions overlap. 

Make sure their slice of wisdom is heard.  They may have had the one vital clue for the success of a critical part of the project. 

Use Tools to Help Make This Happen

How can ensure that all team members are contributing in that communication two-way street?  Obvious ways are to show leadership in meetings.  Make sure your loud confident types cede the floor and don’t interrupt.  Try a round-table technique for your stand-ups and other essential meetings.  Use a “speakers totem” if necessary to shut up repeated interrupters.

Even better - and this is a nice segue into the next of the 3 tricks - consider using tools that gamify and level the playing field when it comes to meetings like the daily standup.  At Smithsoft we use the Slack on-line chat tool, with its scriptable bot, to manage our daily standup.  Wikis, source control, online-test-plans, and Drop Box all have their place too.  Trello and the Google suite of cloud-collaboration & document tools are also great.

The single best communication tool is working software.  An up-to-date version of the game, which everyone on the team can access.  Your tech team should prioritise what’s called “continuous integration” - which basically means automatically getting new builds when changes are made.

Team members who are remote or working remotely, or from home are not out of the loop.  Breakdowns & mismatches are avoided.

Yes - there’s value in face-to-face, or video conference hook-ups, but their usefulness has to be balanced with the time-wasting aspect.  Making people report in personally to a meeting like little tin-soldiers might give a feeling of control, but once you’ve dished out that sermon on the mount, how much of it actually sank in?  Meetings, and especially ones where the communication is mostly all one way is a number one time-waster that you can move away from as you pursue a lean and creative team methodology.

Gamify Your Planning

OK, you’ve unleashed your people and tooled up your communication.  Now you have everything buzzing, how to make sure you get the project delivered out of all that energy?

It turns out that there is one huge shift you can make with your project management; if you’re not doing this already, prioritize people over days.

They are not human resources.

At the beginning of a two week period, the team goes through one by one & makes a list of all the tasks they will commit to complete that period.  We call the period a “sprint”.  As far as possible teams should be multi-disciplinary with artists, technical artists, programmers, QA people and designers all working side by side on functional areas of the game.  This way they see & communicate issues in real time.

Team members only commit to what they know they can do, and they OWN that.  The whole team agrees that those tasks advance the mission of the project, by delivering value to your players.  Because you’ve communicated the mission to them, they know what success looks like, they know to measure each and every task against that vision to see if it is up to snuff; before adding it into the sprint.

The tasks then become cards in a game, played in rounds & turns.  This leads to ceremony around the working day which structures your teams work in a way that makes it obvious when the agreed upon plan is strayed away from.  The rules of the game help reinforce ways-of-working that stop the classic mistakes of human nature such as "The Planning Fallacy".

Well, you might now say, great - I’ve burned my GANTT chart and I don’t know what we’re delivering any more!

Actually you do.  Because you have used communications, with specific clear terminology, and you have working software, you know exactly what you’re delivering.  You see it every day.

Its the working software - the current build of the game.

And actually you know MORE - because you can look ahead and see where the trend line goes.  How many stories are we getting through?  This is the teams VELOCITY.  You can use a fancy graph like this one.  But the best thing is just to put a big chart on the wall and use a marker pen to keep it up to date.  Or just track the velocity as a number.  If you like you can break it down by team member.

How many tasks are left?  You know your delivery dates - simply draw a line across  your backlog at the cut off date and you can SEE what features are in and what don't make it.

https://github.com/sarah-j-smith/trelloburn

But I have to have my feature!  

OK, sure - time to horse trade, what other feature do you want to swap out so that the one you want in makes the cut?

Now you have a dialog that allows you to negotiate and still have a working game.

Closing:  People Before Tools

Beware of becoming seduced by tools.  A lot of managers I have worked with in the past will say things like "We're using Trello" or "We're using Jira" as though that completely describes the ways of working of the team or studio.

A burn-down chart like the one above is not your process.  If that starts to happen, go back to basics and use a number of a rough chart on the wall.  

The truth is not some graph produced by a tool - its what your people are producing and what the working software says.

Also I'm not saying this way is simple: its hard, and our teams still struggle every day to stay on target.  But at least by putting people first you as a leader, studio founder or producer are not trying to do all the planning with bogus numbers on a fictional GANTT chart, and you have help with planning from your team.

In closing I’d just like to summarise: you can beat the Planning Fallacy & other mistakes, by getting your team to divide a creative milestones into small, simple, same-sized, swappable stories stored into a prioritized backlog.  

Good luck and have fun!

Pandora's Books Coming Soon!

Lately all my time has been devoted to Game Development so I have not been posting much.  What have I been up to?

Since January 2016 with Space-Bot Alpha behind me, I expanded the studio and bet the farm on a new game Pandora's Books.

It's a game about Pandora who opens the wrong book and releases the chaos wizard & his minions onto the worlds of classic stories.  As a player your job is to unscrambled the mixed up words, to defeat the wizard & his minions, and save the cities of these timeless tales.  The game ships with War of the Worlds unlocked and as you play you collect clues that can be used to help when you're stuck on a word, and also saved up to unlock books.

The team has been amazing, and last week we pushed the game to Apple's App Store editorial team in the hope of getting a feature!  This is the "big time" for me, and I guess even if we don't get the much-vaunted Apple feature we still have a great game which will go live on August 18th.

If you want to follow my journey as an Indie Game Developer why not subscribe to follow this blog and keep up with future posts?

Thanks for reading!

Sprite Kit for the Win

My game development work these days is all done in Apple's Sprite Kit, which is a dedicated 2D game development technology.  To my knowledge Apple is the only device vendor making game APIs like Sprite Kit.  Google has some back-end stuff but nothing to put sprites on the screen.

Sprite Kit is a "no engine solution".

The correct term for it is framework: Sprite Kit is not an "Engine".  You hear that as a common term around game dev circles: "what engine are you using?".  Sprite Kit is a "no engine solution".  In this article I lay out my reasons for choosing Sprite Kit for my professional studio's development, and what this distinction means in practice.

Editing a Sprite Kit Scene in Xcode

In game dev you try to separate code from assets, functionality from data, as you do in regular programming or good software engineering.  A key difference is the degree of separation and what role your game plays on the device when you use a framework rather than an engine.

• With a framework you are actually writing a computer program,  in essence, and that program is an executable, which runs on the platform making calls via a framework API to load assets and data.  There may be tools to create data like levels and maps into a form that the framework API calls can consume.  But those tools only exist as part of a set of programmer's productivity helpers, and typically its possible to edit that data using other tools if needed.  
• Essentially in the engine case, your game is NOT a program, its all data.  The engine is in charge, and you provide your game as a package of data for the engine to operate on.  The engine has a combined editor and previewer that encapsulates the entirety of your creative process, capturing your scripts, assets and other inputs into a package and giving an almost-real-time view of the game.

What is it that we get from game engine makers, like GameMaker, Adventure Game Studio, Unity3D, Unreal Engine or CryEngine?  They ship pre-packaged functionality, such as "place that quad over there with this texture on it", and "apply that animation to this object node".  You provide a package of data, which includes visual assets such as images & models, and logic assets such as scripts, that the game engine loads and at various times to render and evaluate.

Framework eg Sprite Kit vs an Engine

What is the real-world implication of this?  Basically you can only do (easily) what the engine provides for.  If you write a script or make an object that invokes cool engine functionality you can move mountains and make magic.  But when you try to just make a button behave like you want, and the engine doesn't support that it becomes ridiculously painful.  Mountains of code or even an external plugin has to be used.

• With an engine
• some incredible things are easy, and 
• easy things are (often) strangely hard. 
• publishing/shipping is way harder than it should be 
• With a framework API 
• everything is possible, and 
• easy things are (often) a bit hard
• shipping is what they do best

These attributes mean that engines are great for prototyping (as long as your prototype is a game that the engine can easily make) but things get hard quickly when you try to exert your will and design intent over the game; and also when you start to get closer to publishing and want to integrate platform API's for things like In-App Purchases.

Having said that engines like Unity are incredibly powerful and talented 3D programmers have produced a lot of common 3D rendering functionality into a tightly honed and well-documented beast which you can call on to get your game up and running quickly.  Of course you don't get this for free: a professional studio has to pay $1500 USD for each of Unity Pro, Unity iPhone and Unity Android - so a total bill of $4500 USD (or around $6000 AUD) per seat.  And then you pay that again when Unity goes up a major version number.  Its worth every penny - if you need that 3D functionality.

The essential trade-off is that particular engines are well-suited to producing a particular type of game.  In fact most engines already have a type of game in mind.  Unity is ideally suited to games where a 3D avatar in either 1st person or 3rd person is running around a world, followed by a camera.

You can of course fix that camera, get rid of the avatar, and place a 2D orthographic scene in the view to thereby construct a 2D game.  This is kind of like using a Mack truck as a garden shed: you've got all this powerful 3D architecture under the hood, and your fixing most of it in place so that you just use the 2D side of it.  But as mobile devices get bigger and more powerful, and include 3D rendering hardware it turns out you can get away with doing this.

As a programmer however, you can do away with all this extra baggage and enjoy the following benefits:

• faster load times (no 3D engine to load)
• zero cost per seat development
• less licensing hassles
• traction with Apple
• immediate access to Platform API's
• App Slicing
• In-App Purchases
• open source community
• 3rd party stuff often $0

What are the drawbacks:

• You need a programmer
• Non-tech team member friction
• Less off-the-shelf "store" assets
• Code is not cross-platform

One of the difficulties with Sprite Kit is that many artists, animators and other creative professionals who are not programmers do not have experience with it yet, and thus find it hard to directly contribute their assets to it, and work with the tool set.

However I think this will change as Apple has a huge commitment to making coding with Swift and Xcode more open and available to the wider creative community.

The Sprite Kit route was a no-brainer for me as I have a career as a software engineer behind me in my game development.  Also I had my previous experience with Cocos2D which has a very similar API.  I don't need the features that Unity excels in such as 3D.  As a founder of a studio I don't want our IP saddled permanently with the licensing and lock-in hassles of being welded to Unity3D - which is a proprietary technology.  Unity also likes to monitor your games so that it can tell if you're adhering to the licensing conditions and it requires you to notify your players of this.  Basically for me its about having control over my game and my IP.

Swift, and pretty much all the Xcode & Apple toolchain is Open Source and Xcode itself is at the end of the day just an IDE, so there is nothing stopping me editing my code in JetBrains AppCode or other tools.  I could edit my assets in other tools such as for example Texture Packer, and TileEd.

Want to give Sprite Kit a serious try for your studio's next game?  I strongly suggest going and buying Ray Wenderlich's PDF book "2D iOS & tvOS Games by Tutorials".  They update their stuff and you get the updates for free, and despite the title its not just a starter book, it teaches you 90% of what you need to get going, and gives a huge bunch of sample code as well.

Your mileage may vary.  But have a look at the pros and cons, and especially try to think of the longer game if you're a professional studio, or consider that you might want to be a buy out option so that you can at some point exit your studio.  Due diligence and buy-out exits are much easier when you have the fewest possible licensing hassles linked to your IP.

I hope this article helps, and if you share some of the same aspects that I do when it comes to game development you can be clearer about your choice of engine or framework.

Thanks for reading!