Skipping Feb OGAM

I’m skipping the February OGAM due to a house move and illness. Luckily I have a design in mind and it’s one I want to work on a bit longer term so I expect to release something, just not to the deadline!


Resolution v0.1.0

I’ve been busy with a house move for the last week so I’m releasing where I last left Resolution. It has a way to go before it’s a proper game, but it’s got the basic mechanics in there. I’ll call that a tick in the box for my January OGAM entry.

Left and right control the character, up and down vary the target speed for running. The max speed you can run at depends on both your energy and current weight. Either of these are affected by how long you run for and what you eat (energy bolts or food).

It’s obviously missing some major features, which I’ll add over time when I can:
– Scoring and failure state. I imagined that coming off the end of the treadmill would be failure. Wah wah wah wahhhh. The longer you’re on, the higher your score counter goes. Or pickups. I dunno.
– Game state handling to let you start at your leisure, pause, and handle the end game states.
– Better balancing of pickups. At the moment they’re randomly spawned across treadmills, increasing in rate as you avoid them, decreasing if you hit them. It also needs to distinguish between good pickups (energy) and bad (food).
– More treadmills. I’ve implemented variable speed treadmills, so these can be added to make it a challenge to move around the whole scene. This could then be tied into a risk/reward system for collectibles.
– Tuning. It needs it. Much of it.
– Sound? Who listens to things anyway?


Resolution: First Demo

I’ve managed to find a few hours to play with both Unity and the wonderful (in my unskilled hands anyway) Pyxel Edit so have made a start on my January OGAM entry for Resolution. Non playable at the moment, just demoing animations, variable speed treadmills, working HUD meters and spawning of random pickups. Looks fun doesn’t it! No? Fine … see if I care.


One Game A Month

I already know 2015 is going to be a busy year. I should have a new house to play in, with all the associated DIY and building work that will come with it. Work isn’t going to get any easier so will either kill me or drive me into a change of jobs, neither of which option is going to result in me being rested and having an abundance of free time. I’m already signed up for at least one comic con for which I’ll need to get my cosplay sorted. I’ve also got quite a few weddings and stags coming up this year. All that doesn’t leave a lot of time to focus on realising my pages of scribbled notes and game ideas, so there’s only one thing for it: I need to set myself an unattainable target! One Game A Month seems like the perfect target to follow. Someone else can manage the tracking and goal settings, and I can sit back and fail to hit any of the deadlines!
Seriously though, it’s a good framework to get myself to put some effort into working on some game development. Every month there’s a new theme to work to, which should help me to branch out or inspire some new challenges. Even if I do the minimum for a given month – create a tech demo or follow a game tutorial that fits the theme – it’ll help improve my game dev skills. I will make one prediction now – September is going to be mega-busy so I expect to be missing that deadline!
The first theme word for 2015 is “Resolution”. I’ve got an idea in mind for a small mini-game about weight loss so let the games(dev) begin!


The Problem with Motion and Touch Controls

The recent announcement by Microsoft that they will be selling the Xbox One without the bundled Kinect has sparked mixed reactions from critics and developers.  From my perspective, Microsoft seem to be accepting something that I’ve been thinking about for a while – the problems with waggle and touch controls for gaming (which I’ll collectively refer to as “waveprod” from here on).

I should point out at this juncture that I think both motion tracking technology and modern capacitive touch screens are amazing advancements in consumer tech.  I attended a lecture by Professor Chris Bishop a couple of years ago on the science behind Kinect and it’s truly fascinating stuff.  The thing is, a lot of his own enthusiasm for the product seemed to come from applications outside of gaming, such as helping doctors control interfaces in sterile environments.

I’m also not trying to say that these types of interface have no place in the gaming world.  There have been some excellent applications of the technologies thus far, and I’ll touch on how some of these implementations overcome the issues with waveprod.  Unfortunately there are also some oft repeated mistakes made with waveprod implementations in games, quite often as a result of lazy porting of an aspect of game design to mobile platforms.  I’m going to touch on two different sides of the waveprod problem – the connection to the game, and the connection to the player. … 


