GameMakersToolkit
patreon
How I make Developing
🕑 Added 2021-12-14 12:00:00 +0000 UTCHello!
So my new series, Developing, is quite different from traditional GMTK episodes. It’s more of a personal story than a richly researched analysis piece. And also - you can see my face!
So in this behind the scenes post I want to talk about how I make episodes of this show, going through the concept, technology, set-up, and process that I’m using to get the series done.
Finding the story
Perhaps the most important part of Developing is figuring out what story I want to tell in each episode.
When I was first conceiving of the series, I knew that I didn’t want to make a typical devlog where I just show off what I’ve coded that month. Don’t get me wrong: I love devlogs on YouTube and watch a bunch of them, but that’s not what I wanted to make.
Instead, each episode should tell a self-contained story - showing the trials and tribulations of this novice game dev.
Now with the first two episodes I knew what the story would be about beforehand. But starting with episode 3, I had no idea. I mean, part of this process is me learning how game development works - so I don’t know what challenges I’ll face, what steps I’ll take, etc.
At this point it’s about trying to distill what happened into the most interesting narrative possible. A lot happened since episode 2, but what was the most important, most interesting, most impactful bit? Turns out: my painful indecision over genre and direction. So I can show my confusion, and then show a solution.
Next episode, there’s a different type of narrative. It’s about heightening the stakes. Do I meet the challenge of 5 levels in 30 days? Or do I fail? Maybe other stories will emerge in future episodes.
So far, interesting things have continually happened in the project so I haven’t exactly struggled to find seeds for storytelling. But we’ll see how things go as the project goes on!
I also want the series to have tangible, takeaway lessons. Like making tiny clones to learn game engines, or the importance of prototyping mechanics, or the power of the “game jam mindset”. Can others learn from my story? Part of that is showing exactly what happens if you do this “wrong”, which can be painful and embarrassing. But I think it makes for a better show.
Another important thing for me to do is to take notes. To keep a little diary of what I’m thinking as the game goes on. It’s very easy to forget the actual feelings and experiences, as time goes on. Hindsight and nostalgia have a nasty habit of wiping out our negative memories. So I jot them down to help put me back in that mindset.
Gathering the footage
As I work on the game, I regularly take little videos of what I’ve been working on. I share a lot of them in the GMTK Discord, but their main purpose is to end up in the video. I also sometimes record my screen while I’m working, but I can’t capture every moment - it would be hundreds of hours of footage for each episode!
Sometimes, after the fact, I’ll realise that I want to talk about something but don’t have the perfect shot. For example, in the latest video I forgot to capture footage of the glitch where I get stuck in the one-way platform. So I had to actually intentionally break the code so I could recreate that moment! Now, I keep backups of the project in various states, so I can go back and recreate certain moments more easily.
Now, for GMTK and Boss Keys and the like, I never have much problem knowing what to put on screen. Just chuck on some more gameplay. But for this series I knew there would be long stretches where I’m just talking - talking about general concepts and ideas. And so what am I gonna show on screen in the YouTube video?
Which made me realise that I should probably bite the bullet and get myself on camera. That will help fill the gaps - plus, it fulfils another goal of the series. To be more personable, conversational, and down-to-earth. This isn’t the booming voice of a British man telling you lessons of game design. This is a real dude, having an existential crisis about magnets. Relatable!
Now, this all took me a long time to get right. With GMTK, I’ve got pretty good production values at this point. But that’s not too hard when it’s just video game footage and some motion graphics. But as soon as you point a camera at things, it can instantly go from “professional production” to “dude sat in a poorly lit bedroom talking into an iPhone”.
It was important to me that the on-camera stuff looked as polished, professional, and slick as the off-camera stuff. To achieve this, I started with…
The gear
First up, there’s the camera. Now I still don’t know much about cameras. A couple years back I Googled “what’s the best vlogging camera?” and ended up with a Canon EOS M50, with a kit lens.
Now it’s a damn fine camera, though it’s not without limitations. I release Developing videos in 1440p, so I shoot in 4K, as this allows me to crop in closer to my face without losing any quality. But at 4K, the camera really cuts in close, and it only allows for 24 frames per second. So it’s not perfect. But it works.
As for lights, I use a handful of different ones. I have a giant softbox on a stand, with four LED bulbs screwed in it. This is my main light, for the left side of my face. Which does this...
To my right, I have a ring light, to add a bit more definition.
Above, I just use the normal light bulb in the room, with no shade, to light up my hair.
And behind me, there’s an LED light block to make the background look lovely.
It’s a bit of a crazy combination, but put it all together and I think you get something very nice. It wouldn’t work without all four lights.
Finally, there’s the microphone. I wear a RODE lapel mic, but that’s just for backup and syncing, as I don’t think the quality is good enough. Instead, I have a Shure SM7B just out of shot, pointed at my mouth.
That’s connected to an audio interface, which is connected to an iMac which is also just out of shot. So I record the video on the camera and the audio on the Mac, and then sync them up later in Premiere.
The GMTK Studio
Okay, studio might be overstating it. It’s the spare room in my house. Just out of shot you’ll see a clothes rail, boxes of junk, lost lamps, and a giant crate of orphaned cables. But, it’s what you see through the lens that’s important!
The "studio", mid-way through painting. Also on display: standing desk, soft box light, camera tripod.
Before I started Developing, I painted the walls a nice shade of blue. Actually, I painted two of the walls blue - I couldn’t be bothered to do the walls that are completely out of view from the camera. I also put up a blackout blind on the window and taped around the edges to make the room pitch black. Natural light can be beautiful for video, but this “studio” is designed to look the same all day, all year - so the sun has got to go.
I also put up acoustic foam on some walls to remove echo and other nasty sound bleeding. But the room is so full of junk that it’s naturally got nice acoustics anyway.
Initially, the idea was to build a sort of set behind me. Maybe some shelves with games and consoles. Or some posters on the wall. But I really struggled to get that gorgeous cinematic shallow depth of field. You know, where the subject is in focus but everything behind is just blobs of colour and light. Sure, with the camera and the kit lens I can get me in focus and the background out of the focus - but it’s not enough. The background elements are still too clear, which makes them distracting, and makes the shot look less professional.
The room isn’t super big, so there’s not a massive distance between the camera and me, and me and the background. But, hey, if you have any recommendations for how to do this I’ll be all ears.
However, that being said, at one point I decided to stop following this thread and, instead, simply lean into the blue background. Because, hey, that’s a pretty nice plain colour which is easy to mask out (using a colour key, like the green and blue screens in movies), so I can put text, images, videos, and graphics behind me in the final video. I also put in a subtle moving background image of little animated lights, to add movement and texture.
Recording
With all my other videos, I step into my recording booth, prop up my iPad with the script on it, and babble those exact words into a microphone. Done! For Developing, I don’t have that luxury. I need to be talking to camera and gesticulating like a loon.
Now, sure - teleprompters exist. Or I could just staple my iPad to the wall behind the camera. But still, in line with my goal to be conversational and relatable, I don’t want to read a script. I want to just talk!
So, instead, I tackle it more like one of my talks than one of my videos. I plan out what I want to say - using Keynote to split all my points into separate slides - and then I just practice the hell out of it. I say the entire video in my head while I’m running, or driving. I keep saying it until I can say the whole video without reading. I then record myself saying it… and then record it all again because, boy, everything’s better the second time around.
In terms of the recording process, there’s just a few little quirks that make it different to voice over. For example, for Developing episode 3 I recorded the whole thing, slammed the SD card in my computer, aaaaand… the whole thing was slightly out of focus. Whoops. Take three!
I also have to think about… my appearance. This is kind of a weird thing for me to have to consider. But it’s a thing! I have to line up my hair cut with video recording. And I even have to think about what I’m going to wear! Can’t be too blue, or it will spoil the colour key. All a bit strange, but it’s a necessity.
Editing
Once I’ve done the video, I drop it into Premiere, sync up the audio, cut out any mistakes. And… wow!
You see, normally, with GMTK, I drop in my recorded voice and I’m left with a completely black screen for the duration of the video. So I have to fill in every single second with something - gameplay, motion graphics, etc. But with Developing, right from the word go, the entire thing has video.
So it’s just a case of putting in stuff where I think it will add. I still want to put in a lot, to keep the video engaging and provide lots of visual examples. But I don’t have to fill every single second, and that’s really nice.
Most of the editing is pretty standard stuff: gameplay and recordings from Unity. But I do some other things too.
For example, something I need to do in this series is explain things that are quite vague and conceptual. For this, I use a simple iPad drawing app called Paper, and an Apple Pencil. I use the iPad’s built-in screen recorder to record myself drawing out scribbles and ideas and shapes and charts. I can then drop them into Premiere and remove the UI and speed things up. It’s the closest thing you can get to hooking a camera up to my brain.
Other bits and bobs
Because I don’t have a script, I can’t easily generate subtitles for these videos. But, accessibility is a key value of GMTK - so no excuses! Luckily, YouTube’s automatic captions system is very good these days so I can save them out and just go through, fixing grammar and small mistakes. It takes a while, but not forever.
Other than that, it’s just the usual nonsense - thumbnails, description, etc.
And so there we have it! I’ve learned a lot about making these sorts of videos already, but I’m sure I have way more to find out. At this point I want to keep things pretty standard for the rest of Developing so all the episodes look like part of the same series. But if I do a second season with another game… maybe I’ll change things up!
Hope you found that interesting. Any questions, lemme know and I’ll do my best to answer them.
Mark
Comments
Will Kommor
This was really insightful, thank you for posting this!! If you find yourself in the "peek behind the curtain" mood again I have something I'm really curious about: how do you go about gathering your normal GMTK game footage? Not in the technical sense of OBS and capture cards and stuff, but more like, do you record footage when you need it to illustrate a point, or do you just amass a library of footage whenever you feel like playing? When recording a game do you feel the need to play through the end of it, or just enough to understand it / have a variety of clips? Do you have a strategy for recording useful content?
David Schleimer
I was going to ask a very similar question. Version Control (VCS), also called Source Control or SCM) is the class of tools software types, including game devs, typically use for "keep backups of the project in various states" as well as taking notes to explain why they made a particular change. EDIT: Another advantage of version control systems is that they typically take up much less space than having the same number of full backup copies. Much, much less space. In addition, most version control systems have concepts used for organizing those backups. Typically called branches and tags. You're likely going to develop similar concepts with your backup naming if and when you release versions of the game. Git is the most widely used version control system, but it's not nearly as popular among game devs, since Git does not handle binary files (referred to as blobs) very well. Game development tends to have a lot of blobs under version control in the form of game assets. Perforce, as I understand it, is the most popular version control system for commercial game development. Unity appears to have support for Perforce and Plastic SCM (which I've never heard of) https://docs.unity3d.com/Manual/Versioncontrolintegration.html I would guess there are third-party Unity plugins available for most of the popular version control systems, including Git. You may find it easier to setup a third-party Version Control plugin than setup up perforce or Plastic SCM. Perforce requires a separate server be running, no idea about Plastic SCM. Git is a so-called Distributed Version Control System (DVCS), which does not require a separate server. Also worth mentioning is Mercurial, which Unity the company at one point used internally and supported (I stopped working on version control and don't know if they still do). Mercurial is a DVCS like git, but is easier to leanr for folks new to version control, and has plugins designed to better handle blobs.
Lionel Nanchen
Hello, about your statement: "Now, I keep backups of the project in various states, so I can go back and recreate certain moments more easily." I don’t know much about Unity and the way professionals handle backups but did you heard of Git (GitHub, Gitlab …) ? It’s a great tool largely used by Dev teams. One of the features it’s that you can commit your work at a certain state and come back to that specific state easily. And it can be easier to use that doing classic backups of your code. I don’t know, maybe Git isn’t the best idea for a game made with Unity but it could possibly be helpful !?
