How to make an iOS game trailer with iMovie, ScreenFlow and the Simulator

Something of a sneak peak in this how-to post for 36peas and the #idevblogaday site... we just finished work on the trailer for our upcoming iPad title Hyperion: d7. It took us about 4 hours (the trailer, that is -- the game took about 4 months), was a lot of fun and actually works pretty well. In this post I'm going to explain how we did it.

I've included technical stuff (how to capture source video, how to get correct compression and import/export settings along the way etc) and direction/design stuff (how to pace the video, how to make it look good).

First off -- you better check out the Hyperion: d7 trailer itself:

This took us 4 hours -- including the time taken to capture the source video in the Simulator (not easy -- the iPad game itself really does need two fingers for effective gameplay) and the time taken to move video around between ScreenFlow and iMovie.

If you're not interested in the video how-to, but do want to know more about Hyperion: d7, skip to the bottom for more details.

What works -- what makes a good-looking video game trailer?

This process pretty much involved watching a lot of other trailers. Primary observations were:

• +/- 60 seconds seems to be an optimal length
• lingering gameplay shots don't work
• menus are dull
• teasing works better than describing
• tempo is critical
• everything hangs on the music

What we decided upon -- our video production rulebook

The details of specifically what we did are in the next section -- these are just the headline paramters for how we guided the process.

• Pacing should be consistent (all cuts the same length)
• We'd make the most out of the game's natural aesthetic (and concentrate on using clips that looked good -- not necessarily ones that we thought "played" good)
• Use the same effects/transitions in similar places
• Break up the action shots (doing so consistently -- again to aid pacing)
• Present some basic information about the game -- but don't worry about detail
• Do not re-invent the wheel

What we did -- step-by-step how-to for making our iPad game trailer

Technical pointers and specifics are in the next section -- skip ahead if you're not interested in the video production bits. If you are interested in the video production stuff, I'd encourage to read both -- there are useful (but non-specific) production pointers in the technical section.

1. Selected the background music we wanted to use -- we had an awesome original score to choose from. Two tracks stood out as obvious candidates.
2. Looked for appropriate 60-second-ish sections from the above tracks and selected one -- it was 63 seconds and had an appropriate open, close and riffy bits. From this point on everything was played back and tested against this music.
3. Decided on how many non-video (text stills) there would be -- we are using these as breaks in the action. We decided on two (plus the closing stills).
4. Picked our transitions (we did this by testing them against some sample captured video -- when using built-in fixed transitions they can look very different on different source material).
5. Decided where the transitions would be used (i.e. video>video; video>text).
6. Picked the text effects (same as the transitions -- try them out).
7. Worked out a good single cut length -- we did this by testing clips between two transitions over the top of the already selected background music. This got us to 4.5s per cut for video and 3s for text stills
8. We then broke down our 63-second timeline into the three sections demarked by text stills and populated the gaps with video cuts, getting us something like the following:
   
    
9. We wrote a list of bullets about the game but didn't dwell on the detail.
10. We wrote a list of things we thought might look interesting (not based on the list from the previous point).
11. We stated recording source video using ScreenFlow (more details below) and the iPad Simulator -- we weren't too worried about capturing the right stuff at this stage, we just follow the list from above.
12. Bringing that video into iMovie, we started to select and trim clips. For most clips we also applied either a single crop or a panning/zooming "Ken Burns" crop (see technical stuff below).
13. Added text from previous bullet list to correlate with what we'd captured (and to some extent what we wanted to say first / in what order).
14. We then repeated this whole process for the second section of clips -- we still weren't stuggling for what to record here (and this was with our tired-after-almost-2-straight-days-of-pre-submission-gameplay-testing eyes).
    
    At this point our source video window is starting to look like we have secret plans for a secret base in a secret spy world where nothing on the secret spy computer screens looks like what you'd see on a real computer screen:
    
    