Nexus 7 Bluetooth Keyboard and UK Layout

I’ve really been enjoying playing with my Nexus 7 but have discovered a slight problem. I decided to purchase a bluetooth keyboard and so grabbed myself a Perixx PERIBOARD-804. This won out over the Zagg Keys Flex and the Logitech keyboards thanks to compact size, internal USB-rechargeable battery and UK keyboard layout. Unfortunately, while testing this out on the Nexus 7 I discovered that the Nexus doesn’t come with UK keyboard layouts for external keyboards. I haven’t been this annoyed by a keyboard layout since I bought a Mac. Anyway, after a bit of digging around online I found that it’s possible (with root) to upload a custom character mapping for my device to make it work as expected. You can read more about the specs of these files over at the Android Open Source Project.

New Configuration

Two files need to be created to ensure that all the buttons work as expected:

  • A Keyboard Layout which defines which android key code results from a key press.  This lives in /system/usr/keylayout and is named Vendor_<VendorID>_Product_<ProductID>.kl
  • A Key Character Map which defines which android key code produces which character (with modifiers).  This lives in /system/usr/keychars and is named Vendor_<VendorID>_Product_<ProductID>.kcm
Each of these locations contains a Generic.kl/Generic.kcm file that can be used as a template for any changes. These files are used when no other suitable configuration is present so I suggest not editing them directly, or at least backing them up.

Identifying the Device

The VendorID and ProductID in the filenames are used to match the configuration to the specific device.  With the keyboard connected this can be found in a shell (adb or on device) by looking in /proc/bus/input/devices.

shell@android:/ $ cat /proc/bus/input/devices
I: Bus=0005 Vendor=04f2 Product=1063 Version=0505
N: Name="Bluetooth Keyboard                   "
P: Phys=10:BF:48:F3:8B:E2
S: Sysfs=/devices/platform/tegra_uart.2/tty/ttyHS2/hci0/hci0:12/input4
U: Uniq=90:7F:61:8E:78:A4
H: Handlers=sysrq event3 keychord
B: EV=12001f
B: KEY=4c37fff 72ff32d bf544456 0 0 1 30f90 8b17c007 ffff7bfa d951dfff febeffdf ffefffff ffffffff fffffffe
B: REL=40
B: ABS=101 30000
B: MSC=10
B: LED=1f

Here my Vendor ID is 042f and my Product ID is 1063. Once you’ve created your baseline files by copying (adb pull is your friend) the generic configuration and renaming to match your Vendor & Product IDs you can jump into them and make the changes you require.

Changing Keys

In my case most of the work was in the key character map file (moving quote marks, tilde, etc.) and you may not need to make any changes to the keyboard layout at all. One change I had to make was to support the # key on a UK keyboard (which has the ~ character above it). The generic keyboard layout was sending it as a backslash, along with the actual backslash key. To find which key to change I needed to know the shortcode being sent by the keyboard and for this you can use KeyTest.apk made by Chris Boyle. This app will run and report the short code for all key presses so you can hunt down the one you’re interested in. In my case this meant changing key 43 BACKSLASH to key 43 POUND in my layout file and then putting a corresponding entry in my key character map:

