Building a Parallax Scroller with Pixi.js: Part 2

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.

Continue Reading

Building a Parallax Scroller with Pixi.js: Part 1

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.

Continue Reading

Adobe AIR Flappy Bird Clone

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.

Lessons From Long Lost Amiga Game

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.

Flappy Bird HTML5 Tutorial Series

If you’ve been following this blog then you’ll know that I’ve been writing a tutorial series for Adobe’s official Animate CC blog. The tutorials teach you how to write an HTML5 Flappy Bird clone from scratch using Adobe Animate CC and JavaScript.

I’ve got two remaining parts to write but the first four in the series are now available on Adobe’s blog. The first two cover the creation of the artwork, while parts three and four get you up and running with JavaScript. Here are the links to each part.

  1. Part 1: Building a HTML5 Flappy Bird Game Clone with Adobe Animate CC
  2. Part 2: Building a HTML5 Flappy Bird Game Clone with Adobe Animate CC
  3. Part 3: Building a HTML5 Flappy Bird Game Clone with Adobe Animate CC
  4. Part 4: Building a HTML5 Flappy Bird Game Clone with Adobe Animate CC

It’s been good fun working on this and hopefully you guys will enjoy the final two parts that will be available soon.

Flappy Bird HTML5 Clone

One of the things I’ve always loved about Flash Professional and ActionScript is just how easy it is to knock together a quick web game. Flash’s design-develop workflow always made such things a breeze. But what about HTML5? Could I use Adobe Animate CC (formerly Flash Pro) and JavaScript to create a game just as easily? Well it turns out you can, and the workflow isn’t really that much different. I spent a few weekends building a Flappy Bird clone that you can try below.

If you’d like to know more, I’m currently writing a tutorial series for Adobe’s official Animate CC blog. The first two parts will take you through the steps required to create the game’s artwork, while the remaining parts will show you how to code the game and add the audio. Part one has just gone live so please take a look and let me know what you think.

Also, if you can’t wait, then feel free to head on over to GitHub and grab the game’s source code and .fla file.

Minimum Lovable Product

Recently I had the pleasure of spending the day with George Berkowski, the founder of IceCream and author of How to Build a Billion Dollar App. Most of the time was spent discussing app design and, in particular, what features would make first release for the latest app the team was working on.

At some point the term “minimum viable product” (MVP) started getting banded around as we struggled to decide which features to keep and which to drop. George however was very quick to interrupt. In his experience it was a dangerous term to be using and would only foster a mindset that would inevitably result in the production of a very poor product.

Instead, George insisted on the team thinking in terms of a “minimum lovable product” (MLP): What were the minimum features required for first release to make users fall in love with our product?

I’ll be honest, I’d never heard of the phrase “minimum lovable product” before but it really struck a chord with me. George was right. Almost all of us had worked on projects in the past where MVP had been the mantra. In fact, I’ve worked on several projects in the past where management even moved away from the term MVP and instead started asking for “the thinnest mint”.

All of these projects started life as very good ideas but ended up being stripped of almost everything that would make them engaging or fun for the users. I’ve seen amazingly talented people become completely demotivated churning out MVP after MVP, knowing that what they were being asked to deliver was never going to resonate with the end user. Many of you may ask, isn’t MVP and MLP the same thing? I guess in many ways it is, but more often than not, people take Minimum too literally and end up sacrificing the design and scope of a product.

Software development can be challenging. There are delivery deadlines and budget constraints to meet. For small development studios this ultimately means that it’s not going to be possible to deliver every feature they’d like for first release. But rather than build something a large number of users might like, it’s much better to build something that a small number of users will love. An MLP is more likely to gain a following and generate enough revenue to help you grow the product over time. From my own experience, an MVP almost never will.

It was really great working with George and I learned a lot from him. If you’ve got the time, spend some time watching the video from his TEDx talk above. I think you’ll learn something too. Also, if you’d like to know more about MLP then take a read of this article.

Star Wars DeLorean Time Machine