15. Once we'd got sections 1 and 2 in order, we looked at the list of things we wanted to say and worked out what we'd not yet said -- giving us a requirements list for the last lot of captures.
16. We chose gameplay to match those points (this was the upgrades bit in section 3) -- and spent a little more time than we had on previous captures making sure we got what we wanted.
17. We created a closing title card (we should have done this sooner -- it's the only bit we weren't 100% happy with).
18. Added the final stills (the closing title card and the 36peas logo). At this point, the timeline looked suspiciously familiar:
    
    
19. Watched it end-to-end.
20. Made some text tweaks (nothing significant -- just some modifiers and joining/flow bits)
21. Exported and watched again. And again. And again.

Seriously -- that was the process we went through. We didn't have to go back on ourselves, or figure out why it didn't feel right -- it just did. This is entirely down to the consistent, snappy pacing. The video flows and feels interesting because the tempo is good and there's lots of pretty colours moving about. The details presented in the video aren't what make that so. If you happen to be interested in those as well, even better.

Technical stuff -- gotchas, hints and techniques for the iPad/iPhone Simulator, ScreenFlow and iMovie

In no particular order (but all particularly important in their own way): 

• Before you even start check that you can record from the Simulator. We had to do some code massage to get it to run in the Simulator (you never test in the Sim, right?) and we had to hone our using-a-mouse-like-an-iPad-screen skills.
• Get your (lack of) compression settings right -- and then check them every time you do something. The only place you want your video compressing is at the very last stage in the workflow (i.e. when YouTube compresses it). Key stuff:
  • ScreenFlow -- Preferences > Advanced > Screen Recording Compression > Lossless
  • iMovie -- Preferences > Video > Import HD video as: "Full - Original Size"
  • (on export) iMovie -- Share > Export Movie
• ScreenFlow only records one display -- do a few test recordings before you spend 10 minutes getting frustrated with the Simulator only to find you recorded the output of the wrong monitor.
• You need to crop the captured video from ScreenFlow after the recording. If your game starts with a black background (ours did) you want to start with something else open -- like Safari -- so that you can line up the the crop window with actual screen (and not overlap the black bezel of the Sim).
• ScreenFlow can capture all sorts of stuff -- make sure you only capture what you need (screen and computer audio)
• Disable the in-game music for your game (you likely want to keep SFX). This way you can have the game's soundtrack (or some other piece of music) play throughout your cuts but keep the in-game SFX if you want them.
• Edit the audio properties (for volume/gain) for each inserted clip independently. For some clips (in-game footage) you probably want to keep the SFX high, for others (menu taps) you'll want it low. Pick consistent changes throughout (we ended up with all "high" SFX at 50%, all low at 20% and a couple of fade outs).
• Be aware of how iMovie handles clip length -- transitions by default play over and consume part of the adjacent clips, so what starts off as a 4.5s clip ends up looking like 2.2s on the timeline with transitions surrounding it.
• Adjust crop and position for every clip -- for example, the iPad screen ratio is 4:3, not 16:9 (which you want to be exporting in most likely), so you'll need to crop and scan each clip.
• Work out how to use the "Ken Burns" crop in iMovie (click a clip, click crop, crop start then hit "Ken Burns", then select red end rectangle and move/crop accordingly) -- it allows you to pan and scan on the fly, set scale transitions and track action. We used these extensively to add or enhance motion.
• ScreenFlow lets you add mouse pointer types -- obviously the default arrow pointer makes no sense, but the optional "circle" pointer works pretty well for finger simulation (we dropped the size and opacity for a subtler effect).
• Pay attention to what you're actually recording -- especially if you're using in-development or imediately-post-production code. For example, we had to fudge the "global high score" and "global average" parts of our fancy skills analysis charts so it didn't look so sparse.
• When creating stills to be used in the video (like the closing shot of the Hyperion trailer), create them at the resolution at which you intend to export the video (for example we were targeting 720p, so we created them at 1280x720).

Concluding thoughts -- would we use different tools? FCP? FCP X? Premiere?

We're pretty pleased with the results -- there are a few bits we'd like to do slightly different given different tools (iMovie's UI sucks -- and it crashed my MBP twice in the process) -- and will certainly be sticking with this formula for future Hyperion (and likely other) videos, but we will look at other edit suites. The restrictions (fixed transitions and single video playback being the primary ones) actually helped us make quick what-can-we-do-with-what-we've-got decisions -- but with more varied source material and evolving requirements we might benfit from taking that self-imposed ruleset to a more sophisticated tool chain.

Er, so what's Hyperion: d7 then?

You'll be hearing a good bit about the Hyperion game itself in the coming days and weeks -- we literally just submitted v1 for approval and finished up on the trailer this morning. We're starting launch activities next week -- but we were eager to get this post out there to the #idevblogaday audience as soon as possible -- we'd have found this very useful 12 hours ago ;)

Should you find yourself needing to make further reference -- or just for the sake preparing for those hexes, here it is again, Hyperion: d7...

21 ways to monetize your game

This is not comprehensive, cohesive or in any particular order. However, it is full of juicy ideas on how to monetize your stuff. 

We’ve been discussing this recently in the context of a new project – you might also find our recent posts on the production/promotion balance and launch-marketing an iOS/iPad title useful.

1. Subscriptions – free to download, but pay for a subscription for so long as you want to play

2. Free trial versions – limited by features, limited by time, limited by expiry date

3. Sale of in-game objects or item for convenience sake (things that you could otherwise create, accumulate, find in-game but might not care to spend the time to do so)

League of Legends is free to play, but sells users a wide variety of playable champions, skins, boosts and other items

4. Selling ancillary stuff – e.g. ads, merchandising (and keeping the game free to play)

5. Pay for access to under-the-hood services (e.g. use of an API, access via 3^rd party services)

6. Hosting of private servers, lobbies for paying customers

7. Sale of cosmetic/aesthetic items or game objects

8. Subscriptions for different levels of access (e.g. free for a single character, paid for multiple characters)

9. Sponsorship of in-game items (advertising)

Burnout: Paradise serves up in-game advertisements as, well, advertisments

10. Pay for services, in-game tools that make it easier to manage/retain your character, world etc (pay not to play)

11. Mixed mode sale (e.g. one-off purchase of items, or fixed-rate subscription for unlimited use / access)

12. Upfront purchase – like how we used to do it

13. Pay for offline automation of persistent character (e.g. AI-like tactics, alerting services)

14. Highlighted/premium status in game-related sites or communities (e.g. forums, wikis etc)

15. Access to in-game, non-core services (e.g. whisper, party chat)

16. Pay for the services of other players (guides for hire)

17. Pay to fail – e.g. allow resurrection where it wouldn’t otherwise be possible

18. Sell in-game real estate

Second Life auctions off chunks of land directly as they’re made available (as well as letting users trade land)

19. Sell choice of spawn locations, other otherwise random new player variables

20. Sell vanity services – naming terrain, aesthetic improvements

21. Currency exchange – sell in-game currency for real-world Dollars/Bahts/whatever

Temple Run, the latest from @nattylux and @kshepherd, allows users to buy coins that can otherwise be accumulated through play

Gutenberg Neto (another #idevblogaday author) recently posted a great article on getting free-to-play right. That’s worth a look.

Honarary mention to Mike Berg (@weheartgames) who reminds us that “no connections, almost no marketing = very low sales. :)” – which pretty succinctly says exactly what I was going to in conclusion: it doesn’t matter how you monetize, if you don’t tell anyone everyone about what you’ve made you’re not going to get paid.

Doing what you (might) already know -- the fine balance of making and promoting your work

We’ve recently been ramping up the attention we pay to promoting ourselves, our work and our upcoming games titles for iOS and the web. In a few short steps (writing up a launch task list, attending Develop and preparing for a couple of conference speaking engagements in September) we’ve come to realize this: all we need to do is exactly what we already know.

To clarify: we know how to market ourselves and our games, we just need to get on with doing it. In order to remind ourselves (and yourselves) of a couple of those basics (because this stuff is basic) we’ve brought them together in this semi-glorified bullet-point list. 

General promotion

• Ensure you can balance sustainability (cash flow, sanity); development effort; profile promotion and title promotion. Without each of these playing its part (you can merge the latter two if  it’s absolutely necessary and done incredibly carefully) you’re not going to see any significant forward progress – and in fact, you’ll likely fall apart or end up going backwards.
• Pay attention to everything. This is targeted primarily at other indies, but relevant to all, because: you should pay attention to what everyone is doing. AAA marketing budgets don’t come easily, but neither does the inventiveness and passion seen in the marketing and promotional efforts of indies.
• Talk to everybody. Network. Targeting individuals is fine, but talking to everybody is better – you don’t know where the pivotal conversations will happen until after they happen.
• Tell people about what you are doing. This is the most important thing. If no one knows what you’ve done, it doesn’t matter how great it is. Your blog, other people’ s blogs, Twitter, Facebook, Google+, forums, mailing lists, traditional media – anyone who’ll listen.
• Get involved. Enter your stuff into competitions. Participate in game jams. Not only do they bring exposure to your work, but they also help you refine your processes around specific points in time and force you to show what you do best: create stuff.

Operational stuff

• Plan what you plan to do. If nothing else it holds you to account and gives you some method by which to assess your progress. Make sure you set yourself lists of forward moving actions – and make sure you review them to make sure they stay relevant and reflect the iteration of your plans as you progress through specific tasks.
• Do everything as cheaply as possible, but no cheaper. It’s astonishing what you can get for little or no money – whether it’s products and services or the time and commitment of others. Just because other people are paying through the nose for something, doesn’t mean it’s the only way.
• Invest in tools. Yes, yes – as per above – but it’s a worth remembering that great tools can make several orders of magnitude’s difference in your most valuable resource: your time.
• Get your commercial and legal bits in order. Legal incorporation and shareholding, banking, insurance, payroll, taxes, copyrights and trademarks. All of these can and will screw you if you don’t get them sorted early on.

Getting better

• Get stuff out there. Putting something out there is better than putting nothing out there. Especially in games development. Getting anything to the point of distribution is hard – regardless of the complexity of the title itself. Once you’ve done this, you can concentrate of improving the core product.
• Sunk costs. Understand the core principle of sunk costs. Make decisions based on what happens next, not what went before. Costs to date should not sway the balance of an otherwise clear decision.
• Analytics and metrics. For your promotional activities as well as for the games themselves. There are a wealth of services out there to help you with this (e.g. Google Analytics, Flurry). It’s amazing what you find out when you start measuring stuff. There’s no better way to challenge and improve your assumptions than with data.
• Take a look at the services others are using. See what they can do for you (can they meet needs you don’t know you have). We’ve seen value beyond solving our initial problems from Skype, Google Docs, Dropbox, BitBucket/Github, Bitly etc.
• Do all of this, then do it again. There is always scope for doing more.

Specifics on – conferences

• Do not dismiss conferences. There’s a reason why pretty much everybody in the industry (AAA, indie and otherwise) treat them as pivotal points in the year.
• It’s surprising what you can learn from others. Whether it’s an introduction to a new topic or reinforcing an existing one, giving yourself the opportunity to absorb information and reflect on your work is incredibly valuable.
• It’s very hard not to network. People want to talk to other people.  Talk to them about their stuff; tell them about yours. It’s the whole fucking point.
• Present your stuff. There’s a wealth of interesting material in what we do – and for sure someone will be interested in what you’ve done. If you’ve ambitions on presenting at GDC you’re going to have to start somewhere.

Specifics on – funding

• Always think about getting paid. No one else is going to do this for you, but no one minds if you make this the most important thing – 9 times out of 10 they’re thinking about the same thing.
• Funding means everything that gets  you paid. Everything from revenue based on past successes, self funding (subsidizing) and borrowing through to angel and VC investment falls into the same category.
• Learn from the pros. VCs and angel investors generally look at you & your team, your competition, their (and your) exit strategy, user acquisition, results to date and transformational potential – you should too.
• Look at yourself from the perspective of others. Regardless of whether you’re seeking funding or not, viewing your work (and more specifically your actions) from the perspective of an outsider can highlight stuff you might not otherwise have seen. If you wouldn’t invest in yourself (or your idea, current plan etc), why would anybody else?

An iOS (iPad) app launch marketing and promotion task list template

We just finished up an outline launch task list for our soon-to-be-announced iPad debut title – this post contains that list, effectively a draft iOS marketing plan. It’s pretty generic, so we figured it might be useful to everyone else out there.

We’ll be revisiting this over the coming weeks – if you’ve got input, questions or whatever let us know – we’ll update this post and report back as we fill out the gaps.

Where are we at right now?

Right now – July 28^th – we’ve got a mostly-finished game, a name and this list.

This is our first _proper_ release on the App Store – we’ve put a few things out there before, but this is the first time we’re doing a launch proper. We don’t expect everything to magically go in our favor – but we do know that if we do everything we can this time round we can only make positive iterations from there on out (we’ll have other stuff launching this year as well).

Required Assets (things we’ve got to make):

1. The game itself (full/paid version) – see list below of new/related features

2. Additional SKUs/version (lite/ad supported etc) – TBD

3. Various videos (launch trailer, full trailer, gameplay footage etc)

4. App assets (app description, screenshots, icon, press release/launch text etc)

5. Game website

• Cross-site stuff with this site
• Leaderboard integration with OpenFeint stuff
• (post v1) level/map sharing

Things we need to decide:

6. Decide on launch price

7. Decide on free version (lite or ad supported)

• (lite) launch date
• (lite) what features
• (ad supported) launch date – presuming same as full version at this point
• (ad supported) ad location / integration
• (ad supported) future feature set – will it get all post-v1 features?

8. Confirm app name

• Current use (revisit this since originally deciding on name)
• Trademarks in relevant regions (at least US & UK)

9. Game website URL (dedicated domain or sub-site to this one)

Features required in app (that relate directly to this list)

A good chunk of these are specific to the game we’re launching – though all are specifically launch/promotion related so completely relevant to other games, just need some adaptation.

10. News and updates pull RSS feed for front page with optional links (to other parts of app; to external URLs)

11. Separate feed (or filter for full/free apps) such that in-app cross-promo news items make sense

12. Finish “challenge” levels design – including having 4-8+ weeks worth of challenges

13. Figure out challenges integration for OpenFeint (if possible) and pushing of leaderboards to game website

14. Decide on final stats and analytics (just Flurry or our own stuff as well)

15. Decide on & implement final version of level sharing – particularly external services and iOS protocol handlers for twitter, facebook, google+ etc

• Do we register our own handler?

Other things to think about / research

16. Do we need to think about readying App Store promo / feature assets in case we get one?

Launch schedule critical path

Fill gaps, estimate time scales and update/re-sequence this launch sequence list:

17. Announce game

• 36peas blog
• Dedicated game site
• TA forum post (initial launch post) + announcement trailer
• Media host locations (youtube, vimeo)
• Offer limited number of public beta test spots

18. Release full trailer

19. Announce to iOS press

20. Distribute promo versions

21. Submit for approval

22. (update, resubmit, required)

23. Announce launch date (decide on best day of week)

24. Release v1 (at promo price)

25. End promo period

26. Announce v1.1 features

27. Launch v1.1 + promo price

Launch activities (not on critical path)

Plan and prepare for other launch-related activities (that are not on above critical path:

28. Solicit media requests for promo material

29. Identify “target” list of game biz people, iOS people, developers, media etc and do direct notifications where known or relationship exists

30. Cross-posting elsewhere of dev- or launch-related contents (inc #idevblogaday, The Cocoa Mag)

31. Speaking engagements and other public events (360idev – we’ll be speaking there and at iOS Dev UK)

32. Identify other timely launch-time events (game jams?)

33. Complete schedule of development content (blog posts etc) related to the game’s development

34. Get in touch with Mike Berg to update last year’s 360idev game jam site – this title is based on a prototype that originated in Austin 2011. Also give Jon Wilker a shout to encourage a mention – timing should be close to this year’s game jam

35. Identify and schedule other promo opportunities and offers – are “freeappaday” promos still worthwhile?

36. Release soundtrack via iTunes & some form of (free?) direct download

Post v1 features

37. Sort out development time scale such that we know when a v1.1 is released (presuming point releases – 1.1, 1.2 etc are feature-full, others 1.0.1 etc will be fix releases)

38. Decide on known likely post-v1 features (multiplayer, map editor + sharing)

Post v1 activities

39. Update this plan with an ongoing retrospective analysis / results

40. Release gameplay stats

41. Release commercial stats

42. Announce next version

43. Release next version

44. Identify competitions, summits etc -- anything applicable to enter title into

Your input wanted

Did we miss something? Is there an area you'd like us to expand on? Let us know in the comments -- we'll update this as we go.

---

Updates

28th July -- Added #44 -- re competitions and summits

Access, not ownership. My view on digital books.

Digital books, blah blah blah -- the argument seems to centre around all things related to ownership. For me, it isn't about ownership -- unless you see yourself as the sum of your things or you consider that books are a better medium from which to learn or enjoy.

Which brings me onto the key point in all of this: access. If that means $10 on a book because I didn't buy it already / don't have it to hand / lost access to it due to a poor purchasing decisions -- then so be it. Next time it'll be $0 on a wikipedia article or blog post or whatever.

If you really do want to "own" your digital content in the I-can-and-will-take-all-responsibility-for-its-wellbeing sense, then you can -- all the major digital book services provide you with permanent, resilient, local, disconnected copies of files. You just need to know how to manage each and every source and be prepared to do a little management. Compared to the pain in the ass that is finding, moving, storing and living with a large number of physical books I think it's no big deal.

Wired: "An unfinished e-book isn’t a constant reminder to finish reading it." WTF? An unfinished e-book isn't a burden on your conventionally-bent self assessment. As it happens, I do finish most books I read. In fact, I finish far more ebooks than I did physical ones because I've always got them all with me. Further counters to Wired's nonsense an be found here at allaboutthevoluntary.com.

Revisionism is a valid concern. But with a little more market saturation and a few more tools, it'll be hard to get away with. Once DRM goes away (it will), it's a non issue as copies proliferate and comparisons are easy. Existing DRM will be brute-forced in about the same time it takes for DRM in the book space to go away. It's really not an issue from a technical point of view. Sure, it'll happen (and does in print books as well as ebooks), but it'll be highlighted.

In the Kindle app on my iPhone I generally have between 10 and 15 books on the go, and manage to get through 1-2 a week. This is done either in 15-minute segments when I have a free hand and eye, or as a reference to whatever I'm working on. At the minute that includes Enter The Kettlebell!, Replay: The History of Videogames, Atlas Shrugged, The War of Art,  The Art of War, The Vegetarian Myth,  and The Art of Game Design: A Book of Lenses, Demon's Captive and Fun Inc. That includes a book not available in this country in print, one that I've been reading for about 3 months, one that's entirely reference, one that has been revised and translated many, many times but I was able to find an as-far-as-can-tell faithful translation of and one that even I may be too embarrassed to own in print.

We're at same point we were 5-7 years ago with digital music. The transition might take a little longer (recordings of music as property have been around for far less time than the printed book) but it'll happen, and in so happening a lot of these little things will go away. Those who really care about "books" (I don't by the way, I care about information), will revel (I am revelling already -- see above paragraph) in the access granted to them and embrace digital books. For the majority, the perceived snobbishness around books will eventually go away with this realisation.

The motivations of the remaining minority will become clear. Either they do actually prefer physical books as a way of accessing and digesting information (and this is entirely reasonable) or they perceive some other value in the ownership and accumulation of those physical books.