With the proliferation of digital companies and growth of content material supply platforms like YouTube and Twitch, it’s by no means been simpler for budding content material creators to shoot, edit, and publish movies on-line.
I’ve been creating and publishing movies on YouTube for shut to six years now, however it occurred to me that regardless of having printed a number of hundred movies, I’ve by no means actually mentioned my motivations for doing so, nor the method concerned of their creation.
I’ll get common feedback asking how footage was captured, however the feedback part of a YouTube video actually isn’t conducive to writing any type of information or FAQ, so I believed it is perhaps attention-grabbing to share my experiences with web site readers and different content material creators.
A prologue of kinds
I first acquired a YouTube account again in 2006, however it was used purely to look at content material created by others, quite than entertain the thought of making movies myself.
That modified after I found channels like World of Longplays, C64 Longplays and Recorded Amiga Games (now semi-defunct). These channels had already recorded hundreds of videos dedicated to some of the greatest video games from the history of gaming, and I was fascinated by the dedication and skill that the content creators had taken in creating their ‘longplay’ videos.
Given that I considered myself to be a fan as equally enthusiastic about retro games as these other channels clearly were, I was inspired to dip my toe into the waters of creating retro gaming longplays. It’s a hobby I would continue with for the next 6 years, and eventually lead to my involvement with other retro-related endeavours, such as writing for this very website.
A short disclaimer
Before proceeding further, it’s worth noting that I’m by no means a video editing expert – the following information is based on my own experiments and observations over the last few years, but if anyone has recommendations, corrections, or believes the information I’ve included here is wrong or factually incorrect, please feel to make corrections and suggestions in the comments!
I should also point out that I’m predominantly Windows PC user, so the capture tools, emulators and software mentioned in the article are very much from a PC perspective, so my apologies ahead of time to Mac and Linux users!
What exactly is a ‘Longplay’?
In its broadest sense, a longplay is a video recording that captures the game from beginning to end, generally showing as much content as possible. Wikipedia actually has a short page dedicated to the subject, and I think the description contained therein is pretty spot-on.
Obviously, there are limits as to how far you can go when creating such videos. Each game has its own unique set of mechanics, rules and content, so it’s virtually impossible to capture every possible aspect of a game, but the goal should always be to try and capture – document, even – as complete an experience as possible.
This doesn’t mean that a game has to show every nook, cranny and general minutiae, but if a game is known to have secret locations, hidden areas and/or bonus sections, the video should ideally capture some of these. It might not be practicable to record every single location, but for my videos, I generally try and capture something that I believe to be representative of the game.
That’s cool, but why bother?
Computer and video games were a huge part of my childhood, so the process of creating longplays seemed like an opportunity that not only allowed me to revisit some of my favourite games that I played from that time, it gave me the opportunity to share some of my memories with others passionate about the retro gaming scene.
Tacit with this is the fact that old games have a reputation of being absolutely bonkers when it comes to difficulty – anyone can record a few minutes of footage from an emulator and upload it to YouTube, but to actually beat an entire game and capture it on video? That seemed like an interesting challenge!
Even in the relative prime of youth, when our reaction times could be measure in mere nanoseconds, games from 8-bit and 16-bit era could be extraordinarily difficult to beat (some, as I would discover, are down-right impossible), but the longplay is specifically designed to lay to rest the long-standing questions one might have about how a game ended, no matter how disappointing that might turn out to be!
There’s also the matter of quality. I used to watch similar videos published by many different creators, but there were only so many low-quality clips one could suffer – usually with a dirty great Unregistered Hypercam watermark daubed across the top – before deciding to take matters into my own hands.
The final reason – one that’s more significant than simply indulging oneself in rose-tinted nostalgia – is to document and preserve a hugely important part of human culture, and of the evolution of digital media.
Video games aren’t merely a form of entertainment, they’re a hugely influential art form that has long since eclipsed TV and cinema in terms of popularity and revenue, and frequently showcases the incredible talents of artists, programmers and digital content creators. I see no difference in preserving and documenting the history of video games, and the rise and proliferation of services like YouTube, Twitch, even Archive.org, mean that it’s possible to preserve our pixelated past for future generations.
Recording videos – a how-to guide
With the history lesson out of the way, I thought it might be interesting to talk about the process of capturing video footage for your own retro-related projects, including the process involved in recording a longplay. I often get requests from other content creators for permission to use my video footage in their own projects, so I thought it might be interesting to share hints and tips I’ve picked up along the way when it comes to recording game footage, and I’d also love to hear from other creators about their own techniques!
Preparation – what do I need?
In a word, patience! While you might think creating a longplay is simply sitting down and playing the game, the process is often a lot more complicated.
There’s no hard or fast rule as to how long recording a longplay can take, but the rule of thumb is generally three to four times the length of the final video running time (and that’s without taking encoding and post-production activities into consideration).
The type of game is a major factor in how much time and effort a recording is likely to take. Shoot ’em ups, brawlers and arcade titles are generally more simplistic in pure gameplay mechanics, whereas role-playing games and graphical adventures are typically more complex, sprawling affairs, which tend to take far longer to record than other genres.
To that end, it’s definitely worth taking the time familiarise yourself with the subject matter, especially if you’re undertaking a longplay project. I’ll generally spend some time trying to source a guide and/or maps that help break down content in the game ahead of recording, and GameFAQS is a superb resource for many games, especially those released on consoles.
Guides for older and more obscure C64 and Amiga titles might be harder to source, and when there’s no other option I have been known to to resort to creating my own maps to help during the recording process. It’s a process that generally results in a slicker, more polished performance as a result, although creating such things adds considerably to the time required for the project.
Video capture tools
While they might not offer an experience as authentic as the real hardware, there’s no getting away from the fact that emulators provide by far the most convenient method of capturing game footage. The purists out there will probably decry me for saying so, but the accuracy of most emulators is generally good enough for just about any project requiring video footage, and many come with a whole raft of features that make life easier.
I strongly recommend using emulators that support native video recording as standard. The output from emulators with built-in capture support is generally more robust and reliable than other methods of recording, principally because the emulation state and output are kept in sync – emulators generally buffer output frames and commit them to disk in ordely fashion, which means the final output shouldn’t suffer from dropped frames or stutter, something that is difficult to avoid with desktop capture software.
If there’s absolutely no other option than to resort to using desktop capture (and I’ve had to do this on occasion), make sure you’ve closed all CPU-intensive tasks before commencing recording, and remember to close down or mute any program likely to play audio – the last thing you want is the sound of an incoming Skype call ruining your video!
The director’s chair
Much like a director making a movie for cinema, the video should always aim to entertain the audience, even with a longplay. The overall flow of the video is more important than you might think, and wandering around aimlessly or engaging in superfluous activities not only prolongs the video length unnecessarily, the viewer is likely to get bored and tune out.
To prevent this, I’ll generally re-record segments where the pace becomes to sedate – it adds overhead to the recording process, but the end result will look more polished. I also try to avoid too many deaths on camera, mainly because games typically reset the player’s position, returning them to earlier point in the game.
What might be acceptable for a ‘Let’s Play’ video isn’t always a good fit for a longplay, and my view is the audience doesn’t wish to sit through the same section of gameplay over and over again.
Determinism and tool-assisted emulation
It’s not always easy trying to capture that perfect moment on video, but there are things available to lighten the load.
Emulators like Bizhawk feature some particularly sophisticated features – bullet-proof rerecording, speed change and TAS studio – designed for hardcore speed-runners, and these tool-assistance features can help immeasurably when capturing footage.
It might not seem obvious at first, but many games are entirely deterministic, by which I mean that the logic and rule-sets that govern how things behave, especially enemy movement, are both entirely predictable and reproducible.
Certain emulators allow the player to create an input recording of a game session, and because the vast majority of games are deterministic, the game behaves in exactly the same way as it did before when the game state is maintained and the state recording replayed.
Naturally, the player must go to the effort of recording the input/state recording in the first place, but it makes the whole process of exploring a game world faster and more efficient, especially if it’s a game with which you’re less familiar, and the recording files can be played back at a later date and the output video captured to disk.
It’s worth highlighting the slight caveat that, as with so many things, such tools aren’t always perfect. It’s entirely possible for desynchronisations to occur during recording, and it won’t be until the point of playback that the errors present themselves.
It’s also entirely possible to create a state checkpoint at the wrong time, resulting in a scenario where the game becomes unbeatable, and the only option is to start afresh, or at least attempt to replay the game from the point where the mistake was made. I’ve lost track of how many hours I’ve lost to glitches and errors breaking certain recordings (not to mention my own stupid mistakes), rendering several hours of work useless.
When TAS is unavailable
While TAS tools can greatly simplify the recording process, not every emulator has such facilities.
The Commodore Amiga – a machine that’s very close to my heart – is one of the platforms I tend to focus on with my own YouTube channel, but despite having one of the best and most accurate emulators available in the form of WinUAE, it also lacks the kind of assistance tools and features found in other software.
In these circumstances, time needs to be invested in assessing the viability of potential workflows and strategies for how to record footage. It makes no sense in recording swathes of footage, only to find that it can’t be reassembled later, or has glaring visual or audio issues.
I won’t go into too much detail here, but my process for recording Amiga videos involves creating a numbering scheme that allows chunks of recorded footage to be matches to a corresponding save state file. It’s an entirely manual (not to mention laborious) process, but it’s one that has proven to be reliable, helping me to re-record footage if something went wrong, or if I have to try and work around crashes and Guru Meditation issues.
When it comes to certain platforms, such as old MS-DOS and Windows PC games, there’s no other option but to play the games and record as you go.
Recording these games is certainly the most challenging, due mainly to the amount of time involved in working out a viable recording strategy, and also because the games are typically far larger and more complex than older Amiga and C64 games.
Although PC games generally include in-built save facilities, relying too heavily on such features can really detract from the flow of the video. Having the save menu popping up constantly and interrupting the action is likely to lose the interest of the viewer, so it becomes necessary to work out when and where natural breaks can occur in the video and saving at points where it’s likely to be less intrusive.
For those looking to record MS-DOS games, the Daum SVN build is the one that I personally use. It has built-in video recording support, plus support for the Gravis Ultrasound, Roland MT-32, plus various options that make it easier to configure for a recording session. While it does have save state support, but it’s a feature that’s far from stable, so using the game’s native method of saving is usually the preferred option.
Capturing footage – codecs & compression
The quality of the final video will only ever be as good as the source recording, so you’ll want to use a fast, lossless compression codec wherever possible for capturing raw footage.
It’s possible to record raw, uncompressed frames from most emulators that support video output, but this will eat through disk space at a rapid pace, regardless of how small the video resolution is.
For emulators that let you choose a video compressor, Lagarith or the TechSmith Screen Capture Codec are great choices. Both of these offer lossless recording at decent file sizes, even when targeting frame-rates of 50 or 60 Hz.
When it comes to capturing C64 footage, certain builds of WinVice (now GTK3Vice) come packaged with FFMPEG as part of the distribution, and the included FFV1 codec provides lossless video capture out of the box.
Try to avoid capturing footage using H.264 or other heavily compressed codecs whenever possible; the quality of the final footage is unlikely to be worse than using a lossless codec, plus editing and transcoding footage will take longer, plus there’s greater chance of visual degradation and colour-space conversion issues affecting the quality of the final video.
As far as audio is concerned, there’s little reason to use a compression codec. Even at 48000 khz, the size of raw PCM is unlikely to consume much in the way of disk space, and VirtualDub (my editor of choice) can’t display an audio graph for compressed audio anyway, so it’s generally best to stick with PCM wherever possible.
So you’ve got a hard drive full of video footage, but this needs to be assembled and edited before uploading to platforms like YouTube.
A lot of people think you need an expensive, non-linear video editing package like Adobe Premiere or Sony Vegas to get the best possible results, but that’s not the case.
If all you’re looking to produce is a video that uses raw gameplay footage – like a longplay – then VirtualDub is all you need; it might not provide the kind of convenience and quality-of-life features found in non-linear editors, but Avery Lee’s editor is a fantastic piece of software, and I’ve used it to help create just about every video I’ve produced.
This is the perfect opportunity to remove lengthy loading times and unwanted segments from the video, as well as tidying up presentation in preparation for final encoding.
Cropping video & presentation
One of the most annoying thing about editing together footage from certain retro systems, particularly the C64 and Amiga, is that developers rarely stick to using the machine’s standard resolutions or screen modes. Developers for these machines loved to display graphics in the border areas using various overscan tricks, and the visible screen space used for the actual game can vary wildly between sections of the same game, not to mention between different titles.
The final presentation of a video is entirely your choice, but my personal preference is to try and crop away as much wasted screen space and black borders as possible. This results in video content that flows to the edge of the player container when uploaded to YouTube, and helps eliminate unsightly black bars around the edges of your videos.
Of course, this isn’t always possible.
A good number of Amiga titles will use a large, high-resolution image for the title screen, yet the main game appears in a tiny postage-stamp sized view-port (usually off-centre), considerably smaller than the rest of the video.
In some circumstances, it might be acceptable to crop away the other outer edges of these parts of the video to make the size consistent with the main game window, but my preference is to try and preserve as much of the original content as possible, so re-scaling certain segments to fit within the minimum window size can be preferable.
In my recent Turrican II video, the final credits scene displays a high-resolution graphic precisely 640 x 512 pixels (in double line mode), considerably larger than the actual gameplay content (640 x 432 after cropping).
Rather than resorting to cropping or putting up with unsightly black borders, the final sequence was scaled down to fit within the dimensions of the main game window. The nearest neighbour scaling algorithm does a pretty good job of maintaining pixel aspect ratio, certainly acceptable enough for what I wanted to achieve.
In some cases, there’s such a plethora of different resolutions and display modes used in a particular game that there’s no easy way to condense everything into a single, uniform frame size, so you need to exercise best judgement when deciding on suitable presentation.
Improving image quality – upscaling
The problem with capturing footage from such old games is the resolution, which is far, far smaller than the HD and 4K screens that modern audiences use today. Blow up the original 320 x 200 capture from a Sega Genesis or C64 game across a modern 1080p panel, and we’re left with a blurry image, rather as though staring at the game through a sheet of baking parchment.
Fortunately, VirtualDub (and other editing tools) provide filters that can upscale the video footage – create additional pixels – to a desired target resolution, using clever mathematics to calculate and predict what colour each new pixel should be.
Since 2D artwork used in retro games is built from groups of pixels, the nearest neighbour algorithm is perfectly suited to upscaling artwork, provided the proper aspect ratio is maintained.
You can specify pretty much any resolution you like, but the scaler works best when ‘squaring’ the number of pixels in the output render. The final image will be considerably sharper when applying a 2x, 4x, or even 8x upscale, since this maintains the correct pixel aspect ration for the overall image.
I generally apply a 4x upscale to the source content, which results in a rendered video output from which YouTube will typically generate a 1440p or 4K stream. Not only does the final video look cleaner and crisper, the H.264 codec often does a much better job at compressing the video if it can match common pixel groups, reducing the amount of information required per frame.
A word on YouTube encoding quality
When it comes to YouTube, maximising the quality of your source video footage is paramount. The service forcibly re-encode videos you upload to the platform, usually with far more aggressive compression and a lower overall bit-rate than the source file.
While you can’t control YouTube’s compression settings, it is possible to influence which codec the platform will use to render your uploaded video.
Videos with lower resolution – typically 720p and lower – are generally encoded using AVC-1, whereas videos targeting 1080p and above will be encoded using Google’s own VP9 codec.
VP9 offers considerably better overall video quality than AVC, especially for videos with fast-moving scenes and lots of changes in pixels between frames, and there’s considerably less smearing and macro-blocking when comparing AVC and VP9 encodings of the same video.
One of the reasons I’ve started focusing on 1440p and 4K videos recently is YouTube seems to default to VP9 when encoding uploads at those resolutions, and the final video is, more often than not, pretty close to the source footage in terms of quality. Encoding video at these resolutions might take longer, but the end result is certainly worth it if you’re as fanatical about image quality as I am.
For the final render, the lossless recording needs to be transcoded to a compression format and container supported by YouTube.
I’ve used various options over the years, including VirtualDub and FFMPEG, but my current transcoder of choice is the excellent Handbrake.
Essentially a GUI placed over the top of FFMPEG itself, the software is simple to use, supports multiple container formats and codecs, and it won’t cost you a penny! It also supports the ability to pause the encoding process mid-render, which is rather handy if you need to free up CPU resource to focus on other tasks.
Final render – codec choice
In this final section, I’ll run through some of the codec options available in Handbrake, including a brief comparison of encoding quality.
This free and open-source version of the ubiquitous H.264 codec is capable of producing excellent quality video with excellent levels of compression, is compatible with VirtualDub, and comes bundled with Handbrake, FFMPEG, and other encoding software.
In the past, I’ll generally err on the side of caution and encode using a constant rate-factor option 10 with ‘slow’ or ‘very slow’ preset; it’s probably overkill for the source material, but the final quality is easily a match for the lossless codecs, and has far better compression.
The only downside to using x264 is that, being a software encoder, performance is constrained by the speed of your CPU and number of cores available. The quality is usually second-to-none, but it’s by far the slowest option of those listed here.
Intel’s own hardware-based implementation of the H.264 encoder is really quick, far quicker than x264. I did some experiments with the tech several years ago, but the results weren’t great. I’ll admit this was on my relatively old Intel 3770k (which I’m still using), but the aggressive compression settings result in final video quality that’s noticeably worse than x264.
I can’t speak for more recent Intel CPUs, but my advice is to avoid Quick Sync if you’re serious about quality.
Owners of Nvidia GPUs have the option of using NVENC, a hardware-based H.264 encoder that leverages the power of your graphics card to reduce workloads and speed up rendering times.
Despite its speed, NVENC has lagged behind x264 in terms of quality, although things have improved considerably with the latest Turing series of GPUs. I’ve been using one of these cards to help render my latest QHD and 4K videos, and not only is it considerably quicker than relying on my ageing CPU alone, the video quality is really impressive.
That’s a wrap!
I’m sure this article might seem like something of a ramble, but hopefully some of it was interesting, and it might prove useful to readers looking to maximise the quality of video footage for their own projects.
If anyone has thoughts and feedback on any of the topics discussed here, then be sure to leave a comment below, or feel free to contact me via Twitter!