Yeah you read the title of this post correctly. At the tail end of last year I received an urgent holographic transmission* from screenwriter and best selling novelist Ernie Cline looking for some help with his latest project. Both Ernie and his brother Eric are proud owners of DeLorean DMC-12’s (that’s right, the car from Back to the Future) and were in the process of converting one into the very first Star Wars Time Machine complete with R2-D2. How awesome is that!

So where do I fit into this? Well their Star Wars DeLorean was pretty close to perfect but the guys felt there was one thing missing. That’s right, a targeting computer. Ernie somehow found out about my X-wing Targeting Computer app and thought he’d get in touch to see if there was any way I could help out. The app isn’t available in the App Store but I was able to get a build put together for him to install on his iPhone. So now both Ernie and Eric can drive around in the coolest car in the universe knowing they can take on the Empire any time.

Check out the videos above. The first shows my targeting computer hooked up to the DeLorean while the second shows R2-D2 chirping and beeping away in the back. A huge thank you to both Ernie and Eric for letting me be a small part of their amazing project. Thanks to them my app has finally found a home.

You can find more detail about the Star Wars car on its official blog. May the Force be with you. Always.

* may be an exaggeration on my part.

Dare the Monkey

If you’ve been following this blog from the beginning then you may remember a game I started working on called Croc & Dare. It was a collaborative effort between myself and talented illustrator, Steve Koren. Unfortunately neither of us could find the time to get it beyond the early concept stages and as the years have passed it has been largely forgotten by us both.

My brother however always thought that the game’s little monkey hero was a pretty cool character and decided to make his own indie game inspired by Dare. He’s actually been working on his game for approximately a year now and recently started a blog to document the remainder of the development process. The game itself has changed radically from the original concept and Dare himself has also changed quite a bit.

My brother’s a professional 3D modeller and animator, and his mad skills have enabled him to build a visually stunning world for Dare and the game’s other inhabitants. Take a look at the video above to see how one of the game’s earlier levels looks. He’s using Buildbox to actually build the game and I must admit I’m amazed by the actual mileage he’s getting out of this game maker tool.

He’s planning to release Dare the Monkey on iOS initially and is aiming to submit it to the App Store later this year. If you want to know more about Dare the Monkey then please check out his blog. He also Tweets as @darethemonkey where you can follow the game’s development.

It’s great to see something come out of the original game idea. Can’t wait for it’s release!

Object-Oriented Programming with Swift 2

The nice folk at Packt publishing sent me over a couple of iOS books recently to have a look over so I thought I’d write a review of each one for you guys. Today I’ll cover the first of the two books that I read: Object-Oriented Programming with Swift 2 by Gaston C Hillar.


The book isn’t aimed at newcomers to programming. You’ll need to know at least one other object-oriented language in order to get the most from it. That can be just about any language such as Objective-C, C++, Java, or ActionScript. Oddly however, Gaston does spend a decent amount of time explaining the basic principles and concepts of object-oriented programming, which most developers will already know. However, for reasons of completeness, it’s probably a necessary step.

As for the quality of the material, it’s mostly excellent. The majority of the chapters will have you using the Xcode Playground to work with code rather than muddy the water by having you try to write an actual app. The Playground is an ideal way to learn and will ensure that you are focussed on the Swift language at this point.

Everything you’d expect the author to cover is there plus a little bit more. One of the later chapters delves into Swift’s functional programming features, while the final chapter has you build a very simple native app to help introduce you to iOS development with Xcode. There was also a very good chapter covering generics and the book also does a good job of explaining protocols to those who aren’t familiar with them.

While I’d already consider myself more than comfortable with Swift I did pick up the occasional trick or two from the author. If you’re already an experienced Objective-C programmer and you want to learn Swift then this book is ideal. It’s also perfect for most people who know another object-oriented programming language and want to familiarise themselves with Swift.

While it’s certainly not as comprehensive as Apple’s own Swift 2 Language Guide, Object-Oriented Programming with Swift 2 does provide some focus allowing most developers to get to grips with the majority of the language relatively quickly.

A well written and enjoyable book.