I had no idea what to expect at my first game jam, and I was nervous about whether I'd be able to participate. I'm a programmer, but I'd never written a videogame, and I don't even much play videogames.
As it turned out, everyone was really friendly and welcoming and I was able to get totally stuck in. But there were a few things that I didn't know that everyone else seemed to know, and I was too shy to admit I didn't know too. Now, following my new and brilliant strategy of "ask as many questions as you can, the stupider the better" (more on that in a later post), I have managed to learn some of these things, and I'll share them here. They are the game engine, game mechanics, and a little bit about art.
When writing video games, people talk about the "engine". For example, "What engine are you using?" and "Don't write your own engine; this is not 'engine jam' ".
A game engine is something that handles the nuts and bolts of a game for you, which basically comes down to displaying the graphics, dealing with input (keyobard, joystick etc), and handling collisions. For example, in a game, when your player runs into a baddie you might want them to bounce off each other at an equal pace. Using a game engine means you can just specify the details of the collision. Not using a game engine means you have to write code to describe the angles and velocities yourself.
Unity is a game engine that handles all this stuff for you. You can copy your art into the folder structure and then drag and drop it to where you want it to be. Game objects have default collision behaviour and you can just write a script to change it.
Flixel is another game engine. It's a level below Unity – there's no graphical user interface, and you have to do a bit more work with the graphics, but the collisions, keyboard input and various other features are there for you.
I didn't understand at the time why my second game jam was so much harder than my first, but when I explained what we did to the brilliant Joe Halliwell afterwards, it all became clear. We disobeyed the advice. We wrote our own game engine.
To be precise, we used OpenGL, which is a 2D/3D Graphics API written in C. It gives the instructions to the graphics card – you definitely don't want to be doing that yourself – at least not in a 48-hour game jam. The code was written in Python, and for the binding we used PyOpenGL. For the physics we used Box2D. OK, so we didn't exactly write our own game engine from scratch, but we assembled one from various constituent parts.
The alleged reasons were that we didn't know Unity, most of us knew Python (except for me – that added another layer of complexity to the weekend!) and between us we had two Macs, two Linux boxes and one loser running Windows. The real reason is that the brilliant Trevor Fountain loves this stuff and, if it existed, would sign up to 'engine jam' like a shot.
Another phrase I heard a lot and pretended to understand was "game mechanics". To be fair, I thought I did understand it – I thought it was jumping, shooting etc. I was wrong.
Game mechanics are more like constructs of rules. Unlocking an achievement is a game mechanic. Going up a level when you reach a certain number of points is a game mechanic. Dying when you lose 90% of your health bar is a game mechanic. So when someone asks "What are the game mechanics?", they mean something like, what are the gamey things here? What makes this a game, rather than just graphics moving across a screen?
I like this list of potential game mechanics.
While I'm here, just a few words on pixel art vs vector graphics, something else I heard talked about which added to the background radiation of feeling I didn't quite understand what was going on.
There's an extremely detailed article on the differences here but in very brief summary – technically speaking, pixel (aka bitmap, raster) art is basically dot-matrix, i.e. made up of pixels individually coloured, and vector art is created using mathematical functions and is basically points and the lines joining them. The art for your game may be either, or some combination of the two. A brief rule of thumb is that old games tend to use pixel art, but the choice is up to you – different tools for different times.
However, it's more than just the technical differences, and the conversations you hear about pixel vs vector art will probably reflect something other than the strict technical distinction. Trevor summed it up for me very clearly, so here is an edited version of what he said:
"To me, pixel art is more of an aesthetic choice than a technical term. It's true that older games had a pixel art aesthetic, especially on 8- or 16-bit platforms. Today, though, I think people use the terms 'pixel art' and 'retro' more or less interchangeably – games like Canabalt or The Last Rocket are undeniably retro, and use the pixel art style to great effect. Games like Angry Birds are rendered using the same technology (2d sprites), yet no one would ever say that Angry Birds qualified as pixel art.
"As for vector art, true vector images (e.g. svg) are rarely used outwith UI design and Flash."
How to Make Your First Videogame by the excellent v21 is great, and the short video You Can Make Video Games is fab and really worth watching. Or why not just sign up to the next Global Game Jam?
Enjoy!
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list: