Yesterday I finally had chance to road-test some of the beginner's game development content I've been writing, running two back-to-back sessions at Stockport Creative Festival.
We had a few hiccups in the lead-up to the day, the biggest one being a last minute change of venue - we were supposed to be running it in Stockport Central Library, which fell through when we realised they had fairly restrictive computer rules (understandably) and no projector (ridiculously). Luckily at the last minute I had an offer from Matt at Drive-By, who had a fantastic space available in Stockport and was more than happy to give us a home for the day. Huge thanks to Matt for saving the day. (Drive-By provide game design/dev and generally ace creative training opportunities for young, unemployed or 'at risk' people. They do a ton of valuable work, check them out).
Each session was a quick three hour workshop slot, which goes incredibly quickly when you factor in any technical/setup issues, stopping to help people, or generally deviating from the script. I decided to adapt a small part of the larger project I'm working on (more on this in a sec), which was a Flappy Bird clone built in Stencyl:
Stencyl is a fantastic program for teaching with - it's a graphical environment that makes total sense to a beginner, allows you to peek at the code underneath when you're feeling braver, and most importantly it's free to use for most things. A few of the attendees had used Scratch before, which I have a lot of love for, but Stencyl is definitely more powerful and tuned for game development. Highly recommend checking it out if you're interested in this kind of work.
I handed out a small folder of images to start with, which formed the sort of empty starting point to work from. We then made a totally empty Stencyl project and pieced it all together in steps. This approach worked really well, and we didn't have to waste any time making images. It's also worth noting that I intentionally used 'proper' graphics taken from Kenney.nl's amazing free game assets work. This made a huge difference in making our simple game look and feel like a real game - developer artwork only takes you so far, and it was nice to have a good-looking game at the end.
The game build itself was fairly simple - a nice background, some infinitely scrolling terrain, a plane with animation, user input handling, and some rudimentary collision detection. Not bad for three hours! The first group I had were a bit younger, and we had some technical issues on a few machines, but we managed to get everything done in the time. The second group were on average a bit older and so a bit more capable (not to mention we'd ironed out the technical kinks for the second session). This group got a lot further, we finished the stuff I'd written in less than two hours, and spent the rest of the time sort of freely adding more stuff to the game. I wasn't really prepared for this, but thought fast and decided to demo how to make new scenes and switch between them, adding a proper 'game over' screen when the plane crashes. This was also a handy chance to get people to fire up Paint and make some of their own graphics, which I felt was quite a fun addition. Some folks even had time to start noodling with audio, which was pretty cool.
Overall I was really happy with how it all turned out - the response from everyone was really good, and I had lots of smiling people excitedly playing their shiny new games. It was also a great chance to road-test the format, and get start to get an idea of how long everything takes.
Since posting a few pics on twitter/Facebook yesterday, I've already had two or three requests to run this in different places - it definitely feels like people are keen on the content, which is encouraging. My bigger objective at the moment is to write and run this as a larger course for Madlab, which I'm much more confident about doing now I've had this chance to do it on a smaller scale.
Ultimately I'd then like to adapt and expand the content into either book format or something similar online. I'm convinced there's a gap in the market for gamedev training that's not tied into single technologies - my work for the game jam continually shows me that beginners are wracked with indecision about picking the right tech, and I'd love to be able to fix that a little by offering a something that will let newbies confidently have fun with lots of difference technologies and ways of thinking. I also think there's a huge gap in games teaching with regard to the slightly less technical side - what makes a game feel nice to play, what makes it fun, how we add challenge - all the fluffy stuff that's just as important.
Thanks a million to everyone who turned out yesterday, and particular thanks to Dan and Matt for helping out on the day. Hugely appreciated, chaps.
Make all the games!