Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

Here’s a project I completed for WeeWorld at the tail end of last year. WeeMoji is an app for iOS and Android that lets you make your very own customised emojis and stickers featuring you!

At its core is a fun avatar creator where you make a little WeeMee that looks just like yourself. The app then generates a series of emoticons featuring your WeeMee that you can share with friends via your device’s messaging app.

There were several technical challenges that we had to overcome for this project. One of the requirement was that the app would have support for thousands of items of clothing and assets for your WeeMee to wear. Those items also had to be colourable along with the WeeMee’s hair, eyes, and skin tone.

We also wanted the user to be able to zoom into their WeeMee’s face without any loss of fidelity. In addition, the WeeMee was to be animated rather than simply standing static in the centre of the screen. And of course, it had to be cross-platform, be within app store binary size limits, and work without the need for any lengthy additional data downloads after installation. Easy-peasy!

Some of WeeWorld’s previous apps had similar technical challenges. They had been written natively in Objective-C (so were iOS only) and had gone for a traditional bitmap approach to handle the rendering of the WeeMee avatars. However this approach meant that the actual avatar fell somewhat short of the original vision. In those apps, the users were presented with a non-animated version of the WeeMee that was static and also had limited colouring options.

For WeeMoji we were determined to overcome these issues. After a few initial prototypes using Objective-C and SpriteKit, we decided to start prototyping in Adobe AIR, and that made all the difference for this project.

Adobe AIR’s vector rendering API really did save the day. We were able to import vector artwork created in Adobe Animate CC and scale that artwork up across any screen resolution. Gone was the need to generate multiple versions of each graphical asset for different target resolutions. Also, being vectors, the actual file size of each asset was tiny compared to the bitmap equivalent. The first release of the app went out with just over a thousand assets, which in total came in at around 12MB! Tiny! And that included animation in much of the content too!

Of course, all that vector goodness also came in handy for the app’s face & makeup editing mode. We were able to effortlessly zoom into the WeeMee’s face and show it off in even greater detail. In addition, we were able to apply some fairly complex animation to the WeeMee’s mouth and eyes, which really helped add a sense of personality to the user’s little avatar. All things that would have been difficult if we’d gone with bitmaps.

While Adobe AIR’s API covered most of our development needs, we also utilised a handful of native extensions from the guys at Distriqt. If you haven’t already, check them out.

It was a fun project to work on and I’m happy with the end result. you can check out WeeMoji here.

Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

I spent part of December working on an Apple Watch game demo. I was looking for a quick native project that I could get my teeth into over the Christmas break and thought it would be fun to write an endless runner. I actually couldn’t find any Apple Watch endless runners on the App Store so thought it would be an interesting thing to try.

The first thing was to decide on a theme. To be honest that was easy – I reached out to my brother who happens to be working on his own indie game called Dare the Monkey. He was more than happy to send along some graphics for me to work with and was actually quite excited by the prospect of getting an Apple Watch version of the game in return.

There were two main challenges I had to overcome during development. The first was simply maximising performance on the watch’s limited hardware. The second was ensuring a decent gaming experience on such a small screen.

I have a fair amount of experience with SpriteKit on iOS and the truth is that you really don’t need to work that hard to get a silky smooth frame rate. Things are a bit tricker on Apple Watch and even getting a consistent 30 frames per second can be difficult.

To maximise performance I had to remove several of the parallax layers that featured in the iOS version of Dare. I also had to be careful to reduce the amount of memory allocations and de-allocations that were taking place at runtime. Instead I opted to instantiate most things up-front and just keep them floating around in memory. There’s still more work to be done, but on the whole I’m fairly happy with where I’m at regarding performance.

As I said, the other challenge was creating a gaming experience that worked well on the watch’s small screen. Endless runners typically requires significant horizontal space for the player to see far enough into the distance. The watch’s square-shaped screen limits this look-ahead somewhat. To get around this I opted to zoom-out the game’s camera as the player’s character picks up speed. This lets the player see far enough to the right in order for them to react to upcoming obstacles.

There was also the issue of user interaction. To jump, the player needs to tap the screen. The problem with this approach is that a finger consumes a huge portion of the watch’s screen making it hard to actually see what’s going on during play. I got around this problem by providing a black rectangular area at the bottom of the screen for the user to tap on. Because of this I had to scale down the game world to fit the remaining vertical space. However, it actually worked to my advantage because it left the game with a viewport that had a wider aspect ratio rather than the original square shape.

So far, so good. I’m pretty happy with how things are going. There are a few things here and there to tidy up but hopefully we’ll see an Apple Watch version of Dare the Monkey released along with the actual iOS version of the app. Anyway, let me know what you think of the video above and I’ll keep you guys posted on how things go with it.

Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