key POUND {
    label:                              '#'
    base:                               '#'
    shift:                              '~'

Note that this format for the character map is supported from Android 3.0+ (the Nexus 7 is on 4.1 at the time of writing). It’s worth digging into the documentation to read up on the various modifier keys you can react to. Power users may decide that they want alt characters for all of their keys to produce special characters. The AOSP docs explain a bit more about any escape characters you might need to use in special cases as well as how to represent more exotic characters as unicode code points. Wikipedia should serve to provide a reference for the latter.


Once you’re done with your new configuration you’ll want to deploy this to your device. I did all of this using adb as follows.

  1. Put my new configuration in two local directories: keylayout and keychars
  2. Create a keyboard folder in the root of your /sdcard partition.
  3. adb push your configuration to the device:
    adb push keylayout /sdcard/keyboard/keylayout
    adb push keychars /sdcard/keyboard/keychars
  4. Launch adb shell and run the following commands:
    mount -o remount rw /system
    cat /sdcard/keyboard/keylayout/Vendor_04f2_Product_1063.kl > /system/usr/keylayout/Vendor_04f2_Product_1063.kl
    cat /sdcard/keyboard/keychars/Vendor_04f2_Product_1063.kcm > /system/usr/keychars/Vendor_04f2_Product_1063.kcm
    chmod 644 /system/usr/keychars/Vendor_04f2_Product_1063.kcm
    chmod 644 /system/usr/keylayout/Vendor_04f2_Product_1063.kl
  5. Wait for your device to reboot
  6. Profit


Voila! You should now have a working keyboard layout for your device! If you’ve also got the Perixx 804 then you can take my configuration files from a repo on GitHub. Please feed back any mistakes you find and shout if you’d like any more layouts uploaded. If I have time I might try to get an app together for installing any configs from git and/or editing these config files on the device.


If you’re trying to do this yourself and having difficulty troubleshooting what’s happening, keep an eye on adb logcat when you’re connecting your bluetooth device. A message should appear telling you which layout and character map files are being used. This helped me identify what was failing on my first attempt and I eventually tracked a problem to a duplicate definition for POUND in the character map.

A shout out to this post on the Thrive forums for getting me on the right track.


Spending Time to Save Time: Automating My Builds

As a one man developer it’s very easy to fall into patterns of bad habits with the development process.  I don’t have a team to worry about, I’m not beholden to any code reviews or quality metrics and it’s just me and my PC, so why go the extra mile to do things right?  Some things have clear benefits and such a small up-front effort requirement that they’re a no brainer.  I have a svn repo running on my NAS and this has saved me many a time – do not underestimate the sinking feeling you will get when you realise the drive that just failed in your PC was the one with your dev environment on it.  Even if you don’t have a seperate server for source control, it may be worth considering a local install and then regular dumps of your repository to external storage.

OK, so that was quite an easy example.  Job done, point justified right?  Well, not quite.  I’d like to share an example of another area where a little bit of upfront effort has made my life easier: automation in the build process.  Now, to be clear, I’m not talking about a full end to end build process / CI here.  At the moment I don’t see the value in that beyond providing me with an excuse to spend money on a server.  Any changes I’m making in code I’ll be immediately deploying to either a simulator or device depending on my current requirement.  There is, however, one key part of my build process that needed some automation and that’s creating art resources.

I’ve written before about the tools I use to create sprites: Inkscape, Blender and TexturePacker Pro (with a splash of Paint.NET) all come together nicely as a toolbox for those who aren’t up to creating graphics by hand.  The thing is, when I want to tweak a sprite, change something completely, add something new or provide assets for multiple resolutions I have to go through a hell of a process to manually deploy this to a build.  Let’s take creating a new menu button as an example:

  1. Create the menu button in Inkscape
  2. Save this somewhere sensible that I’ll find again later
  3. Export the region I want at a scale for the app sizes I want (1080p, 720p, SD, etc.)
  4. Store these exported files somewhere
  5. Open up the texture atlas definitions for each app size and add the new assets
  6. Export the new texture atlases and their indexes and save these somewhere
  7. Copy the new atlases into each project that uses them and rebuild

The process doesn’t differ much for making small changes to existing sprites.  As you can imagine, this results in me looking at to-do items demanding I perform a bit of an art clean-up, sighing and then ignoring them in favour of playing with some new code.  Not a great position to be in. Looking at the above process, there’s clearly a lot of scope for automation and process improvement.  I’ve probably made a lot of things more difficult than they need to be as this was my first project.  Luckily, all of the apps I use come with command line functionality that provides what I need to make my life easier.  By making a few design decisions I now have a three step process:

  1. Create / edit Inkscape / Blender files
  2. Run batch script
  3. Rebuild apps

Nice eh?  To do this I’ve set up my environment in the following way:

  • All projects now look for texture atlases in a root project folder called Resource[X]\textures where the [X] is a number indicating whether the resources are HD or not
  • All Inkscape / Blender files are designed with the assumption of a HD screen to display on and placed in a Textures path within the project directory
  • Sub directories within the Textures path group the texture source files together by theme (uicontrols, menus, decorations)

The batch script (Windows version attached) iterates over each sub-directory and uses Inkscape and Blender to output full resolution PNG exports of each file to a temporary directory, divided up with the same sub-folder structure.  TexturePacker Pro is then used to create an atlas from each of these sub-directories.  This is run three times as TexturePacker Pro will handle reducing the size of the atlases for the different resource sets (I use three multipliers – 1, 0.7 and 0.5).  All that is then left in code is to import the atlases and refer to the textures within by name.  While the process could certainly be made more efficient (by not re-working items with no changes), this isn’t necessary for my personal needs.

If you want to look at the details of the arguments I use on the command line, grab the batch script and take a read.  It’s not amazingly complicated but the effort required to create it more than pays for itself.

The script: generate_svg_to_png


Blackberry PlayBook Development: First Impressions

I should open with a summary. My first impressions of developing for the PlayBook have been very good overall. In the past I believe RIM haven’t made things that easy for many developers to get started on their platforms. My account was originally registered in 2009 when I used to own a BB, but I quickly gave up when faced with requirements to get notarised ID, etc. etc. Some of these problems apparently existed earlier in the PlayBook’s life as well but RIM has taken note and clearly been working to make things better, but there are still some opportunities for improvement. I’ll tackle my first impressions with getting set up to develop for the PlayBook by theme: registration, tooling up, development, support and publication. With all of these I’ll try not to dwell on timelines too much – there has been a massive influx of developers and apps thanks to the PlayBook giveaway and it sounds like RIM have been swamped dealing with this.

Initial sign up as a vendor for the BlackBerry App World is a fairly simple web based affair with few pitfalls. As an independent developer you will be asked whether or not you will be charging for apps. I believe this can be changed later. If you do opt to put apps up for sale then you will not have your vendor account activated immediately. You will be sent an e-mail requesting proof of ID and this is then reviewed by the App World team. In my case this was turned aroundin a couple of working days and they were happy to accept scans of my UK driving license as proof of ID and address. This is a big improvement over my experiences of a few years ago where more expensive options involving notaries were involved. There’s also no charge to register as a vendor these days, which is certainly competitive given the Play Store $25 up front and Apple’s annual $99 fee.

There’s not a lot of room for improvement here. Two small things spring to mind:
1. The generic ID requests aren’t very helpful. There needs to be more details of what is acceptable, especially for international vendors.
2. I now have seperate accounts for the vendor portal, the forums and the BB Jam Zone. Wouldn’t it make more sense to do this as single sign on, possibly linked to the BlackBerry ID.

Tooling Up
There’s quite a range of platforms available for development on the PlayBook: C++, HTML5, AIR, Android. The choice for each developer is likely to come down to where they may have existing components to re-use and any cross-platform considerations. Personally I went for the C++ native SDK route and my choice was driven by wanting to use a particular framework (cocos2d-x).
All of the tools you need are freely available on the BlackBerry Developer site and you don’t need to register to download these so you can have a play with them before you commit to the world of RIM. Along with the development environments / eclipse plugins offered, there is also a PlayBook simulator. This runs on VMWare Player in Windows or VMWare Fusion on a Mac. For native SDK development, the QNX IDE (built on Eclipse) is a nice clean tool and integrates well with the simulator running in the VM.
Getting my hands on the tools was one experience where there is definite room for improvement. I’ve got the following gripes I’d like to see disappear over time:
1. You want me to download how much?!? These things are absolutely massive. Additionally I can’t see any updating path that doesn’t require a full re-install (certainly updating both the ndk and simulator from the beta required a full update). This is quite a fail IMHO – take a lesson from Android’s SDK manager, not Apple’s delivery of an installer through the App Store.
2. Do not try to force a downloader plugin on me. I like my browser how it is thanks. I have to reject the install before I’m even offered a direct link. In all honesty, I wouldn’t have minded so much except when I first tried the downloader plugin it downloaded everything and then kept delivering broken installs. Avoid like the plague.
3. VMWare Player is fine. It’s free and only requires an irritating registration with VMWare. VMWare Fusion, however, is a retail product – I like to develop on my Macbook Air when I’m on the move so this has basically forced me to outlay thirty quid to keep my simulator running. Bravo RIM, bravo.

RIM have provided a few examples to get you kicked off on the dev side. These are helpful, but what is even better is that RIM really seem to have embraced bringing Open Source components into their platform. There’s a whole page dedicated to open source components that have been tested with the PlayBook. This is especially handy for game development – no need to ween yourself off Box2D!
Documentation is present, but I found it rather hard to navigate. In my opinion it could do with a bit of work on the layout of the docs. There are a few too many pages that don’t provide enough cross linking to help you dig into further detail, instead just leaving you in loops where pages link back to each other. I have more than enough of that using HMRC’s website.
All in all I can’t complain about developing for the PlayBook. I didn’t run into any real problems beyond the standard PITA of setting up environment variables on OS X. Only one improvement suggestion here:
1. Give me a local copy of the docs please! KTHXBYE.

Support for developers by RIM has blown me away. Even ignoring the idea of pushing devices out to people as a reward for publishing an app, I’ve seen a great level of support in the few weeks during which I was getting Flip! migrated.
The Developer Support Forums have some genuinely useful people on as well as BlackBerry personnel chipping in with helpful answers. There’s also a good BB dev presence on Twitter and their Blog. I’ve been impressed with the level of engagement from people like Alec Saunders and Alex Kinsella as well.
The only issue I have is that their forums are a little clunky and aren’t always easy to search or navigate. I’d really like to see a community wiki growing at some point as this would help flesh out any gaps in the documentation.

Publishing to the App World is done through the vendor portal. The portal allows you to maintain your application descriptions, prices, screenshots and releases. It also provides facilities to set up test “sandbox” account to test purchases without having to make an actual payment.
All releases to go onto the App World go through a review and testing process. Much like Apple’s offering, there doesn’t appear to be a lot of transparency around exactly what goes on in this process. From anecdotal evidence on the BB Dev forums, this lack of transparency extends to rejection feedback, which may irritate many developers. I haven’t experienced this personally so I won’t say any more. The review SLA is 7-10 days, and by all accounts they are able to hit this (outside of free PlayBook madness periods). On releasing an update with minor changes, the review turnaround seemed even quicker so I can only guess that the update reviews are a lighter version of the initial approval.
Once in the App World, I could easily search for the name of my app and find it (you hear that Google?). Unfortunately there’re a couple of issues with the App World. For one, the screenshots seem to be getting massively downscaled at the moment so appear very pixellated. The second problem for me was that the RIM view of links to the App World seem to be all about going to single apps rather than vendors. The web portal for the App World does offer a way to view all apps by a vendor, but the PlayBook itself (and so the calls you can make in the native SDK) does not. This seems really odd to me as it seems a no brainer to allow publishers to present links saying “hey, did you like this? Have a look at our other stuff then!”
The one other problem I have with the App World over the Play Store is that I have to use my real name as an individual. I don’t exactly go to great lengths to hide my identity on the internet, but in this case I like to put everything under “floor4”, something I’m not able to do here without registering a name to trade under. I understand, however, that this is a very personal gripe so I can’t really hold this against RIM.

So my overall experience with developing for the PlayBook has been good. There are certainly improvements to the process that could be made, but I’ve never seen a process that couldn’t do with tweaking and RIM certainly seem to be trying to introduce more and more improvements. At the end of the day, it’s another market and well worth your time to investigate. With BB OS10 around the corner you never know, RIM may just get back in the game and make us think of the top three of the mobile world rather than just the two (oh … and WP7 I suppose …).


Development Update – February

Another gap in posting, but a productive one. In January I was investigating some cross platform Lua based frameworks (Moai and Gideros) but between a skiing holiday and recovering from injuries sustained while on a skiing holiday I didn’t get beyond a few proof of concepts. Both are worth a look, and I’ll probably return to them in the future, but my investigations were derailed by this post on the Inside Blackberry Developer’s Blog.

So, with PlayBook OS 2.0 comes (limited) Android support and RIM were offering PlayBooks to developers who submitted apps within a timeframe. Hard to resist really (and it’ll be interesting to see how this pays off). As I have no willpower I went ahead and signed up, hoping to easily repackage Flip! for the PlayBook. I ran into immediate problems as (among other things) native code in Android apps is not yet supported, but this provided me with an opportunity to pick up one of my other to-do list items and learn to use cocos2d-x along with relearning C++ so I could re-build Flip! using the BB Native SDK. I’ve now completed this and just had the app approved on the App World! I eagerly await my new shiny shiny and will tell all about it when it arrives.

I’ll get a post up this weekend about the process of signing up for PlayBook development and my first impressions.


Yet Again OS X Pokes Me In The Eye (or OS X Environment Variables)

I bought myself a Macbook Air last year to replace my ageing laptop. The theory was that I’d be using cross platform apps so the underlying system didn’t matter. Or rather it didn’t matter enough to outweigh the pretty 🙂

Anyway, not all of the niggles I have are down to OS X (Apple’s “we must have our own way” GB keyboard is bloody awful and seems designed to piss off developers), but many are and I’ve just come across another. Trying to set consistent environment variables across all apps, regardless of whether terminal based or launched from an icon is an absolute mess. Worse still, Apple doesn’t seem to offer any standard friendly configuration methods for environment variables. Pricks. Anyway, the best resource for troubleshooting these that I’ve found recently is this post on stackoverflow. I’ve reproduced it below in order to ensure it is captured and kept!

There are several places where you can set environment variables.

  • ~/.profile: use this for variables you want to set in all programs launched from the terminal (note that, unlike on Linux, all shells opened in are login shells).
  • ~/.bashrc: this is invoked for shells which are not login shells. Use this for aliases and other things which need to be redefined in subshells, not for environment variables that are inherited.
  • /etc/profile: this is loaded before ~/.profile, but is otherwise equivalent. Use it when you want the variable to apply to terminal programs launched by all users on the machine (assuming they use bash).
  • ~/.MacOSX/environment.plist: this is read by loginwindow on login. It applies to all applications, including GUI ones, except those launched by Spotlight in 10.5 (not 10.6). It requires you to logout and login again for changes to take effect. There is no reason to use this one any more.
  • ~/.launchd.conf: this is read by launchd when the user logs in. It applies to all programs launched by the user, GUI and CLI, on 10.5 and 10.6. Additionally, you can apply changes at any time by piping this file into launchctl (maybe grep ^setenv first if you have other commands you don’t want to run). Then the new variables apply to any application launched by launchd from that point on. This means you should restart for the new variables to cascade down into the shells it launches.
  • /etc/launchd.conf: this is read by launchd when the system starts up and when a user logs in. They affect every single process on the system, because launchd is the root process. Again, to apply changes to the running root launchd you can pipe the commands into sudo launchctl.

The fundamental things to understand are:

  • environment variables are inherited by a process’s children at the time they are forked.
  • the root process is a launchd instance, and there is also a separate launchd instance per user session.
  • launchd allows you to change its current environment variables using launchctl; the updated variables are then inherited by all new processes it forks from then on.

Sample setting an environment variable with launchd and storing it into your personal config so it works for your login even after your reboot:

echo setenv REPLACE_WITH_VAR REPLACE_WITH_VALUE >> ~/.launchd.conf

Now, launch your GUI app that uses the variable, and voila!