The adventures of Frank and Dale, in World War II Normandy.
An Australian machinima series by the team from A Walk in the Black Forest, using the Company of Heroes game engine.

The Frank and Dale FAQ

How is each episode put together?

First a script is written, which includes the dialog and the action. Some, but not much, regard is given to what can be done inside the game engine, but the most important thing is to get the story and dialog correct.

Once the script is written, the cast get together and record the dialog, which is then edited and mastered as a final dialog track.

The action is then blocked and recorded from the PC monitor, direct to a standard MiniDV camera. Anything which cannot be shot inside the engine, is usually implied later using a sound effect cut away from the actual action.

In the video editor, the episode template (containing the opening and closing credits) is loaded, the mastered dialog imported, and then the video imported. The video is then plotted against the audio, and both are adjusted for comedic and dramatic timing purposes.

Then the mouths are drawn (unlike Halo, which never shows the characters' faces). Screen shots of each character's head are made from the various angles in the episode, imported into Photoshop, and redrawn with the mouth open. These are then imported back into the editor, and placed over every mouth opening phoneme.

Any special sound effects are then imported and mixed against the dialog levels. Then all the sound is panned for correct stereo positioning.

The completed episode is then exported to QuickTime 7 H.264 in high and low quality. The high quality version is then imported with iTunes to convert it to an iPod supported encoding, and into AVI via FFMPEG so that the Windows Media Encoder can convert it to Windows Media Video 9. Then all but the AVI are uploaded to the site.

What about the animation?

We don't do any animation. Everything you see on screen, with the exception of the characters' mouths, is from the game.

Who does all this work?

Richard BF, a radio and stage comedian. He does all the writing and production. The cast also contribute last minute changes to the dialog, if something better comes up during the recording of the dialog.

How come the mouths look so unrealistic?

Richard's not a graphic artist. When there's a lot of dialog, he tends to spend more time perfecting the mouths. When there's less, he tends to reuse an old one, or put one together more quickly. But you know it's fake anyway right, so who cares?

Who does all the voices?

A whole bunch of people.

Character	Introduced	Actor
Frank	Episode 1	Richard BF
Dale	Episode 1	Abe Killian
Kev	Episode 2	Peter Bryant
Fear/Cecil	Episode 3	Peter Bryant
Chester	Episode 5	Peter Bryant
Terry	Episode 7	Louise McManus
Jase	Episode 7	Jonathan Briden
Otto	Episode 8	Richard BF
Henrik	Episode 8	Peter Bryant

What's this game engine you keep mentioning?

Company of Heroes. It's a PC real time strategy game by THQ/Relic. You can buy it yourself if you like. It's a good game.

Why is the colour slightly different to the game?

The game video is recorded on a domestic PAL MiniDV camera, which is then imported into the video editor. Some colour loss occurs as part of this process, and it would be worse if we used NTSC.

How do you control more than one character on the single player maps?

We only ever play in single player mode. Unlike a lot of machinima, where each character is controlled by a different player, we have one person (yes, it's Richard), who controls the blocking for all the characters in the game.

How do you turn off the game so you can take your time blocking and shooting?

We don't turn off the game at all. In order to not have a time limit, we start a game with the Annihilate win condition, and not Victory Point Control. We then select a single CPU opponent set to Easy, on the Alliled or Axis side, the opposite of the side the characters for the scene are on. So for Otto and Henrik, we play a game as the Axis, against the Allies. We then play the game all the way through, until the enemy has no sectors, no units, and just one non-unit producing building left. This way the game never ends, and the enemy never collect any resources, and thus never build any units.

We then kill off most of our remaining units, by placing them under artillery or mortar fire. This gives us enough unit space to produce the main characters for scene. Special care is needed to make sure they have the same unit upgrades as previous episodes. Units which come as a squad, need to have the rest of the squad killed off first, again by either artillery or motar fire.

The game is then in a state whether we can play around with the characters.

One of the main problems with this, and the engine itself, is that we can never see characters from either side in the same shot. To do this would require a networked game, with a real person controlling either side, ala Halo machinima. Additionally, Company of Heroes always automatically engages nearby enemies, meaning that they can never get close enough to interact, else the engine will kick in and they'll start shooting at each other.

Why is the shooting style so untypical of standard film/TV?

In the first few episodes, we didn't know how to remove all the game artefacts (icons, symbols, counters etc.) from the screen, and there are a lot of them, so we had to very carefully position the characters for each scene. This restricted us a lot in what we could do, with many of the scenes having to be shot from slightly above the action.

In later episodes, we figured out how to remove most of the artefacts, but there are still some restrictions, as follows.

While we shoot the entire screen to video at (1024x768), this gets down rezed to PAL DV (720x576), and then only a portion of this is used in the final movie file (480x270). It is difficult to predict how much of a particular shot we can use because it is difficult to know where the frame is without zooming, which makes it look very "jaggy" and "zoomed" due to the PC graphics limitations. The quite lengthy workflow required to get this acceptable, limits how pedantic we can be about our shots.

Not all the artefacts can be removed from the game. Each game sector has a flag which must be captured, and this is always visible, fluttering in the wind with either a U.S. star or a Nazi swastika, depending on what team the characters are on. Thus it can look strange being in supposed enemy territory, when there's a bunch of your home team flags waving all around you. We have a number of techniques for working around this problem, including framing which excludes the flag (yet sometimes includes the flag pole) and high camera angles. The ground mountings for the flags also look a little out of context, but aren't so much of a problem when shot from a distance.

Close ups are very difficult. The in game characters tend to only want to face in a limited number of directions, and only at certain unpredictable locations and distances from one another. This is difficult enough when you're trying to place two or more characters in certain positions, even more so when trying to get them into special positions and work around the aforementioned sector flags and game artefacts.

Moving characters around, involves selecting them in the game (this artefact can be removed), and repositioning them with the mouse. Both the mouse, a large green circle where the character is moving to, and a bunch of large yellow arrows which indicate the direction the character will end up facing, restrict how much movement we can actually show. In the time it takes to choose a new position for a character, it takes a few seconds (and quite a few attempts) to move the mouse pointer out of shot, and several seconds for the green and yellow symbols to fade in and out. We obviously can't use any of this initial footage, so our cuts are usually mid-action.

A good example of this problem is where a character suddenly starts running off in another direction. There are two main solutions to this. The first is by positioning the camera at an angle where a distant and out of shot location can be clicked on as the destination, where the character is guaranteed to run towards it via where the character is supposed to be running according to the script. The second is by cutting away to another character or establishing shot, and then cutting back to the action once the run has started and the green and yellow symbols have faded out.

We have a couple of other tricks we use as well, to make it look like action has been initiated by a character, when in fact they've been doing the action for quite a few seconds already.

In the case of the bridge exploding in episode 9, the bridge cannot be detonated without all the game artefacts being displayed, and it is impossible to have the entire bridge in shot without seeing at least a few game artefacts. See if you can figure out how we worked around this problem.

Each character in the game has a predefined set of movements which it cycles through at random intervals when idle. For example, when Dale is just standing and not moving, his body movements may include standing up, squatting down, turning to face various directions within about a 30 degree angle, raising his grease gun (M3) to check the sights, and putting it back down again, putting his left foot or right foot forward, or a combination of all of these. Consider the continuity issues when we're using various cut away angles to cover up game artefacts and positioning problems, and then having to make sure the idle body movements are matching the ongoing continuity. If you watch an episode where two characters are shown continuously but from different angles, such as in episode 8, you'll see that they are in fact in sync.

There are also other minor restrictions on the camera angles and movement of characters, which we may document at a later date. The above has probably stunned you enough at this point, and made it obvious why we're the only ones doing regular machinima with this game engine.

All up, it may look to a trained DOP, that the shot composition is very amateurish. It may very well be, but much of that is due to the above restrictions of the game engine, which was not designed for machinima. If Relic/THQ start to improve the engine with some machinima capability, we'll be able to use a more traditional shooting style.

Why are the 3D models so basic looking?

Our production PC isn't very fast, so we've had to reduce the resolution and quality of the 3D models, and turn off a lot of effects like shadows, texturing, water effects etc. If you have a more powerful PC, then Company of Heroes will definitely take advantage of it, and will look at least a degree of magnitude better than it does on Frank and Dale. We chose to do it this way because the story is the most important thing, and while better modeling would be great, it would still be obvious that it was shot inside a game.

On the other hand, if you'd like to donate hardware, or money to buy new hardware, then please let us know!

I could have sworn Henrik's gun floated in mid air!

Well you've got us there. We've also noticed that some of the models do have some strange side effects. We're not sure whether they're due to our low 3D model settings, or whether they're bugs in the game when doing really close up models. You'll have to ask Relic/THQ.

Have the Relic/THQ guys seen Frank and Dale?

Yes. We've had some comments from people on the Company of Heroes team, but only in an unofficial and not part of the company kind of way.

We've not had any official contact with them, although we did email them when we started the first season, just to let them know, and to make sure we covered any legal issues. We never heard back from them. We've been assuming that's their unofficial approval to continue.

Why machinima? Why not some other medium?

We have a background in scripted and improvised radio and stage comedy, audio and video production, story telling, and video based anthropomorphic comedy. Oh, and we're not very good graphic artists. We had the idea for the series already, and when we looked at how to produce it, machinima seemed like the best solution.

What's "A Walk in the Black Forest"?

A Walk in the Black Forest is an improvised comedy radio show that has been on public radio since 1994, and they provide the voices for the main characters, Frank, Dale and Kev. Frank and Dale is a production of the A Walk in the Black Forest comedy team.

Aren't Frank and Dale just a copy of Red vs. Blue?

Sure. As much as Red vs. Blue is a copy of any other comedy act. We're both machinima, and follow typical, yet different, comedy formulas. In fact, the relationship between Frank and Dale has more in common with the status transactions of comedy duos such as Abbot and Costello, Martin and Lewis, Morecambe and Wise etc., than the trios and more common status equality of Red vs. Blue.

Are you fans of Red vs. Blue?

Of course! We first came across Red vs. Blue around episode 5 or so, and then continued to watch up until the middle of the second series. It helped inspire Frank and Dale.

We're a bit sick of both Red vs. Blue being a synonym for machinima, and the dictatorial editors of the machinima articles on Wikipedia and other machinima aggregators, being myopic Red vs. Blue fans. But that's no fault of Red vs. Blue, and we certainly don't begrudge their success.

What are the legal copyright issues with machinima?

We don't know, and there's never been a test case. All the 3D models in Frank and Dale are owned by Relic/THQ, so in theory, we're using their intellectual property. We've not gotten a response to our emails trying to do the right thing by them, so technically we're copying their work without their permission.

While we're helping to promote the game and build up their fan base, and after all, we're fans ourselves, this still doesn't give us a legal right to use their game.

This whole issue needs to be tested at some point, but with the success and publicity potential of machinima such as Red vs. Blue, The Adventures of Bill & John, and the large number of Halo and World of Warcraft machinima, no company seems to want to take the first step toward a test case.