I said in my previous post that I’d show off some more levels from my Tomb Jump game demo. So here’s a video of the game’s hardest difficult setting. While I was more than happy with my earlier level designs I thought it would be cool to try and recreate the sense of action and adventure from the movie Raiders of the Lost Ark. Remember it? Where Indy is chased by a huge boulder and also has to negotiate deadly spikes that pop up from the ground?

As well as adding these things I also wanted to lace the level with a few other ideas including doors that would slide shut behind the player, large drops into tighter shafts, sliding platforms, and doors that could only be opened by activating switches. I think it all added up to an exciting and challenging level. Possibly too hard for your average gamer but something I’ll definitely look at if I find the time to re-visit Tomb Jump in the future.

stored in: General, iOS, Tomb Jump and tagged: , ,
Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

Here’s a little game demo I bashed together at the beginning of the year. I’d been playing Mr Jump on my iPhone for an insanely long time and thought it might be a good idea to try and build my own game borrowing some of its elements. So I spent a few weeks coding Tomb Jump using Swift and SpriteKit. Okay the graphics aren’t much to shout home about – I simply grabbed what I could from the web to serve my game’s needs – but I really wanted to focus on making a really fun and challenging platform game and worry about the artwork later.

Whereas Mr Jump only scrolls horizontally, I was eager to have a game map that scrolled both horizontally and vertically. I also wanted to make the game camera subtly zoom in and out, allowing the player to see more of the game world at key moments. This let me implement some pretty dizzying jumps and drops into my levels, which you can see in the video above.

While Mr Jump has a blend of platforming action and insanely hard puzzle elements, I really only wanted to focus on the action elements for Tomb Jump and went about building three demo levels to try out some of my ideas. Each of the levels loosely represents a level of difficulty, with the video above showing off some of my ‘medium’ difficult ideas. I’ll post some more videos of the other levels in another post.

It’s a game idea I’d like to resurrect if I can find some free time. I might also try and find an artist to help bring the whole thing to life. Anyway, let me know what you guys think.

Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

This tutorial series has been updated for PixiJS v4.

Welcome to the fourth and final tutorial in the series detailing how to build a parallax scrolling map using JavaScript and pixi.js. In the previous tutorial we started writing the scroller’s foreground layer by implementing an object pool and learning how to work with sprite sheets. Today we’ll actually construct the foreground layer and write code to scroll its game map within the viewport.

What you will learn…

  • How to represent a game map in memory
  • How to display and scroll a large game map
  • The support code required to construct a game map

