TL;DR
  • You don’t need to be an expert-guru-ninja to do a beginners workshop;
  • Don’t overthink and be ready to improvise;
  • Agile works for workshops as well;
  • WebMuses Rock!
GeekWeek

Back in May, Piotrek Krawiec (currently @ Estimote) and I ran an introductory workshop on writing games in Phaser.js. We did it together with girls from WebMuses as part of the GeekWeek KRK. Recently, I had the pleasure of doing it again for a group of students at AGH. I figured this is the perfect opportunity to tell the story of how we ended up doing the original installment and what we learned in the process.

The ‘oh shit!’ moment

22 2

Being a technology consulting shop involves a lot of education. One might even say that Consulting == Educating. First you need to teach yourself, and then you pass this knowledge (as advice) to your clients.

So, when our friends from WebMuses reached out to us asking if we want to help them with a beginners game dev workshop, we said – “HELL YEAH”. Note that we don’t do a lot of games dev work on the daily basis. We made a few flash games back in the day and one of our clients asks us to do something in Unity3D every now and then, but that’s pretty much it. Most of us, however, do like (or in some cases even love) to play games, so we knew what a game should look like. So, after the initial ecstatic “Fuck Yeah!” moment, came the more quiet, but nevertheless essential in every creative process, ‘oh shit!’ moment.

a) we are no experts at creating games, so how are we going to teach others?
b) what tech do we use?
c) what example do we want to use to make sure we won’t bore people to death?

For a) we decided that there wasn’t much we could do. We have some experience and no shortage of passion and this would hopefully be enough. After all, this whole event is about having fun and learning together so a simple ‘You know what, I have no idea. But email me later and we can figure it out’ should take us pretty far even if questions get too complicated.

Choose wisely

phaser2

When it comes to technology, we used to build games in Flash. But flash is a dying technology, not mobile friendly and not very fun to work with (or at least so we thought). We do some dev work in Unity3D, which is a great piece of engineering that allows you to easily create cross-platform 3D games with cool graphics and effects. It looked really promising, but when we thought about it, Unity has a learning curve not really suitable for a 4 hour workshop. This was the time to look for something outside of our area of expertise. We decided to make a list of requirements for our dream tech of choice:

  • easy to set up
  • reasonably easy to debug
  • have a gradual learning curve
  • use language we are at least familiar with
  • use language the participants might be familiar with
  • is widely adopted, so people can look up tutorials and other resources on their own

That left us with only one contender – Javascript. But, as you may know, there are plenty of JS/HTML5 frameworks out there. In the end we ended up picking PhaserJS, because it seemed friendly, had great examples page and a really cool logo. No, seriously. We could’ve probably chosen any other framework out there and it would also be a blast.

TIP 1: spend as much time as you need choosing your tech. But not more. There is a threshold beyond which the differences will probably be meaningless.

I want to play a game

playagame

Now that we had the tools we knew we could build something. Cool. But what could we build? We decided we wanted a game that would be simple (duh!), fun to play (duh!) and showcase as many game dev concepts as possible. Namely:

  • physics
  • collisions
  • sprites
  • sound effects

Also, making it look and play nice on mobile devices was high on our nice-to-have list. After brainstorming a few ideas we ended up with the perfect candidate. It covered all the basics

defender-ideaTime is money, and we knew that we were left with the time equivalent of small change, so we decided to split our efforts – one of us taking care of the horrible monsters, the other of the mechanism for shooting them. And so we went our separate ways. A week later, when we came back to combine our efforts it turned out that we’d chosen two different physics engines. A simple Arcade system for the enemies, whose main responsibility is not to fall through the ground (the same goes for the castle), charge and finally assault the castle. And a more sophisticated P2 engine for the projectiles, because who doesn’t like friction and fancy rebounds? We ended up using the Arcade system for the workshop just because it was less complicated and still gave us a satisfactory result. We might have lost some time. So we polished the details, came up with our own graphics and the product was ready:

defender-done

TIP 2: Splitting the work allows for exploring very different directions. Just make sure you touch base from time to time to make sure you didn’t wander too far.

Planning is priceless – the plan itself is useless

38

OK, so we had a game that we liked, was cool (a geeky kind of cool but still), fun and simple to write. Now came the time to figure out how we could teach others to do it. Naturally we needed some slides that would give the whole workshop a framework and a boilerplate people could download to get started right away and spend the minimum time on setting up. For the actual workshop we decided to use the Cloud9 cloud based IDE. Why, you might ask? Well, first of all with everyone using the same IDE it’s likely that people encounter common problems that will be easy to solve. You can easily share workspaces, so people can compare the code they write with yours and find bugs on their own.  Finally it’s completely OS independent and easy to set up by cloning a github repo. What we didn’t consider is that C9 might become slightly unstable when 20 people are watching a single file, so we did run into our fair share of issues there. In the end it was still a good decision, but not without its disadvantages.

TIP 3: Web based IDE’s are treacherous and it gets worse with a growing number of participants.

Agile(ish)

18

Then we made a few crucial decisions that (probably more than anything else) contributed to the success of the whole enterprise.

In the ever present spirit of Agile (which we use daily), we divided the game into incremental steps, building one feature at a time, having something to test and show at the end of each stage. This prevented people from being discouraged, and guaranteed that they would take something home that works even if not the complete game. The last part also made us more at ease, as it meant that even if we misjudged how much our participants would be able to do in those 4 hours there would still be a chance they would leave feeling that they had learned and accomplished something. To prepare even better for this scenario we divided the steps into plan minimum and the extras. Doing everything would be great – getting the minimum done would be fine.

Now the next crucial thing was to make all the slides and the code public including the extras. This worked well for people who were working fast and wanted to do more. For those who found the pace more challenging it gave them the ability to work at their own pace.

Behind the scenes

39

Finally, to help with all the problems that inevitably come during events like this we had one guy with us, who knew the code and the IDE and whose sole responsibility was to help those in need. Without him, implementing a “no geek left behind” policy wouldn’t be possible.

Speaking of making things possible, we would like to thank WebMuses for organizing these workshops and pulling us in. They took care of securing and preparing the venue (thanks Hub:raum!), building the hype around the event, registering participants and last but not least making sure we had pizza:). All we really had to do was show up with something fun to build. Girls, you are the best:*

So much win

5

In the end we enjoyed the whole experience tremendously. And, judging by the feedback we got from the participants, it was an overall success. Working with WebMuses has been blissful and we would love to do something together again. We met some great people and hopefully taught them something about making games. We also learned a lot ourselves:

  • You don’t need to be an expert-guru-ninja to do a beginners workshop
  • Teaching others is an extremely energizing experience! (surprise)
  • Structure your workshop in an agile way and everyone (including you) will enjoy it more
  • Be ready to improvise, especially if you’re using an in-cloud IDE (:

Now go and teach somebody something you are passionate about!

Wanna see more photos? Check them out here!