What you should know…

  • How to build and use an object pool
  • An understanding of JavaScript or ActionScript
  • Basic object-oriented concepts
  • We’ll continue where we left off. Keep working with the code you produced during the course of the first three tutorials. However, if you prefer you can download the third tutorial’s source code from GitHub and work from there.

    By the end we’ll have a scrolling game map that’s almost identical to that found in Half Brick’s excellent Monster Dash game. Remember, our map will be built from a series of wall spans of varying height and width, and we’ll take advantage of our object pool to retrieve the individual slices that make up each wall span. We’ll also add a little icing on the cake by gradually increasing the map’s scrolling speed over time, just like in Monster Dash.

    The final version of our scroller can be found above. Simply click the image to see it in action.


    Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

    This tutorial series has been updated for PixiJS v4.

    Welcome back to the third in a series of tutorials covering how to make a parallax scrolling map using JavaScript and pixi.js. A lot’s been covered so far. In the first tutorial you learned some pixi.js fundamentals and applied parallax scrolling to a couple of repeating layers. While in the second you wrapped your existing scrolling functionality into its own class by applying some object-oriented concepts to your codebase. We’ll now focus on a third, more complex, parallax layer which will represent the terrain that the player’s character would traverse if we were actually writing a full game.

    What you will learn…

    • How to work with textures and sprite sheets
    • The basics of object pooling

    What you should know…

    • Familiarity with pixi.js fundamentals
    • An understanding of JavaScript or ActionScript
    • Basic object-oriented concepts

    We’ll continue where we left off in the previous tutorial. You can either work with the code you produced during the first two tutorials or download the second tutorial’s source code from GitHub and work from there. You can also find the entire source for this third tutorial on GitHub although I do encourage you to work through the steps detailed in this tutorial and only refer to the source if you run into problems.

    This series of tutorials is very much inspired by endless runner games such as Cannabalt and Monster Dash, which both make excellent use of parallax scrolling to provide a dizzying illusion of depth as the player’s hero runs and jumps between platforms.

    Over the course of the next two tutorials we’ll build a scrolling game map very similar to that found in Monster Dash. Monster Dash’s game maps are built from a series of wall spans of varying width and height. The aim of the game is to survive as long as possible by jumping between wall spans. The scrolling speed of the game map increases over time adding to the challenge.

    A demonstration of what you’ll be writing can be found above. Simply click on the image to see the scrolling map complete with wall spans and gaps.


    Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

    This tutorial series has been updated for PixiJS v4.

    In this series of tutorials we’ll discover how to make a parallax scrolling map similar to that found in games such as Canabalt and Monster Dash. The first part introduced the pixi.js rendering engine and covered the fundamentals of parallax scrolling. Now we’ll build upon our first scrolling attempt by adding the concept of a viewport.

    What you will learn…

    • How to extend pixi.js display objects
    • The basics of object-oriented JavaScript
    • How to add a viewport to your scroller

    What you should know…

    • An awareness of object-oriented concepts
    • Some pixi.js fundamentals

    You’ll be working from the code you produced during the first tutorial. Alternatively you can download the previous tutorial’s source from GitHub and work from there. Additionally, the entire source for this second tutorial is also available on GitHub.

    As a reminder, click on the image above. It will launch and run the current version of our parallax scroller. There are only two layers at the moment but we’ll start adding a third, more sophisticated layer, in the next tutorial. In the meantime we’ll put ourselves in a position to add that third layer by adding the concept of a viewport. While we work, we’ll also perform some significant re-factoring in order to wrap our scroller within its own class.

    While this tutorial is very much aimed at a beginners level it does expect that you have at least a fairly basic understanding of object-oriented programming concepts. Don’t worry if that statement makes you feel a little uncomfortable, as I’ll still provide enough gentle prodding in the right direction for those who are unfamiliar with object-oriented JavaScript.


    Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

    This tutorial series has been updated for PixiJS v4.

    Ever played endless runner games such as Canabalt and Monster Dash, and wondered how to build their scrolling game maps? In this tutorial we’ll take our first steps towards building a similar parallax scroller using JavaScript and the pixi.js 2D rendering engine.

    What you will learn…

    • The fundamentals of pixi.js
    • How to work with textures and tiling sprites
    • How to implement simple parallax scrolling

    What you should know…

    • A basic understanding of JavaScript or ActionScript

    JavaScript is everywhere. Thanks to ever increasing browser maturity and the plethora of JavaScript libraries that are out there we’re really starting to see HTML5 games development flourish. But with so many libraries available, part of the challenge has become picking the right ones to work with.

    This series of tutorials will introduce you to the basics of JavaScript games development and focus on pixi.js. Pixi.js is a new 2D rendering framework which supports both WebGL and HTML5 Canvas. By the end you will have built the following horizontal parallax scrolling game map:

    Clicking on the image above will launch and run the final version of the scrolling map that you will be working towards. Notice that it contains three parallax layers: a far layer, a mid layer, and a foreground layer. In this first tutorial we’ll implement some basic parallax scrolling by concentrating on just the far and mid layers. And of course, to do that we’ll cover the basics of pixi.js. Also, if you’re new to JavaScript then you should find that this is a good place to start learning the basics of HTML5 games programming.

    Before we proceed, click on the image above to see a running demonstration of what you’ll actually build during this tutorial. You can also download this tutorial’s source code from GitHub.


    Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

    I had Sunday afternoon to myself, so I thought I’d port my HTML5 Flappy Bird clone to Adobe AIR and see how quickly I could get it up and running on mobile. It didn’t take that long at all and I was pretty pleased with the end result.

    Porting the JavaScript to ActionScript 3 only took about four hours if my memory serves me correctly. After that, all I needed was an extra hour to drop in some icons and launch images for the various iOS devices I had at hand. Since the project was using vectors, the game scaled really well across the various test devices, which included: iPhone 5, iPhone 6, iPhone 6 Plus, and iPad mini 2.

    Oh and as you can no doubt tell from the video above, I’m really really bad at Flappy Bird.

    Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditShare on LinkedIn

    From an early age, both me and my twin brother always wanted to make our own video game and have it released. It almost actually happened but unfortunately the stars didn’t align for us. In the end the whole experience put us off working together for most of our young adult lives. Here’s our story.

    When we were teenagers we were offered a publishing deal for an Amiga game we were working on. It was a dream come true and we genuinely thought big things were on the horizon. However, having to stay on top of university work and also finding time to make a game proved somewhat tricky. It ended up taking two years to finish the project and by that time Commodore had gone bust and the Amiga games market was on its knees.

    Consoles started to dominate in the UK and it no longer made any financial sense for the publisher to release our game. They dropped the bombshell a few days after I delivered the master copy to them.

    Needless to say we were both devastated and saw it as a huge personal failure. It felt like a crushing blow knowing that there would be no reward for all our late nights and sacrificed weekends. We’d given up almost every moment of our free time just to get the project over the line. We were physically and emotionally spent. I remember spiralling into a depression that left me with a huge amount of self doubt about my own abilities as a developer.

    The years passed but the pain of the whole experience didn’t seem to fade for either of us. We both spent the immediate years afterwards focussing only on the negatives from the project. We blamed ourselves when the reality was that even the best Amiga game in the world probably wouldn’t have gotten released that late in the day. Perhaps being twins in this instance didn’t help. It almost felt like we were both feeding off each other’s negativity, caught in an endless feedback loop. Who knows.

    Although we both ended up working in the games industry after graduating, we never again dared make another game together. In fact, we very rarely even spoke about our game, preferring instead to pretend that the whole thing never happened. On the few occasions that we did manage to talk about it we only seemed to focus on the negatives and that only served to erode our confidence further. We never really stopped to think that those negatives were actually things we could learn from. Mistakes that could easily be rectified in future projects.

    I’ll be perfectly honest. We did make mistakes during the development of our game. Lots of them. Some technical. Others related to game design. But there were also a huge number of things we did right. In fact, many of those things were quite innovative for the day.

    For example, we made heavy use of rotoscoping, where we imported video footage of ourselves before drawing over it frame-by-frame to create the final artwork and animation. Our game was also one of the first where the body of each enemy soldier would remain in the background after being killed rather than simply disappearing into thin air. In fact there were lots of cool things to be proud of for two kids just out of high school. It’s just a shame we chose to ignore those positives.

    In fact, it has taken us almost twenty years to really get over it. To look at it from a different perspective and really embrace it for the amazing learning experience it actually was.

    About a year and half ago my brother announced that he didn’t want to live his life knowing that he hadn’t at least tried to make one more game. He’d gotten married, had a kid, held down a good 3D modelling job, and for almost a whole decade had more-or-less forgotten about our game. But something had started to gnaw away at him. He felt there was some unfinished business. Something he had to put right.

    We had a chat about it and it became apparent that we’d learned so much over the years since completing our game. I’d grown immeasurable as a developer, was a manager and team lead, and had even published a book. My brother had gone on to work on several award winning kids games and television commercials, and was a highly skilled 3D modeller and animator.

    For the first time ever we talked in depth about our game and why it didn’t work out. We acknowledged that we’d learned so much since then and that there were factors outside our control that really prevented the game from being released. Basically once we got it all off our chests we were pretty cool about what happened. It was really something we should have done a very long time ago.

    So why am I telling you all this? Well something wonderful happened the other day. Something completely out of the blue. A friend sent me a link to a YouTube video. To my amazement it was a video recording of a level from our old game running on an emulator. It was something I hadn’t seen in a very long time. In fact, it was something I’d deliberately tried to avoid in the past. Of course it all looked terribly clumsy by today’s standards, but there was a spirit captured in the game’s rotoscoped images that I hadn’t noticed before. I was looking at a digital version of my younger self, running around dressed as a soldier; shooting at the screen and enthusiastically falling over when hit. There was an energy there. A real passion for what I was doing. Something that I’d let go of due to one bad experience.

    I don’t want others to make the same mistakes me and my bro made. We could have and should have spent the last few decades churning out all sorts of cool and amazing games together. Looking back – although we never admitted it to each other – I think we both felt like failures and the thought of failing again was simply too much to bear. When I look at what we’ve both achieved individually in our professional careers, it saddens me that we couldn’t shake off our previous bad experience and go on to work together on new game ideas. After all, we’ve had plenty of them over the years.

    So if you’re making your first indie game and things aren’t going how you hoped then don’t give up. While it’s certainly easier to get your game out there these days it’s a completely saturated market and making a living from it isn’t going to be easy. Try to set yourself realistic expectations. It’s unlikely your first game will make you rich or storm to the top of charts. Instead, think of it as the beginning of a fantastic journey. Learn from your mistakes and make your next game even better. Take the positives from everything and most importantly of all, don’t be afraid to fail. I wish someone had given me that advice all those years ago.

    So how’s my brother getting on with his indie game? Has he finished it? Well not quite but he’s almost there. He’s been working on it with a determination and passion that I haven’t seen in him since we were teenagers. He’s even taken the game on the road with him: touring the many indie game expos throughout the country and getting valuable feedback. I’ve even found the time over the past few months to help out and I must admit it’s been great working with him again. In many ways it feels like we’d never stopped, and it makes me wonder all the more why we let such a good thing go to waste for so long.

    To date, the response towards my brother’s game has been extremely encouraging. Of course, he’d love for it to be a financial success, but right now he’s being realistic. His primary goal is to create a game he can be proud of and that people will enjoy playing. From the significant time I’ve spent playing it, I firmly believe he’s going to achieve that.

    You can follow the development of his game, Dare the Monkey, on his own personal development blog. Also please follow him on Twitter at @darethemonkey. I know he’d really appreciate your support.

    Thanks for reading.