Testing our amazon associate link. Let us know what you think.
Testing our amazon associate link. Let us know what you think.
In this piece, I wanted to talk about something that comes up all the time in discussions with other game developers, and that is the disparity between what people think about how we make games, and how we actually make games.
There are a lot of things that go on behind the scenes in a game development company, in fact in all game development companies, that go generally unnoticed by the general population. That's fine, and it's expected, because what you see is what we put out in our game, trailers, blog posts, content updates, and Twitter feeds. But what else goes on that might motivate some of our ideas that the average gamer doesn't know about?
In an ideal world, every game developer would make exactly the game they dream of, not limited in the content they can produce, not limited by their own talents or the talents of their colleagues, not limited by a publisher's wishes or orders, and not limited by consumer expectations. But in reality, we run businesses and this ideal world would require infinite time and money.
This doesn't mean that all of our decisions, or even most of our decisions, are driven by making money. What it does mean, however, is that when someone is putting out a single player puzzle game that should last 4 hours and selling it for $9.99, there is absolutely no way for them to make it a real-time co-operative online multiplayer open world procedurally generated puzzle game... still for $9.99.
What the developer wants in that situation is irrelevant, the fact of the matter is that even if the money was there to hire the network programmers, additional artists, etc... there would still be a question of dealing with the cost of keeping those people after launch, based on how much the game might earn. It also means that developer now becomes a manager more than a developer, and needs to learn new skills and work in a new position. There are hundreds more questions that arise from decisions like this, and all are bigger than most people might think.
On the surface, as I mentioned earlier, people see games. The games come out every couple of years or so, and are often delayed. What people don't see is that the driving forces for decisions can be very different for different companies. Just in Montreal, I can name five similar sized studios that have fairly significantly different business models and way of funding their projects, making their decisions about what games to work on, hiring employees, etc.
The event that sparked this section of the post is the announcement that Hibernum, a seemingly extremely profitable Montreal company that did mostly contract work and used licensed IP to make mobile games, let go of most of their employees last week. Even though I'm close with people from that company (including some executives), and even though their games appeared to be successful, this can happen. So what's the situation under the hood? We never really know. Obviously I can't talk about anyone's (including our) financial situations directly, but in some cases, studios need to put their own ideas on hold and take contract work to survive. Sometimes they need to restructure, sometimes they shut down, and sometimes they make millions of dollars and stay single-person companies.
The crazily falling price of film technology and the advent of social media and the “gig economy” have all come together to make it possible for filmmakers without Hollywood connections to produce feature films. Filmmaking tools that used to cost literally millions of dollars can now be had for hundreds to a few thousands of dollars. Aspects of filmmaking can now be “internationalized”, bringing down costs further. Not surprisingly, there’s plenty of great features that have been made for next to no money. Some of them have gone on to great success.
Of course there’s the out of this world income that Paranormal Activity picked up; shot for a reported $15,000 it grossed a whopping $193 MILLION! But while that’s an outlier (ie. don’t expect it to happen to you) it’s certainly true that there are microbudgets that have had great success. Many successful films, such as Primer, Bellflower, The Animal Project, For Lovers Only, Tangerine and numerous “mumblecore” films, have been shot for close to nothing.
So, it’s possible to make a feature film for next to nothing and have it do well, at the very least in terms of launching the careers of their filmmakers. But what is the recipe? How can microbudget filmmakers repeat these successes?
These are some key elements to the success of your microbudget feature film:
This is maybe the most important: don’t try to make a typical Hollywood genre picture with 1/10000 of the budget. All you end up with is a cheap looking knock-off. Without the high priced equipment and crew, music, special effects, etc. all the weaknesses of Hollywood films are exposed and none of the strengths are possible.
Other than Paranormal Activity, all the films mentioned above have pushed the boundary of their genre or broken long-standing rules. Even Paranormal Activity, shot like a cheap video monitor, broke traditional rules of aesthetics and took the “found footage” genre in a different direction, which felt fresh and surprising.
For Lovers Only, shot for a reported $0 (that’s not a typo, though it is a claim based on a certain amount of marketing hype), explored a non-traditional romance – adultery – that used avant-garde cinema techniques from the French New Wave to amp up the romance. It also had a story structure that was loose and dreamy, again, amping up the romantic ambience of the film. It helped that it was shot as a road movie in the country of romance, France.
The lesson is clear: experiment, break rules, dig deeper than what is on offer from the big, commercial films.
You want to write a space opera but you don’t know how to do it. That’s OK, you can watch some how-to videos on Film Riot, right? Bad idea. While a microbudget is a good place to experiment in terms of story, it’s not a good place to experiment with high stakes effects.
You need to be brutally honest but also open-minded: What are your resources? Do you do circus performance, like juggling or aerial silks? Or parkour? Can you bring those unique talents into the film? Do you build mud huts or robots? Do you have access to a green screen wizard or know Adobe After Effects like the back of your hand? Is there a de-commissioned insane asylum near your house or an old barn? Do you have a cool motorcycle that would be great for a road movie?
Most people have far more resources than they realize but they are thinking about the Hollywood movie they WANT to make and not the awesome no-budget feature that they CAN make.
Think about all the things you have and can do, all the people you know and what they have and can do – right now. Seriously: make a list. Then take the theme and story you’re passionate about and build it around that.
Primer, made for $7,000, resourced Shane Carruth's background in engineering. It's intensely cerebral.
It's now a cult classic and allowed him to make his next film for ten times that amount.
You’re going to need a great team to get your film made. You don’t want to break your teeth trying to be writer/director/producer (and maybe star and cameraperson) on set. You don’t even want to be in pre-production trying to do it all on your own.
Having a producing team of people who are enthusiastic about the project and see it as their own will also lift the financial burden off of just you. If you want to make a $10,000 film and you divide that four ways, you reduce your personal costs to $2500, which is much easier to swallow.
But having a solid team also allows you to have much better planning, better scheduling, better budgeting. When you’re making a microbudget and you don’t have any “contingency fund” to dip into in case you don’t make your days, planning will determine whether you complete your film or not.
Of course it’s great to find more experienced people, preferably at least with some short films under their belt. But just remember when it comes to your team, your crew AND your cast, enthusiasm is usually more valuable than experience.
Also remember – it goes in both directions. If you want to keep your (unpaid) crew around you have to be the best, most competent, kindest person on the planet. You have to be the person who keeps their cool when everyone else is losing their minds. In other words to create a great team, you have to be a great leader.
Hollywood does this, of course – with teasers, behind the scenes, and “making of” films and featurettes. You should too. Chronicle the entire process of making your film and share – on an ongoing basis – with your budding audience. Because this is so important you should have someone on your producing team whose sole purpose is to generate marketing buzz. In case you haven’t heard of this role, the filmmaker Jon Reiss coined the title Producer of Marketing & Distribution.
People love to see photos and short videos. People find romance in the filmmaking process. There’s something magical about creating stories. Let them see how you do it. They’ll want to see the final product. That means making sure you have a stills photographer on your shoot and, if possible, a videographer.
While you’re thinking about marketing, think about whether you connect with any niches. Niches can be the lifeblood of any microbudget marketing venture. Is your film about gay firefighters – that’s a niche that you can find online, on Facebook, Twitter and elsewhere. Is it about a particular location, a sport with fanatical participants, style of music, etc. These all have particular niches that exist online and can be found without much effort.
Too many filmmakers think that crowdfunding is about raising money. It’s not. Not primarily anyway. It’s about building a fan base. The money is a nice bonus, a symbol of your fan’s commitment to your goal.
With crowdfunding, and marketing in general, you need to be aware that at first your audience of fans will probably not extend beyond your friends and family – and perhaps those of your cast and crew. Is it any surprise? Do you go see bands you’ve never heard of just off a poster you see on the street? This is going to be a more than one picture process. The film Tangerine was a big breakthrough for the filmmaker, an “overnight success” – it was also his fourth feature film.
That’s why you shouldn’t try to raise the money you need through crowdfunding, you should raise the money that you can. In other words, sit down, go through all the friends and family you think will give money and estimate how much. Then divide it by half. It is better to ask for $2000 and raise $5000 than it is to ask for $15,000 and raise $5000.
You’re trying to use the crowdfunding campaign to raise excitement and enthusiasm for your film and to pre-sell copies of it. Nothing kills excitement and enthusiasm more than a terrible failure.
You’ll notice that not once did I mention the gear that you need? That’s not an accident. I interviewed an Indian filmmaker recently who shot most of his first feature on a Canon Rebel – a crop-frame, prosumer DSLR. Their “camera slider” was a sweater that they set their camera on and pulled slowly across a table. They’re in negotiations with India’s version of Netflix to sell the film and with a more established producer to make their next film. Too many filmmakers obsess about gear.
The quality of even cheap gear now is such that, unless you’re shooting a film that really, really needs a particular camera for a specific reason, nobody is going to know – especially if you have a gripping story. Sure, have decent sound gear and a camera that works. But Tangerine was shot on an iPhone 5S and it went to Sundance. What’s really important are the other things – the story, the team, how you have built buzz and the uniqueness of your vision. With a little magic, if you can bring these elements together, you stand to make a great film and launch your career out of it.
Squatting Monkeys is proud to announce that we are currently working on two games with a tentative release date of Winter 2017.
X is a stylized futuristic racing developed by our team. We are planning to launch on Steam, Windows Store, Mac Store end of this year with consoles hitting Q1 2018. The game will launch on XB1, PS4 and Nintendo Switch.
Apocalypse Now is a 4 player co-op experience similar to Left 4 Dead. The game uses Unity Engine will be available tentatively by the holiday season. The game will launch digitally on Windows, Steam, Mac store, Nintendo Switch, PS4 and Xbox One.
Launching a new mobile game is cheap these days, right? I mean, the common wisdom is that anyone can make and release a mobile game for practically nothing - just a small bit of time and maybe some hard work and then you sit back and wait for your 'free money' to potentially roll in. I assume this is part of the reason why, once people hear I make apps, they keep telling me about their new (and impractical) 'awesome app ideas'...
But what does it really cost? And what does it cost if you want to do it professionally - create a company and treat it as the first game in an eventual portfolio?
The first cost for me was setting up a new company I could release games under. You can technically avoid this if you want, as I think all of the major app stores allow you to sell apps under your own name, but there were a couple of reasons I decided to go down this route.
I'm offering a product for sale worldwide and while I don't anticipate any issues, there is always the slim chance someone will decide to try and sue me over some obscure patent, copyright, trademark or some other reasons. That's just the reality of the world at the moment, and I'll sleep better at night knowing I'm somewhat protected since they can only sue the company and not me personally.
I think its just looks a bit better. I would rather have customers seeing a company name at the top of my products' store pages than my own. I think it also adds a bit of credibility when contacting press or platform holders for featuring.
The final deciding factor for me was that it was extremely cheap (and relatively easy) to set up a new company as a Canadian citizen. It cost me $450 to incorporate the new company, and another $30 to register a trading name so I could drop the 'Limited' from the end of the company name on stores (it just looks better). I spent about 10-15 hours reading over all the relevant documentation and laws and then I was good to go. There is a bit of ongoing paperwork (doing accounts for example), but I didn't need a lawyer or accountant to get started and as long as the company's yearly revenues stays below a certain amount a year, I won't need to incur any major costs like audits and don't need to register for GST straight away. This process could cost you a lot more depending on where you are living however.
App Stores Registration Fees
One cost that isn't optional is the various app store 'registration costs'. I am releasing on the Apple App Store, GooglePlay, Amazon, Windows Store. The Apple App Store is $99, GooglePlay is $25, Windows is $150 and Amazon is free. The only hidden catch here is that the Apple App Store developer license is recurring , so its actually $99 a year (but that's next years problem...) So that's $275 to release on all 4 stores.
You need build machines and mobile devices to test with. I actually had access to everything I needed already, but my circumstances are a bit unique, so chances are you don't... I do most of my development on my windows gaming PC, but I also have a 27' iMac I got years ago for some ios Development at home. You need a mac to build and release on the Apple App Store and you need a Windows 10 PC to build and release on the Windows Store (and because Unity can be a bit of a pain to use on the mac). Since even a cheap second-hand mac can set you back a few hundred dollars, this could be a major expense for a few people.
Test devices are trickier - my main test devices are a cheap kindle fire and an old nexus 7 for android and my current iPhone 5s and old iPhone 4 for iOS. (I always prefer to test on older, slower devices - I can get a rough idea of how things look on my dev machines, but for performance you need to test on device). Those 4 devices really aren't enough for proper testing however - you'll need to test on few more android devices from different manufacturers (bare minimum would be a kindle, a nexus and a htc). You also want to test on different iOS devices - especially the newest iPad Pro to see what your game looks like in full retina resolution. Its pretty common to find rare bugs/inconsistencies that crop up across the different CPU/GPUs of the iOS device family. You also want to test on a few different versions of Android and iOS....
Luckily for me, I have access to all of these devices at my day job - and they have been very cool about me testing on them outside of my work hours. Without this, I definitely would have had to purchase at least a few of them - and the newest devices don't come cheap.
So what about making the game itself? How much can it cost when you do 'everything' yourself?
First off, while I'm not counting my time as an explicit cost - I am aware of it. Anyone who tells you it cost them 'nothing' to make a game is lying to you. I'll work out the exact times later for a retrospective, but I have probably spent about 400 - 500 hours working on the game in one form or another. That's maybe 3 months of full time work, so the opportunity cost of that is theoretically pretty high. For illustrative purposes, I'm a videographer and Area Manager when not making games and the average Canadian salary for that is $115,000 - so $~28,000 for 3 months. Now I'm doing all of this in my spare time, so I'm not missing out on any income, but there is still a cost - as of writing this I still haven't started Outlast 2! Let alone the various games that came out over the Holiday season.... Oh, yeah - and missed time with loved ones, that's also important....
In terms of production costs, I did all of the design, programming, art, audio and marketing (such as there was) myself - for better or worse. I actually enjoyed switching between the different disciplines more that I expected, but I was never quite happy with how the audio turned out. There is obviously going to be a trade off in terms of quality and scope when wearing all the hats yourself. While I am confident enough in my design and engineering skills for example, I work with some really talented artists and my limitations in the field are made immediately obvious when I try to draw something to illustrate a point (my stick figures put other programmer art to shame...). This heavily effected the design of the game, as I adopted an art style I was confident I could pull off.
Localisation was something I couldn't do myself though (and if you are reading this and thinking to yourself 'Google Translate'... No. Just No.). I wanted to launch worldwide and decided to localize in 14 languages - most of the major ones and a few that I suspect the Apple featuring team have a soft spot for. Localizing obviously broadens your potential markets, and not localizing reduces your already infinitesimally small chance at getting featuring from the major store-fronts. (As a side note, I really wanted to localize into Arabic, but Unity doesn't support it by default - get on that Unity!)
I knew localisation was going to cost a lot, so I worked to keep the number of words as low as possible and chose re-usable phrases where I could - some of those translations are going to be used in future games to help reduce costs! In total, I needed 175 words translated. As a side note, I strongly recommend you have all of your store pages filled out before you get things translated, there are a lot of small things you can miss like minimum and maximum string lengths or descriptions for IAPs. I went with keywords for the localisation as they had localised apps I had worked on before - they weren't the cheapest option, but their rates were reasonable, they were nice to work with and had a great turn around time. In total, localisation set me back $800
Surely that's it right? Well, for me it is. But some of you might have noticed a distinct lack of market spend.... I'm not going to pay for 'expedited reviews' on principle, but what about advertising? For this game, I don't think its worth it - its a fun game, but the monetisation is basic and it doesn't have the kind of stickiness a modern free to play game needs to succeed. I needed to stick to free marketing for this release - I have sent out promo codes to various outlets and YouTubers, contacted the stores in the hope of promotion, and will send out a few press releases on launch day.
App Store Dev Licence : $100 (per year)
GooglePlay Dev Licence : $25
Windows Dev Licence : $150
Amazon Dev Licence : 0
Unity 'Plus' Licence : $400 (per year)
Company Registration : $150 (per year)
G Suite Company Email : $60 (per year)
Website Hosting and URL : $300 (per year)
Localisation : $800
Total Cost : $1985
I am in the enviable position of not needing this game to turn a profit since I made it in my spare time. I hope people download it, play it and like it, but to pay back its $2000 cost I would need a lot of downloads once you factor in conversion rates (probably 100,000+). Luckily, I worked out the majority of this before I started and knew what I was getting into - and I really enjoyed making it. Some of those costs won't come up again, and depending on how many games I make a year, some of them can be spread out. The next game should cost me less, as will the ones after that, and I do plan to keep making them. Hopefully, if you decide to make your own games, this post will help you go into it with your eyes open.
This might seem like an obvious one, but I know I've heard fellow producers say some variation on how the game designer's job is so easy compared to theirs, and that they could do the game designer's job in their sleep. Heck, I'll confess that the thought crossed my mind once or twice! While this idea may be true for some projects, in my experience the role of game designer is at least equally as difficult as the producer's.
Game designers utilize many, if not all, of the same "producer" communication skills when collaborating with and giving direction to the team, and when giving presentations to stakeholders about the design. Game designers even arbitrate disagreements between team members-usually creative ones, rather than interpersonal ones, which can sometimes be even more sensitive.
One interesting communication element that I didn't fully understand was that people ask the game designer to explain themselves all the time. Developers want to know more about the system you designed, stakeholders want to know why you chose to design the system that way, the producer wants to prioritize everything about the system in case something needs to get cut, and everyone along the way will want to know why you didn't implement their idea-or didn't implement it in the way they wanted. Producers get a lot of this too, though as a producer I often feel one step removed: you're explaining the project, rather than yourself.
The two jobs do many of the same things, they just approach the communication and the coordination from two different angles: producers on the managerial side, and game designers on the creative side. Based on my experience, neither role is "harder" than the other, they're just different, and it takes some empathy for one to figure out what the other is going through.
This was another lesson that I thought I understood going in, but I really had no appreciation for until I was on the other side. Because the producer and the game designer are two sides of the same coin, and because they have to work so closely with one another, the two must be in lock step with one another. If the two don't understand and trust each other, the team won't feel like it has unified leadership, which gives rise to a number of other problems that can trickle down through the rest of the team. For example, when my producer and I experienced a number of communication breakdowns over the early sprints of the project, we noticed that there were other similar communication breakdowns between us and our leads, and our leads and their departments. Regardless of whether or not we realize it, team members can sense when their leaders aren't getting along with one another, and that destabilizes the rest of the project.
The inverse is also true. Later in the project, the producer and I felt so in sync we kept joking that we shared a brain, and we noticed that the team seemed motivated to work hard and succeed together. The two of us leading together not only helped us support each other and lower our stress levels, it helped our team figure out how to work together.
Furthermore, the dynamic between producer and game designer isn't going to be a one-size fits all relationship. I realized after talking with my producer early in the project that one of the reasons why we had problems together was because he assumed I had the same strengths and needs as his previous game designer, when I actually needed a different kind of support. Producers and game designers must take the time to get to know their "other half," and be flexible enough to find new ways to work with each partnership they have.
Despite a clutch of enviable awards, many concluded that the 2012 film Indie Game: The Movie, a documentary that followed a handful of thoughtful, industrious game developers working in near-poverty on video games that eventually made them rich, gave an unhelpful account of independent game-making.
As in most creative ventures, financial success is the exception. Moreover, the film’s implication that major game studios were holding their staff back from fame and wealth, if only these game-makers could be courageous enough to strike out alone, was misleading.
The narrative proved effective. Many were inspired to leave the relative security of a job in mainstream game-development to launch independent projects, with varying degrees of success.
It would be too much of a stretch to imply that, five years after the explosion of indie game development, we’re witnessing a widespread return back to large studio development. It is, however, undeniably true that, for every indie success story, there are scores of independently produced games that have failed to make a mark or to provide, for their creators, a viable new career. And as such, many are returning to more orthodox roles within established studios.
Likewise, with the democratization of game-making tools during the past decade, major studios increasingly receive applications from young developers whose first experience of making and releasing software was as individuals. Indie game-makers are increasingly occupying roles at major studios.
“After the chaos of releasing a game with an small independent team, there’s something soothing about the routine of going into the same office and seeing the same people day in and day out,” says Noah Sasso, creator of BaraBariBall, a competitive game that featured on the PlayStation 4 collection of absurdist athletic minigames, Sportsfriends.
"There are a lot of complicated and personal factors involved in being an indie. You have to be comfortable living with uncertainty. You have to have good connections in the industry. You have to be able to manage ugly realities, like the fact that most people need a regular income to survive."
In the summer of 2014 Sasso joined Iron Galaxy, the Chicago-based creator of Killer Instinct, which has also ported lauded fighting games such as Street Fighter III: Third Strike to contemporary consoles. Previously Sasso, like many freelancers, had a portfolio career: a string of freelance gigs supplemented by teaching posts and other odd jobs. While touring BaraBariBall around game events such as EVO and PAX, Sasso met Iron Galaxy founder Dave Lang. When Lang offered Sasso a job, the opportunity for security, as well as the chance to work with like minded and highly experienced competitive game-makers was, as he puts it, too good to pass up.
"There are a lot of complicated and personal factors involved in being an indie,” he says. “You have to be comfortable living with uncertainty. You have to have good connections in the industry. You have to be able to manage ugly realities, like the fact that most people need a regular income to survive.”
Many of these problems have been solved by Sasso’s move to a major studio, but there have been costs too. “I miss the flexibility of solving problems more slowly and more naturally,” he says.
Likewise, Sasso has had to learn a specialized kind of humility. “When you’re making a game with a large team, there are so many factors at play that unfortunately the decisions that seem like they would be most logical or the most fun aren’t always possible, and being able to roll with the punches with a bit of grace is important.”
Teddy Dief is a designer and programmer who, following the successful launch of Hyper Light Drifter in 2016, made a similar move to Sasso, joining Square-Enix Montreal as a creative director. Dief has previously worked in larger studios such as Gameloft, Disney and Microsoft, where he worked on the Kinect project. “I went indie to work on my own games, because I knew I wanted that creative influence that comes when you’re a part of a tiny team,” he recalls.
"If you average out indies, they make far less than AAA devs. Don't go indie for the money. Hell, don't go into games for the money."
But Dief rejects the idea that his recent move back to major studio is at odds with that aim. “I decided to come work with the studio as Creative Director because our goals aligned,” he says. “I wanted to make a certain type of game, and they felt it was a good match for their future interests. We got along well. The AAA environment is affording me a little extra scale, but I still very much value low-ish scope.”
Still, it’s the general consensus that indies benefit from more creative freedom and control, flexible working hours and a shot at greater financial rewards compared to those working at major studios. “I would agree with that consensus, except for the major financial rewards part,” says Dief. “There are outliers, and I'm lucky to consider Hyper Light Drifter one of those. But if you average out indies, they make far less than AAA devs. Don't go indie for the money. Hell, don't go into games for the money.”
Salary, security and the companionship of co-workers are clear incentives for any indie interested in joining a major studio. But there are benefits for the employer too. Anyone who has taken a game from idea to release has a first-hand appreciation of the various disciplines and requirements involved in launching a game today.
Conversely, young designers, artists and programmers who have cut their teeth in a large commercial team are more likely to have had a cloistered experience. “Someone who has spent five years working on a half dozen smaller projects, whether they are independent or otherwise, has had opportunities to learn from mistakes, correct assumptions, try on different roles, in a way that someone who has worked on a single game for five years has not,” says Sasso.
Dief agrees: “They’ve seen how all the pieces fit together because they had to mash every single one of them together with their own blood, sweat, and tears. They have a perspective on game creation that you can’t get any other way.”
"The culture clash experienced by an indie joining a major studio (the stricter working hours, new tools and processes) must be addressed with care."
Freed from the commercial pressures to infuse their games with a wide appeal (with much lower overheads, an indie game-maker can aim for niches) they’ve also likely had the chance to be more experimental. But while a generalist with an experimental temperament may add some useful spice to a major studio project, they pose risks too.
Being able to work efficiently as part of a large team requires a raft of particular skills, ones that take time to develop, Ricky Haggett, developer of Hohokum, told me. “This can make it both harder and riskier to parachute an indie into a higher-level role at one of these places.”
The culture clash experienced by an indie joining a major studio (the stricter working hours, new tools and processes) must be addressed with care. “There may be things indies are used to that major studio isn’t used to supporting,” says Dief. “Maybe an indie loves going to Fantastic Arcade every year, and considers that trip a crucial part of their annual routine. The AAA employer might want to respect that rhythm, and the two have to negotiate to make sure they can take vacation at that time to preserve that priority.”
At Square-Enix Montreal, Dief has seen the benefit of fostering a team that has a mixture of developers who have come from indie game development and those who have been brought up within the studio system. “I also work with people who have shipped multiple blockbuster console titles who, as a result, have specialty expertise I'll never have,” he says.
"I think the indie vs. studio binary becomes less and less meaningful every year. In the end the goals and motivations of the people you work with are more important than the size of the team."
Dief worked for years at Glitch City, a co-op space he co-founded in Los Angeles’ Culver City. An open plan office space, with a lively décor, Glitch City is home to around a dozen people, all of whom work on different projects. It’s this sense of being together with people working on different things that Dief most misses from his current set-up. “I learned a lot from that, and I push to meet and share with other devs in my city now.”
That loss of environmental freedom has, for Dief, combined with an increased sense of responsibility to others, something that indies who work alone often do not have to consider. “The team I work with trust me to make decisions that affect all their lives,” he says. “I feel the weight of that responsibility. It’s intense.” Since Dief joined Square Enix Montreal, he’s found that he needs to protect his time. He keeps a daily faux three-hour meeting in his shared calendar in order to ensure he has time to do “deeper work.”
While Square Enix Montreal is a forty-person studio, Dief’s immediate development team consists of just seven people, a size that’s much closer to a typical independent team than the battalion of staff required to make a contemporary blockbuster. It is, Dief believes, the ideal size for an indie game-maker moving to a larger studio. “I love still getting to talk with the whole team every day,” he says. “That just doesn’t happen when you get into the bigger numbers. I want to see every team member’s handprint clearly in this game, and that gets really hard to preserve when you get bigger and bigger and more specialized.”
This set up of a smaller, indie-like team working within a multinational corporation is perhaps evidence of another paradigm shift in modern game development. “I think the indie vs. studio binary becomes less and less meaningful every year,” says Sasso. “In the end the goals and motivations of the people you work with are more important than the size of the team.”
There may be other practicalities bearing down on game-makers, however, especially in America. In the Trump era, all signs point to it being more difficult for freelancers and independents to secure healthcare coverage. A job at a major studio could provide a crucial safety net, especially for older game-makers. Beyond these utilitarian considerations, Dief broadly agrees with Sasso. It’s important, he says, to not get too caught up in the old definitions. “There’s some culture clash, but ‘indie’ and ‘blockbuster’ are ultimately not labels that stick to people. They just stick to studio structures, entities we can all move into and out of over the course of our careers.”
Designing games is an extremely challenging job. It requires a vast array of skills, knowledge and experience in order to do it well, yet it is perceived by many as being easy to do. There are many kinds of designers and design jobs out there, and they all often do very different things each day.
People often think that designing games is just about coming up with ideas. Ideas are a dime a dozen. Taking an idea and making it work, making it fun and making it into a game is the hard part. Execution of the idea is everything. In the end, you have to trust that you and the people on your team will have plenty of great ideas along the way, so great ideas aren’t going to usually be a problem for most teams, but making the idea is another story.
Some people think that great games are all about good game play or storytelling, artwork, cool technology or some other aspect of the game. In fact, it’s about all of them and how they all fit and work together. Designing games is a constant compromise, since everything must fit together and work as a cohesive experience.
You often see a bad feature in a game and think that you could have done it so much better, and that the designer of the game must have been an idiot to have done it that way. While there are some bad designers out there, and a few people with bad ideas, the reality is that it is often out of our hands. If the technology doesn’t come through for you, if a feature isn’t possible to make, if the artists can’t make it look right and if a thousand other things that could happen do, you can get completely messed up and have all your plans evaporate instantly.
As a designer, it can be a hopeless feeling to have all your hard work thrown out because something else didn’t come together. While we can never remove risks like this, and it will always happen and be the thorn in our side, there are things you can do to prevent many of these problems from happening. Having a process that you follow when you make games will help you prevent many of these problems and others which you might encounter.
All games must go through a development process. This means that they usually follow the same order of events, or a similar order of events when they are developed. Most games follow a fairly similar development cycle. Each company makes games a little different, but the overall development cycle is very similar. So from a high concept level, the game development process is similar to the development of other software and entertainment products.
The basic development cycle goes like this:
Concept - Pre Production - Production – Post Production
Later on we will refine this cycle a bit more however, to show how this process of making games is slowly changing.
Like most everything else, all games must start with an idea. This idea must be thought about and refined a little bit, until it can begin to form into a cohesive concept. This concept is usually then developed into some kind of proposal. Occasionally this may just be you going to your boss with the idea in your head and telling it to him to get approval to make it, but usually it involves putting it down on paper in some kind of formal way which people can read, understand and get excited about. The goal of this first step is about getting permission to develop your idea further.
Once you are given permission to develop the idea further or decided for yourself to refine the idea more, you can then start what is called Pre-Production. Pre-Production is the time when you take your early concept and evolve it into something which can show why the game should be made. The goal of pre-production is to develop a game prototype which shows why the game is fun, how it looks and that the technology necessary to build the game is feasible. Pre-Production is therefore the planning and early building stage. For a designer, this is where a lot of your work is done. Surprisingly, Pre-production is one of the most important stages of the development cycle, and is often either overlooked or severely cut short by many developers and publishers. At the end of Pre-Production, you generally will need to show your game prototype to someone again to get approval to move into full production.
Once you have approval to start building the entire game, you move into Production. Production is when most of the assets of the game are made, and when the bulk of the features are flushed out. This is when the game is assembled. The goal of this phase is to create a version of the game which is basically all together, done and ready to test.
Once a game hits a key point, called Alpha or Content Complete by many people, it should have all of it’s features and programming code finished. The goal of this phase is to find all of the bugs with the game, make sure it is stable, compatible and well balanced. At the end of this phase the game should be finished and shipped to the public.
Keep in mind that every company has a different process and set of procedures when it comes to making games. This can serve as a guideline to what is widely accepted by many companies.
This general overall process is logical and generally works pretty well to develop games. As a game designer however, you will find that the overall game development cycle isn’t the same or in alignment with the game design process you will need to follow to make a great game.
A game design process is similar to the game development cycle for most people. Most game designers, yes even the working professionals, don’t have a formalized game design process. Whether they realize it or not however, most game designers do have a process which they follow.
So what is a game design process? A design process is a series of steps that must be completed to refine an idea for a game and bring it to completion. Whether the game is being designed by one person or a group, every concept within the game must be thought of, refined, questioned, verified, and solidified before it can be implemented.
As a designer, you control the content that goes into a project. You determine the number of features, mechanics, moves, protagonists, antagonists, special effects, and so on. Being realistic about what is going into your game is the first step in the design process. Making sure that everyone on the team understands as clearly as possible what is in the game from the start is the best thing you can do. Establishing a formal design process allows you to think about all aspects of the design and ensure that you cover all your bases up front.
You can have great art, great technology, and a great design, but unless you have unlimited funds, a proper schedule is the most important thing you can have on any project. Because games are often one-of-a-kind propositions full of unproven content and technical hurdles, they are notoriously difficult to schedule (which is one reason that so many games are late, late, late). Having a design process is one of the checks and balances with the reality of your schedule and the game design you are creating. With a good understanding of the process, you can not only schedule your own tasks, but help the Producer on the project begin to schedule the rest of the game realistically.
Every idea must get from the designers head and then somehow into the game. Every aspect of the game must be designed. Failing to design key aspects of the game could cause major problems late in the development cycle. Therefore developing a formalized game design process can be a huge advantage to you if you understand how to properly utilize it. Keep in mind that there is no right or wrong design process, but there are better processes which will work better for you.
While there is no right or wrong way to design a game, there are many different ways. This is both a blessing and a curse. It gives us lots of freedom, but makes finding the right process very confusing. This can also be made worse by the fact that many of the people who write articles and articles on game design, and speak about it at conventions have very strong opinions about what works and doesn’t work for them, but they tend to preach it as the only solution.
For some designers, the idea of a design process involves just sitting down and creating the game as they see fit, in a vacuum. Others try to create the design by brainstorming with other members of the team. Whichever way you generate your ideas, you need to agree upon the process by which new ideas can be implemented. Although some designers can conceive and control their projects by themselves, most need other people involved in the process to ensure that what they're doing is realistic.
So, if you don't have a process in place that helps make your ideas happen, it's time to think about it a little. You then want to make sure that the entire team understands the process and will adhere to it. It seems a little strict at first, but ultimately having a process ensures that you're making the best possible product.
It is a good exercise to read and hear about how other designers work and the processes that they use, but you have to be careful. I would encourage you to use a lot of common sense and restraint in throwing out your current process, if you have one, unless you’re sure that this new process that someone else is using is right for you, your team, the type of game you’re making and the environment you are trying to build.
Many different philosophies approach the best way to design a game. Every company, every team, and every project have different strengths and weaknesses that will also make one method more successful than another. This article shows you primarily one approach to game design, but it's not the only way and it's perhaps not even always the best way for you and your particular project.
Some designers hate the way large publishers work and the way big business works, so they will argue and rebel against my process until the bitter end. Some designers believe that game development has to be a totally organic process that you can't schedule because the game needs to evolve into its final form. Other designers believe that it's best to have a game designed by a single visionary, while still others believe in design by committee. There are a lot of different ways to skin the game design cat. Here's a glimpse at a few of the design processes which people use:
Some designers believe that it is impossible to design something and keep it creative. To put it bluntly, they are wrong. Jumping into a game and just making it won’t get you very far, unless you’ve done it before, the game is really simple, or it is some kind of a sequel. Even then, I still wouldn’t recommend attempting to not design your game ahead of time.
A bit more than not having a design, some people like to design as little as possible in the beginning. They may write a paragraph to a few pages of details and then jump into making the game. This isn’t much better.
Complete Up Front Design
On the other extreme side of the spectrum are the people who try and completely design the entire game before they begin making it. They may write hundreds of pages of detailed documents and plan out every detail, before they begin making the game.
A technology design is one which is one where a key feature(s) of the game are programmed first and then a game is made out of the feature. While every game needs technology, and even it has to be designed, a technology driven design is one where a programmer sits down and develops a cool feature or set of technologies and then makes a game out of it. Bloodwake for the Xbox is an example of a game where some incredible water technology was created, and then they figured out how to make a game using really good water physics.
Another approach for technology driven design is taken by a game like Dungeon Siege. These games were designed by designers with a strong programming background, and they first developed what they call the “Sandbox” and then see what they can make with it. This is where the developer creates a whole series of features, which all fit together, but they aren’t sure exactly how, and then once the technology is finished they try and figure out exactly what kind of game to make with it.
Visual design is the process used by many developers who work in what are primarily art houses. Many game developers whose upper management come from the art or film industry also use it. This process involves visually detailing the game for a very long time. In this process, there is a tendency to forget about game mechanics. I've seen projects designed with this method drag on for a very long time, only to produce impressive artwork without a real game underneath. One of the big problems with art-driven design is that the visuals raise expectations that, in many cases, are not supported by the underlying technology or game-play mechanics. In general, it is very easy to visualize a game in static storyboards or paintings (or even pre-rendered game-play visualizations) and very difficult to actually implement these visual ideas.
Munch’s Oddysee was highly driven by its need for a fantastic visual quality. These types of projects are usually designed or run by someone with an art background, or because the art is a very important aspect of the game. I have seen games which were close to a year into their Pre-Production phase, and all that had been done was concept art. No code had been written and no real game design had been done. While Art is a critical element to the game design, you need to make sure that it is kept in balance with the rest of the game.
A collaborative design process is one in which the entire team works together to develop the design of the game. Although in many cases every project is a team design, even if it has a lead designer, a collaborative design goes out of its way to include everyone in the process. Valve is a prime example of a company that uses a very collaborative design process called the Cabal. You can read all about it at www.gamasutra.com/features/19991210/birdwell_01.htm.
The Valve process involves including the entire team or members of the team in regular brainstorming and design meetings. The idea behind a collaborative design process is that everyone on the team is smart and has great ideas, so it's good to utilize this to get the best game possible. Unfortunately, everyone tends to have different ideas, so it can be hard to focus the project.
One of the biggest problems with a collaborative design process is that someone needs to be in charge and able to make the hard decisions. This process can quickly devolve to a design by committee, which doesn't work. Unfortunately, when you ask everyone's opinion, you're likely to get a variety of different answers, or else one person will dominate the group and keep others from talking. Whenever the entire group must decide specific issues, you can be in for trouble.
If the collaborative process isn't run well, you can run into a host of problems. In my opinion, even a collaborative process should have a leader who can act as a "tie breaker" to keep the team focused.
An iterative design is one where a feature, or maybe a few features are designed, implemented, tried, tested and the refined, before you move on to the next set of features. This design process can be similar to that of a balanced design, but tends to look at just a few features at a time and then make them fun, before adding anything else. This process is often driven by programmers, and is often used in strategy games where every new feature could possibly unbalance the game.
Iterative design can also be called Trial and Error Design or T&E design, as I call it, and it is most often done by programmers. Although this isn't necessarily a bad idea for some games, it can mean death for others. In a T&E design, you start with a small concept and then begin to program the game. The goal is to get the game up and running and fully playable as soon as possible. When the core of the game is working, you begin to add features and remove features as it makes sense. In other words, add a feature and see if it is fun; if it isn't, take it out and add another. Keep this up until the game seems fun overall. Designers who use this process typically do minimal, if any, formal game design.
Most early games and many arcade games were designed this way because the games were simple and easy to create. This was also often done because no formal design standards existed and because the person programming the game was often also the person designing it and possibly even doing the art for it. This made designing games back then a lot different than the way most games are now designed.
This design philosophy was used by Chris Taylor when he created Total Annihilation. Because an RTS is so data-driven, game-play balance is everything. Although this approach worked really well in TA, it didn't work so well initially in Dungeon Siege, and Chris quickly learned that he needed to do more up-front design work to design a good RPG. This shows that just because one technique works well in one application doesn't mean that it can be applied to every game design you might do, unless you're always doing the same type of game in the same genre.
A balanced design is one where everything is done together. It lies somewhere in between no design and a complete upfront design. It has components of artistic design, technology design and the other design processes, while finding the right balance between them.
Similar Issues in Software Design
It can also be helpful to study general software development. I strongly believe that there is a strong correlation between the game-design process and that of other software design. I believe you can learn a lot from other software projects, whether they are applications or even updates of an existing code base. The more I talk to people from other parts of the software industry, the more I realize that game developers' problems aren't unique. Therefore, I highly recommend reading articles on general software development, including Rapid Development, by Steve McConnel.
The process of game design is similar to normal software design in many ways. Many people think that making a software application is totally different than designing a game. Although it's true that games are creative and have their own set of difficult problems to overcome, a lot of similarities still exist between most software-development processes. All software projects require code to be written, involve deadlines, must create a product that is easy to use, includes a development and design process, must consider what users want, and includes an entire team of skilled people working on the project for years at a time. Designers can learn a lot from normal software development, which can help improve the process of developing games.
As you can see, there are a lot of different ways to design a game, and all of these different development processes will directly influence how you create your own design process. The entire process of creating games is very difficult. Without some kind of plan, you're never going to make it on time and on budget, unless you make severe compromises. It's important to adopt and understand some kind of design process if you hope to be successful.
Creating a good game design is a very difficult thing. It's not something that you can just jump into, but it's also something that is creative and that can't be overly analyzed. Having a process in place and developing a deep understanding of how you should design games will go a long way toward helping you design a better game.
What Does It Mean to Formalize a Document?
A formal design is one that follows a set of policies and procedures to help ensure that an adequate design is created for the project. If you don't follow a more formalized approach to design, you might waste a lot of time early in designing the wrong things or focusing so much on short-term issues that you put off the long-term problems facing your game.
This formalization is set in place as a way for you to think about every aspect of the game early, especially when it's time to set a budget and a schedule. People in the industry commonly do not work on critical components until late in the project, assuming that they will be easy. More often than not, this causes delays in the project. Never assume that anything is easy.
Formal design documentation is about planning your game. The better planned a game is up front, the smoother the project will usually go and the better chance it will have of actually being manufactured and distributed.
In an ideal situation, a designer should be able to work by himself for at least six months before anyone else even joins the project. During this time, the designer roughs out the design. When the designer has had time to solidify the basics of the game play, several other people should then come on board and help with pre-production. By the time the design reaches the end of pre-production, it should be fully formalized and fleshed out so that when the project moves into full production, a blueprint of the entire game will be available to the team. Of course, some aspects of the game won't be fleshed out yet, but the pre-production phase should answer as many questions as possible. Keep in mind that this is an ideal situation that doesn't always happen. Often you will have to work on projects that are already in full production and that have either no formal design or a really weak one that needs to be fixed.
The most challenging part of creating a formal design documentation procedure is that it needs to constantly change and adapt to every new project. It is impossible to create a set of rigid rules that are equally appropriate for every project.
By formalizing your design process into documents, you create a blueprint from which others can build the game. To communicate your intentions effectively, these documents must live up to certain standards of completion. The bigger the team with which you work is, the greater the chance you have of something going wrong with someone else's implementation of your design if it is not properly formalized.
By creating this document and saying that it is complete, you're endorsing the design. If your name and reputation are on the document, you're placing a lot on the line. You also want to make sure that the design you endorse is done right. The worst fear of a designer is to work on a project for an extended period of time with a large team and see the project cancelled because of bad game design. A lot of fingers can (and will) point in your direction because, as the lead designer, the fault is yours. I've been involved in helping a lot of projects that have come under fire late in the project's development for bad or unfinished game design. This problem is very common in the industry, and we must stop it by making sure that game designs are formalized and up to snuff.
So what separates a normal design document from a formalized one? A formalized design is one in which a set process is applied to the document to ensure that it is written to a satisfactory level of completeness. In some ways, every design is formalized, but if you're just writing down what comes to mind and are not thinking about the process and the implications, you're failing to formalize the document.
A formalized design is one that is planned out in advance. This requires that you have some prior knowledge in game design and hopefully some experience in designing the same kind of game because they are all slightly different. It also helps if you have a template of some kind. A formalized design doc doesn't exactly have precise characteristics that can be listed because it's always different. The process involved in the development of the document is more important than the specific information within the document. A formalized design is one done to a level that is satisfactory enough to allow you to easily and realistically develop a game based on the information.
The next two short examples show the difference between taking a loose approach and a more formal approach to writing a paragraph description.
Short Informal Design Example
Well, you see, in my game there are these guys, and they run around using guns and killing people. They have all kinds of cool weapons that shoot bullets, lasers, big flames, and missiles that explode. The player is a big guy who is in the Army, and he's fighting aliens who have all kinds of strange weapons.
Short Formal Design Example
Goal: This is a first-person shooter that has spectacular graphics and a bunch of great new features.
Game play: First-person shooter, similar to Quake.
Controls: Same as Quake. List here[el].
Weapons: Pistol, machine gun, laser pistol, laser rifle, bazooka, flame-thrower, grenades.
Story: Sci-fi story that pits the player against an alien invasion on a distant Earth colony on Mars.
The difference between these examples is that the formal example is often easier to read for the team, because they can find the information they need and get all of the details. The formal example also helps make sure that what you are writing is complete and precise. The informal example doesn’t sound as professional, which you need to try and be. Overall, I’ve found for my main design documents, it’s best to be quick and to the point, and as minimal as possible. You shouldn’t have to sell your team on the idea.
Sometimes it is necessary however to create multiple versions of your documents. You may find that people from marketing and management respond better to a more hyped up, cool sounding document, than one which is better suited for the team.
Using the Design Process
Every idea must go through some form of process to become a reality in a game. Understanding the path that an idea travels until it becomes a reality is important. You might start with an idea such as "The game should have four-player split-screen multiplayer." As a lead designer, you might be fairly sure that this is something you want to do, but you must also figure out all the specifics for it. You might then need to check with all the other designers to make sure that there is not some other ramification or pushback to doing it. When the entire design team thinks it's a good idea, you might need to check with the programmers to see if they can do it. After the programmers have signed off on the idea, you might need to check with the art department, to make sure that any changes required by that group can be done.
For some games and ideas, this might be all that is required. However, for more complicated or risky ideas, you might also need to have the marketing department, testers, and management signed off on the idea. Each one of these sign-offs is a necessary step in the design process. Either way, you need to understand that, as a designer, you can drive the vision of the game, but you can't control it: Other factors need to be taken into account before your idea can become a reality inside the game.
Most ideas are put into some form of a design document and looked at in bulk by whoever needs to sign off on them. Avoid trying to get buy-off on each and every individual idea from the entire team, unless it's a really big change in the vision of the game. No matter how you turn an idea into a feature, keep in mind that at some point you need to get others to buy off on the idea. Involving the entire team in the buy-off process regularly helps the entire design process greatly.
A design process can also help you identify several main needs in your game production. First of all, a process should help you keep track of all of your ideas. It can also help you track all of the features in the game, and help ensure that you don’t forget any key features of the game. As you can see, a design process is indirectly closely tied to scheduling. This is important to keep in mind since it’s difficult to make games without keeping the reality of the schedule in mind.
Making games is a team effort. A design process can help your team work much better. Every idea that must be made into a game has a process that it must go through in order to get made. This process includes getting the team to buy off on each and every idea you come up with. Programmers and artists must tell you that the idea is possible, while the Producer and others may need to tell you if it is feasible.
A design process also helps to ensure that nobody on the team is implementing ideas without your consent and buyoff. It also lets the other people on the team know that you're in charge of the design and that it's not okay for them to simply start changing things as needed. In addition to the project design process, each department should have its own development process, or "pipeline," for how things are implemented in the game. This helps keep proper communication channels open between team members and keeps time from leaking away from your schedule.
How you formalize your design process is up to you. Just knowing that you need to have a process may be good enough for some people and projects, while creating some kind of chart may be better for others. I like to create a spreadsheet that lists every feature in the game going down, with the across columns listing the steps of the design process.
Here are the different categories I track across the top of the spreadsheet: Feature, Feature Priority, Date Needed By, Stage feature is in: Idea, design buyoff, art Buyoff, Programmer Buyoff, Buyoff from Others, final feature approval.
Going down on the chart I track the features like: Interface Design, level design, units, weapons, etc. I then break down each of these features into as finite as detail as possible. Even if the features are unknown, you still should have a rough idea of what the total features for the game should be. This initial step can also help you try and help you figure out which features you should design first. This helps you make good decisions about what you are doing early on, which is one of the toughest challenges for a professional game designer.
I've found that creating a detailed design process spreadsheet serves several important functions. First, the spreadsheet acts as a place where I can put every important design feature. This helps me make sure that I don't forget an area. Second, by continually updating this spreadsheet, I can track the progress of every design feature in the game. This also allows me to globally track the game's progress against its ship date. In addition, the spreadsheet helps the rest of the team, which must buy off on a particular feature, know where the game is in the design process. Last, the design process marks the beginning of a schedule, which is really the most important part of the project.
How exactly you use the design process to improve your game is up to you. It may not be possible to capture all of the information you need to track in a single design process document. It may also not be necessary to even create these documents at all, but if you’re as anal and thorough as I am, it can’t hurt.
Earlier we talked about the standard development cycle.
Concept - Pre Production - Production – Post Production
Over time, we have begun to realize that this development cycle doesn’t work extremely well. Some of this has to do with the way games need to be made, while other issues revolve around stickier problems having to do with the way contracts are written and the current political scene of the industry. What it boils down to however is that once we commit to fully developing a game, it can be very difficult for some publishers to cancel a project.
One of the problems we are facing which is forcing this change is that the quality bar of games is dramatically increasing every year. Many developers are still developing games using the processes and standards of what was acceptable in years past, which is impractical in today’s much more competitive environment and higher project costs.
There are two different schools of thought when it comes to creating features and showing quality in a game. The first school of thought is what is called a “back-end development cycle” (see figure 4a) and it says that developing games, programming features and making great quality art is extremely difficult. Therefore it will take the developer most of the production cycle of the game in order to get all of the features working in the game, which won’t allow them to show what the finished game will look like until very late in the development cycle.
The back end development model is the most common model used in the production of games today. Only a single prototype is built and then full production is started. Because the entire game is not running early on, many problems are often not discovered until late in the development cycle. This causes delays and lots of changes late in the project, when it is the most expensive to run. Also, if a project is then discovered to not be viable until the end of production, millions of dollars have already been spent and often years of time.
The second school of thought is called a “front end development cycle” (see figure 4b) and is where you need to show the final quality of the game as early as possible in the development cycle. This can be very difficult to impossible for a new developer with no existing technology to achieve. This approach is now considered lower risk for a publisher and the developer. Because of the quality problems we are having as an industry and because of the lower risk factor, there are more and more people making a change to the front end development cycle and demanding to see what the final game will look like as soon as possible.
The front end development cycle is safer for a publisher because it allows them to risk less money if there is a problem and they need to get out of the project. The front end development cycle is used by many successful companies like: Naughty Dog, Blizzard, Insomniac, Nintendo and Microsoft. It allows them to spend more time at the beginning, in Pre-Production, making sure that we know what we are going to make before we jump into making it. Under this model, several prototypes are built, which prove all major concepts in the game, before the entire project is staffed up and becomes expensive to run. If a prototype is found to need more work, it can be easily and more cheaply thrown out and repeated or just completely thrown out with a lot less money being spent. With this model, costs do not start going up until the risks are limited. Later in the article I will get into more detail about what goes into a prototype, and how this process directly effects pre-production.
Finding the Process That Works for You
As you can see, there are many different ways to make games. Every company you work for will have its own way of making games. You may not have a choice on the process you use to make games initially. You may however be able to control how your team or small group works, so it will help you a lot to see how different people design and the advantages and disadvantages of each technique. Then, in the end, you can hopefully gain enough insight, experience and influence to build your design process and development process which works best for you.
You should formalize your design for a lot of reasons, and you should avoid a few things along the way. The biggest mistake I see all game companies making is not properly documenting their design ideas. So, the first step of figuring out how to formalize your document is to think about what would be best for you and the project.
None of my advice here will do you any good if it completely changes your project and it spirals out of control. You might not be able to stop your game development for four months while you say, "I'd really like to just think about this for a while do you guys mind taking a short vacation?" The advice in this article is meant to help you improve your process in an idealized situation, so don't expect to completely adopt a formalized document overnight. Some of my ideas will be immediately applicable to you, while others are food for thought or something to implement in the next project.
"Designing is not the abstract power exercised by genius. It is simply the arranging of how work shall be done." - R. Lethaby
The different parts of the development cycle which we’ve been talking about can logically be broken into phases. These Phases help identify key points in the game-development cycle. Within each Phase of the development process, certain design and development work is usually done. These Phases aren't always very well defined during some projects, however. The five Phases might also be too granular for some production cycles, so don't be afraid to break this down into some smaller steps and adjust your design process appropriately.
The main reason for separating the Phases of the design is that, at the end of each phases, there usually comes a time when you are waiting for other members of the team to finish some work and for some kind of approval from management to continue. This usually means that you are waiting for some aspect of the game to actually be created and made playable so that people can look at or test it. At the end of each of these Phases, there is a chance that the results won't be adequate and that you will have to repeat the stage or iterate the stage until it is good enough to proceed. When you understand the different stages a design goes through, you can begin to understand the phases for the work that you need to do during each stage.
What is a Design Document?
Everyone has a different idea about what design documentation should look like. I've seen designs for games as short as 3 pages and as long as 1000 pages. What matters is not how long your documents are, of course, but how clear and thorough they are. Every type of product and team requires a different level of documentation, so the best approach is to offer guidelines and let the game dictate the standards.
The most important thing to remember while creating your design documents is that they are what we call "living" documents. This can mean several things. First, the documents are always changing and are always being updated, refined, and polished. Second, many people tend to contribute to the document in some way, providing feedback and additional information through the life of the project. Finally, a living design document isn't just a collection of words and diagrams set in stone, but it is a flexible map representing every aspect of the design as it changes over time, acting as a warehouse of useful information for the entire team.
Creating a game is not a black-and-white process, so your design documents also cannot be rigid and inflexible. Game creation is an art applied to a science. When creating your documents, you might have to use your instinct, intuition, and gut feelings to come up with the initial answers to your problems. Sometimes you might come up with several ways that a problem can be solved. Because a design document is living, feel free to insert all of your ideas. In case one idea doesn't work, you'll immediately know what to try next. Also, by including your ideas and thoughts in your document, the rest of the team can read them early and might contribute to a healthy debate about the relative merits of your ideas, allowing you to solve problems on paper well before implementation. Letting your programming team see your ideas early also enables them to evaluate them from a technical perspective based on the way the core technology functions. Sometimes even the slightest game design change, that seems easy to do, can affect the entire core of the game. If the programmers know that there is a possibility for two different features to exist, they can make their technology flexible from the start, to implement your new idea later with less work.
For example, if you ask the question in your game: “Can the NPC’s in the game pickup and use different weapons?” Whether or not NPC’s use the weapon they are given or have the ability to change weapons is a huge architectural change. If a character just uses one weapon all the time, like a sword, then the actual model of the character can just have a sword as default. The game doesn’t really need to know the sword exists. Plus the animations can account for the character always having a sword. If you decide on this, and then later on decide that it would be cool if the character can pickup and use a gun, this will cause all kinds of problems. An in between solution may be that there are classes of weapons, stick (swords, clubs, etc), pistols, rifles, etc. Then, a character might be able to use a class of weapons, but not all weapons. Making this single choice will determine how the programmers design the architecture of the animation system and AI, how the models are built, how the characters are animated and how the game is balanced. Before you decide on any key feature, try and think about any possible changes you can foresee, what systems of the game will be affected and who it affects. Get the signoff of anyone who the design feature affects, so that you and they know it will work.
One of the biggest problems with trying to also keep track of all these other things arises in the way documents are formatted. Later I'll get into how to properly format game design documents that will make ideas in your document clear and easy to understand.
Another critical reason to properly design your game on paper is to allow you to create realistic schedules. We live in a time in which it seems to be acceptable to be late sometimes very late. Publishers and developers wonder why they can't make any money from a project that was a year late and doubled its expected production budget. There is no reason why projects should be late, and there is no reason for designers to live in perpetual crunch mode. If projects are properly designed and a set of good design documents is created, you should know exactly what you need to do up front and should be able to detail out a proper schedule. If you fail to design, you're failing to plan, and you know what can happen there.
You'll face many unknown questions when designing a game. Even with a formal design process, you might not be able to answer them. Get help early! Turn to other members of the team or outside resources to solve as many problems as you can.
Can You Over-Design?
There comes a point in every paper design in which the answers will just be unknown. If you design too much of the game before it is playable, you run the risk of designing so many features early on that aren't fun, and then you end up spending time implementing features and losing the soul of your game. It is very important to strike a balance between documentation and implementation. Some games beg for a completed design early. Adventure games and other very linear games are examples of games that have simple play mechanics but complex interactions between them.
One thing you will learn is that you usually can't just design a game from start to finish. This begs the question of whether you can over-design. I can say that it's important to design a game as much as possible, but a lot has to do with when you design.
Think of designing a game as a military operation. You don't want to just gather all your troops together, cram them in a plane, and tell them to attack. Although this does happen a lot and is sometimes necessary to win the war, it's not the safest thing to do. This is especially true if your troops are green. A good military operation requires proper training, practice, intelligence, and preparation before execution.
The military can do some practice before a battle, but until it knows exactly what the terrain and the opposition are like, it's impossible to plan the specifics of the battle. Game design is similar: You have to design a lot of general things early, which means making broad design strokes. Then when you learn what kind of war you're getting into, you will know more about how to refine your ideas and what tactics you will need to employee to crush your enemy. At this point, you might have the vision of the game pinned down and can start getting ready to go into battle. When you find out where exactly the battle will take place, you can practice it in other words, you can build the prototype before committing to battle. While drilling for the final battle, however, you might find out that a different plan is better than the initial one you created. This might require a totally different or even slightly different battle plan before attacking. Attacking the enemy or committing to the battle is the point at which you move into full production in the game.
Although this analogy might seem strange, it shows you that no matter how well you plan or how much you design, you still need to test things, try new things, look for problems, and evaluate the game design before committing to it. A bad game design will result in you losing the war or getting the project canceled. However, sometimes victory is bittersweet at the end of the war or project if there are too many casualties along the way. A poorly run or designed project might get out the door, but that doesn't mean that everyone will be happy at the end, when the game doesn't sell and everyone on the project is burned out and quits from frustration. You have to find a balance in your game designs. Designing too little or too much can both lead to problems.
Every game has some level of design documentation; the question is how much is right for you and this project. As a general rule of thumb, I expect that when laying out my design over the course of months, I will write a minimum of 100 pages. However, if you find your document hitting 500 pages, it's probably time to seriously re-evaluate what you're doing and the state your project is in. This doesn't mean that always writing 500 pages is bad, but if you've written 500 pages of design and still haven't started creating the game, you are probably in for trouble. If a lot of what you're writing is back story, character development, and other details that will help serve as a guideline for the game, maybe you're just working on a very grand and epic storyline within an RPG.
Because there is no hard-and-fast rule, it's just good to get into the habit of occasionally evaluating your design for the content that it holds. As soon as you find yourself writing text because you feel like you need to add more pages to the document, stop! It's time to figure out what information is relevant and what is just filler.
An Overview of the Design Process
So now that you understand that's it's important to have a good design process, you should first be sure you understand the entire game-development and design process. I want to take the development cycle we’ve been talking about and expand on it some more. This expansion fits well into the front-end development cycle I’ve been talking about, and helps refine it even further.
This elaboration of the development cycle may not be helpful for everyone on the team, but as a designer I think it is critical. As you read more of the article and begin to understand the big picture of game development, you will hopefully start to understand why this refined process is helpful.
I’ve talked a little bit about how scheduling is so important to game designers. This is actually a fairly controversial subject, since creative people hate to work on a schedule and would prefer to just do it the best that they can, no longer how long it takes. Publishers are often the ones to establish the Milestones and deliverables for a project. Most publishers don’t usually request design deliverables early on however, and leave this area very vague. It is very important that a designer stay on track and on time, since more often than not, any changes and slow downs the designer encounters will be amplified out to the entire team and project.
This more refined design and development process was the first step for me in trying to define what needs to be delivered and at what point in the project for the designers. Later on in the article we will get more heavily into how to more accurately and realistically schedule the design. For now just keep in mind that there are some reasons why this breakdown will be helpful to you.
I've identified 10 main stages of the game-design process for this article. These stages fit into the different phases of the overall game-development process. Because there can be different stages to a game design, and because stages are often repeated, it is important to separate the different stages and phases of the game design for this discussion. Keep in mind that there are key deliverables which will need to be created for each of these stages, which I’ll go over in a bit. Not every project will need to create every one of these documents or deliverables however.
I find it best that when you’re trying to establish a development process, that you create a set of standards so high that it’s almost impossible to reach them all. I’ve seen process documents from large companies that were meant to make everyone happy. In order for them to make a process document that outlined a process which was acceptable for every kind of game out there, they basically had to say “Do it however you want”. It’s impossible to create a process which will work on all games and at all companies. My goal is to always set a bar that is really high, define documents that may never need to be written, and to breakdown the process in as much detail as possible so that I have a goal to strive for. I would much rather have someone say that this document is unnecessary for their project for these reasons, than have someone never create the document because they never even realized that they should have created it. Some people will say that this approach is excessive, but if it gets you to think about the game development process and what really needs to go into it, then I have succeeded.
This breakdown is the best way for you to start thinking about the game development cycle as you’re getting into it, but this isn’t necessarily a formalized breakdown which the entire industry uses or goes by.
The Phases of Game Design
Phase 1: Concept
Stage 1: Concept
Phase 2: Preproduction
Stage 2: Vision
Stage 3: Definition
Stage 4: Creation
Phase 3: Prototype
Stage 5: Play
Stage 6: Refinement
Phase 4: Production
Stage 7: Expansion
Stage 8: Completion
Stage 9: Balance
Phase 5: Post-production
Stage 10: Conclusion
Of course, the Stage are similar to the Phases of the game-development process because they take place within the Phases. However, because they make up important substages of the overall design process, it's important to discuss them separately. Typically, each of the game-design phases is also a key milestone, with a specific design item that must be delivered.
This is an important point to understand. These phases aren't just random or arbitrary; they are designed so that you create your game in the right order and at the right time. Later in the article, I talk more about what it means to formalize your design and why you need to do it. These phases directly speak to this. You need to realize that each of these phases must be tied to a schedule and that you must hold to this schedule as much as possible. These phases also take into account that designing games is a creative process, so even if this seems rigid, you should hopefully understand at the end that this phase schedule is actually a very creative and flexible process.
Some phases include starting or finishing a major document, completing a series of smaller documents, and completing a proof of concept. I’ll briefly talk about all of the various documents you may need to create at these stages here, and then later on throughout the article I will talk in more depth about how to develop all of them. The design process is organized in layers, with each layer building on the one before it. As you'll see, creating a game is a bit like baking a cake.
The Proposal Phase of the project is the most informal phase of the project, when the initial ideas are coalescing into a game idea. Concepts are created, examined, and then thrown out. This is the stage in which all the seedlings of a game first take tentative root. At some point, the ideas become strong enough to write down and detail them. During this stage, a basic concept or "pitch" is created. Think of a pitch as a short summary of your game that you can use to get someone interested in your game idea.
Similar to the first stage of the game-development process, the initial phase of the design process is all about ideas. This phase doesn't have a great deal of formal process to it, but instead it requires a lot of brainstorming. The main point of the concept phase is to sift through a lot of ideas in search of a central "tentpole" concept that will become the basis of your game. To keep beating the cake analogy to death, this is equivalent to perusing the recipe article and picking your main ingredients. You might not know what kind of frosting or filling you want, but you had better figure out what kind of batter you're going to use.
The pitch doc is often one of the first documents you formally write. This doesn’t mean that it is the first thing you write, but once you have a good idea of what you want to make, you can start to create this document. This doc is more of a marketing or hype-doc as I call them. It’s meant to give people a high level view of your game idea, get them excited about it, and then ultimately fund or approve the next stage of the project. This document is often a short one or two pages. Keep it simple, and make it sound fantastic.
The concept doc is the first pass of the design document. It is where you start to write down your key concepts of the game. This document is for the design team to gain a better understanding of what the game is all about. It focuses on core gameplay, mechanics and what makes the game fun.
During this stage, the pitch is developed more thoroughly into a set of documents that describe the game in enough detail to create a prototype. This means that you are confident enough about your ideas that you can describe them in terms that enable programmers and artists to build a prototype and be fairly confident that it will work. The preproduction phase is often the shortest phase of the design process for many developers because there are always a million reasons why it is important to build the game now. This is usually the wrong approach to creating a good game, so I encourage you to fight for an adequate preproduction stage to allow you to properly design your game. The bulk of the game design should be done during this stage because good preproduction should lay a foundation that will make the rest of the project much, much smoother. By the end of the preproduction stage, you need to know exactly what you are going to build in your prototype.
In the vision phase, ideas are first put down on paper. You've picked out your main ingredient; now you have to create a recipe. Here's where your vision gets tested: Is there enough of a central concept to attract other great ideas, or is your idea of a role-playing game set in downtown Manhattan at rush hour just not cutting it? Throughout this phase, you will find yourself throwing out ideas and starting over many times. Eventually, concepts will start falling into place and you will actually write down a few recipes, asking people what they think of each one and what might make the cake taste better. I cover creating the vision for the game and the corresponding documents and steps involved in part 10, "Creating the Vision."
The vision statement is a tool that helps the entire team keep one central focus throughout the life of the project. A good vision statement will help the team clearly understand what it is that you are making, help focus the team members on a common problem, build cohesion among team members, and make it easier to make decisions about the project. A good vision statement helps clarify and prioritize the goals of the project.
A proper essence statement should tell anyone who is unfamiliar with your product exactly what it is in a very short period of time. This statement should include your vision and goals for the product.
During the second phase of the design process, most of the important details of the game are figured out, including the core concepts, game play, and general mechanics for the game. During this phase, you need to get your recipe down on paper and make it as complete as you canand that's not so easy when you can't actually taste-test anything yet. During the definition phase, you work on developing the creative vision of the game, which I cover in Article 10, "Creating the Vision."
The Creative Spec is the document where we start to get to the bare-bones of the game concept. This will be a working test model for the game. It may be redeveloped time and time again, but the Creative Spec. is the vision that will keep the game focused on its Essence Statement.
During the Proof stage of the project, it is time to show that your ideas will work. A lot of times this work is done by someone in marketing, but as a designer you need to help. This is the point where you need to thoroughly analyze the market and show why your game will succeed.
Competitive Analysis Doc
Doing research on your competition can take a lot of forms. You can analyze sales numbers, market trends, feature sets, reviews and a host of different information. Creating this document helps you thoroughly understand the competition.
Proof of Concept Phase
The proof of concept phase (POC) is the point where you’re ready to prove and show that your game idea is solid. This often includes building a partially working version. In the front end development model, this is the point where you iterate your game design several times if necessary, until you know if it is going to be fun and compelling to play. In the past, we’ve traditionally called this the prototype phase, but recently we have found that a “pre-prototype” phase is extremely helpful in refining ideas earlier on. A lot of projects get thrown from prototype into full production very quickly, so the more time you have to iterate early on the better.
The creation stage is the point where you’re ready to dive in and start writing the main design document for the game. So, now you’re ready to buy the ingredients for your project. This stage is where you take all the ideas you’ve created up until now and coalesce them into a nice cohesive design document which a game could be created with. This recipe has all the ingredients (characters, mechanics, storylines, and so on) described in detail. In Phase 2, you know the ingredients of your recipe, but you're not sure of the quantities of each one or how long they need to be cooked. In fact, to really make your cake, you're going to have to bake a few and adjust the recipe accordingly. During the creation phase, you must create the design for the game's prototype, which I cover in detail in Article 11, "Designing the Prototype."
Prototype Design Document
Any information that needs to be implemented in the prototype must be thoroughly defined now, so that the programmers and artists can actually start building the prototype.
Technical Design Document
There are two kinds of technical design documents. The first pass I like to do myself, working with the lead programmer on the project. Not every designer is technical enough to write this document. This document is meant to give the programmers an idea, often in non-technical terms, what the different systems of the game will function like.
The pre-production stage and the prototype stage are often combined. I like to separate them, though, because, without proper pre-production, it is very difficult to know what aspects of the game to actually implement. Skipping over pre-production is like building a house without plans. During the prototype stage, you build the first playable version of the game, including all the primary features and as many high-risk design elements that you can implement technically. The higher the risk is, the earlier features need to be tested. Because most of this work is being done by other people on the development team, a designer should spend his time during the prototype phase fleshing out the remainder of the design as much as possible.
At the end of the prototype stage, there needs to be time to test and iterate the prototype. I often add a short sixth stage (Stage 3b) between Stages 3 and 4. When you are happy with the design of the prototype, you need to bring the design documents into alignment with any changes that you had to make during the prototyping stage. Spending an extra month or so here can help a lot. The rest of the team can spend time bring any code that was hacked to make the prototype up to full production standards, and the rest of the team can begin hiring and ramping up for full production.
This is the point at which you bake your first little muffins, most of which will taste either under cooked or overcooked. Your carefully constructed design document has now been interpreted by engineers and artists to build a prototype. The game must be up and running to see how it plays. Now the ingredients get adjusted: Did you think that a drunken half-elf was a good idea? Whoops, controlling a drunkard is just not that much fun, scratch one gin-soaked main character. By continuing to bake muffin after muffin and adjusting the recipe, the batter improves quickly. This way, in case your terrific recipe produces shoe leather flavored muffins, you can fix it before ruining the whole cake.
Any features that are implemented in the game need to be evaluated. This short document is a way for me to basically analyze the game one last time before we move into full production. This is the last point where changes can be made in the design without some kind of potential impact on the project or loss of work. I like to identify all of the key features, make sure they are all necessary, and fun. This is also a good point to possibly run a focus group or usability test which will let you more formally analyze your features.
This is the phase during which you put all the final pieces together and flesh out the various design documents. It's time to butter the pan, make last-minute adjustments to the batter, set your timer, and preheat the oven. During this phase, you bring all your documentation into alignment with your final findings of the prototype design.
The design spec is the final design document. You take the prototype design document and begin to flush out all of the features. Every feature in the game should now be built into the document.
The design bible is the place I store everything in the game. This includes reference material, and anything not appropriate to put into the design spec. This can serve as a reference to other people as they work on different aspects of the product. Also, by putting stuff into the design bible, instead of the design document which only a few people will need, it can help keep the design document more focused and simpler.
The Story bible is where all the details of the story are kept. Many games often have a super complex story that includes many details which are unimportant to anyone but the lead designer and a few others. I often detail out parts of the universe or world which aren’t really necessary, but may play an important role to a sequel or for some consistency reason which I feel I need to understand. Don’t bore your whole team with all the details of the story in the main design document, but make sure they get enough of it so that they understand it.
The AI for the game needs to be designed. Similar to the technical design document, this is a task for a designer and a programmer. The programmers need to understand how the AI needs to work. AI in games is still rarely done well, and I think some of this has to do with the fact that designers rarely get heavily involved with defining the AI, and just end up using what the programmers create.
When you reach the production stage, you should know exactly what game you are going to build (although this rarely happens!). This is the longest part of the development process. The bulk of the actual work laying out and testing the game play is done during this phase, and this is the stage in which all the final aspects of the design are fleshed out. All of the final code and art is created during this stage.
In the expansion phase, a variety of other documents and secondary design tasks can be tackled, depending on the type of game you are creating. It's now time to start baking the cake. During this phase, you finish the last details of the design, finish creating the final design spec, and begin heavily testing the game for good game play. I cover most of these issues in Article 14, "Additional Issues and Elements"; Article 15, "Usability"; and Article 16, "The Design Spec."
Level Design Doc
The level design doc is the place where all of the levels are detailed out. This can include concept art, level layouts and other supporting material. It also isn’t necessary to put all of this information into the main design spec, since not everyone needs to know every detail about each level. This document should include information on how the levels are going to be built, the geography and architecture or layout of the level, the story and events of the level, locations of enemies, NPC’s and anything else that is in the world. There are a lot of details you usually need to know about a level before you run off and build it.
In this phase, you completely wrap up every aspect of the design and lock it down. It's now time to trim the edges of the cake and spread the frosting. Any remaining issues are now finalized. I cover the last few issues in Article 17, "Finishing the Design."
In this phase, your main goal is to make sure that the game is fun to play, while not being too hard or too easy. Now that the cake is fully baked, trimmed, and frosted, you need to put the candles on it to make sure that it's perfect. You shouldn't actually be creating any documents anymore, but you should be working to make the game fun and trying to get it out the door.
Post Production Phase
This is the final stage of the project that occurs when the game can be played end to end and is "content complete." During this stage, the game is tested for bugs and polished for release. By now, the designer's role is mostly over. Some projects might require a bit of play balancing or last-minute tweaking, but hopefully you have moved on to the next project by now.
This stage is the point of the project where you are usually code complete or finished with the game. What is important now is that you balance the game and find any bugs in it. Designers are usually involved with determining if design bugs should be fixed, making sure all the units in the game are properly balanced and that the game is playable from start to finish without ever stopping the player, stumping the player, or ruining the play experience. This is also where the pacing of the game can be adjusted.
In the final phase, an analysis and postmortem of the project should be completed so that you can move on to the next project, having learned some lessons. It's time to serve up the cake and see who comes back for seconds (or who gets sick to their stomach!). Do the people you work for ask for the recipe?
These 10 phases of the design process are important to understand. This is the concept about which most of this article is built around. Understanding the theory of how to create games is important, but understanding how to actually create the games is often more important. Designing games is an organic process, and understanding the different stages and phases of the design process and how they relate is very important. It's not good to just sit down and design a game without taking the idea on a journey to help define and refine it properly.
As you read through the rest of this article you will see how everything about game design will indirectly lead back to this process and you’ll learn that how you make games will become as important as what you design. You’ll then begin to see how everything fits together, and how the process of making games relates to all aspects of game design.
Hopefully by now the shear immensity of what you have to accomplish as a designer has started to set in. Hopefully this article will help you better understand the entire process and allow you to go into game development with your eyes wide open to the realities it poses. If you’re already in the industry, there is still a good chance that you don’t fully understand the entire process, which this article I hope will help clarify.
One of the biggest things that separates a good designer from a bad designer, or an experienced designer from an inexperienced designer is their ability to do the right things at the right times. Determining when to design a key feature, how detailed to make the design and how much time to spend designing the feature is truly a difficult task. There is no right or wrong answer to this problem. Each game will need different things done at different times and in a different order.
Since making games is also a creative process, sometimes it is necessary to follow your heart, your inspirations and your gut instinct. Sometimes you also just need to put ideas down when they come. If ideas are flowing freely and quickly, sometimes it is good to capture them before you loose them. However, if you find yourself struggling for ideas and hitting a wall on things you know you really shouldn’t be, then it is definitely time to move on.
When should you design a feature?
While there is no precise time to design a feature, there are some general rules and guidelines which you can use. If you follow the design process which I outline throughout this article, you will see that a lot of it is about designing certain sets of features. This can be important to follow, since it is an attempt to define which features need to be worked on first.
The biggest thing you need to realize is that you need to have a vision for what you want to make. This means that you need to understand what it is you want to make. You need to understand what it is you are making, what makes it special and different. You need to initial think in broad strokes, and the progressively refine your ideas and concepts into more exact specifics. Be careful to avoid defining exact specifications early on. If you find yourself figuring out exactly how fast a unit moves, how strong it is, and details like that in the beginning, this is unnecessary.
I have seen design documents from seasoned developers which were 50-100 pages in length. They outlined every unit in the game, every detail and number associated with the unit, every piece of equipment, weapon and such that was found. Every detail of the story was detailed out, the back-story and every important event was detailed. Yet, they didn’t know what kind of game they were making, why it was fun, or why people would play it. They didn’t understand or define the interface or controls for the game, which was a major problem in the kind of game they were trying to make. In short, they dove right in to the features, without knowing why they were doing what they were doing.
Overall, you need to figure out what is important to the project and focus on it first. A very story driven game like an RPG will typically need a lot more story work up front than your typical action game. Also, just because you are doing a game like a FPS or RTS which is very derivative (similar to another game) or a sequel doesn’t mean that you can ignore defining what the core of the game is and how it is going to play.
Spending Your Time Wisely
It’s very easy for a designer to do “research” for a very long time. Early on in the development of a game it is very easy for us to get wrapped up in checking out the competitors (hey, it’s a good excuse to play games for awhile, and is necessary). It’s also very easy to just get lost in thought for long periods of time. When you combine this with everything else which happens at the start of a project, it can be very easy to not get a lot done for a few months. While this can be nice, it doesn’t help your schedule.
It’s incredibly difficult to get started on a new project. Ideas have to come from somewhere. We often need to come up with ideas, which can be very difficult for all of us at certain times. It’s important to balance out this need, with the need to get the game designed on time or at least in a reasonable time frame.
You must also spend your time wisely during the day. Find ways to make your design process more efficient. It does nobody any good to be inefficient in what you do. Make sure you look at how you are designing, the tools you are using, how levels are being built and the steps that you must go through in order to get the job done properly. It is very easy to work very inefficiently and waste a lot of your precious time. It is good to always evaluate your methods and see if the time you are spending is well spent.
Wrapping It All Up
The game development cycle is an incredible complex thing. There are many different ways which you can make games. While the vast number of possibilities can be thoroughly confusing, there are really just a few viable paths with a few different variables in each.
An analogy I like to use is that the paths to game development are like a battlefield. There are actually two parallels here. Each possible path you choose can either lead to victory or defeat. If you’ve studied military tactics you will see that at first, when you look at the entire battlefield, it would seem like there is an infinite number of options ands paths. However, you only have a fixed number of highly specialized resources. So if you look at the battlefield, the resources you have and the dangers ahead, it becomes apparent that there are usually only one or two paths that will work. Some paths will work, while others will dead end or get you killed.
The point is, you must study, practice, train, plot and plan if you want to win the war. Once you understand the battlefield, the correct path to victory will become clear and obvious. The trick is in making sure you either don’t just jump into battle, and just run into an unknown situation guns blazing, loose the war by preparing too much or get so confused you never know what to do and you get killed without even realizing it.
The more you know about the various fields in game development the better off you will be. You are the General of the battle (well, hopefully at least a Major), and you must be able to know how to use your troops effectively. A general must understand his: army, airforce, armor, artillery, special forces, support and all different kinds of specialties. All of these must work together as a team to win. The better the General can see the big picture, the better he can truly understand exactly what his troops are capable of, the better he is. Also, If you only know the theory of battle, but never understood the current health of your troops, weather, enemy positions or morale, you also can’t be an effective commander. Likewise, a good designer must not just understand basically what the other members of his team do, but strive to constantly understand the condition in which they are in. This is mostly just common sense, and part of being a good manager or teammate, but it’s surprising how often it is really done well. SO, understand your team and the process, and you’ll be off to a running start when it comes to your next project.
Until next time,
Are you working in the games industry by chance, or do you see this as your calling and your career?
If you're in it for the long haul you'll be happy to know that there's someone who's been building video games for 45 years and still loves the craft and the industry. Don Daglow started programming games on mainframes in 1971, and at GDC 2016 he took the stage to share some key lessons he'd learned about staying productive and passionate over the course of his decades-long career.
Daglow's weathered the game industry's booms and busts; in this session he shared the keys to creative and professional persistence that have carried him for over four decades in our turbulent business.
One of the most distinct differences between good movies and great movies is how well they construct their respective worlds. This world building is what makes something like Tim Burton’s Batman great and Joel Schumacher’s Batman Forever utter crap. In the former film, the director has fully-realized the world of his protagonist, he has imbued it with character separate from the story’s participants, and made it a living, breathing entity that pulls the audience completely inside it. We aren’t just watching the film, we’re experiencing it, that’s how vibrant, cohesive, and distinct the details are.
In the latter film, the director bought a bunch of neon spray paint and black lights and reduced the world to a campy caricature, a parody of what it had been, and as such the artifice was glaringly obvious, reducing the audience’s ability to suspend their disbelief and immerse themselves in the film.
Using Batman movies to introduce a video on Hayao Miyazaki and Studio Ghibli might seem like an odd thing to do, but the following essay from Asher Isbrucker deals with the revered animator’s ability to efficiently and effectively craft fully-immersive worlds, and so good is Miyazaki at this that I couldn’t find a pair of contrasting examples among his work. The first thing every single Studio Ghibli film does is to establish the veracity of its world, even if that world is drastically different from our own. The distinct Ghibli style and the fervent attention to detail Miyazaki and his animators employ help to make even the most fantastical realms real, they create a tactile link to the world we already know, and allow us to make the imaginative leap while barely noticing the transition. It’s a fine balance and not one every storyteller can strike so directly every time. Yet like the author Gabriel Garcia Marquez, another master of magical and immersive realism, Miyazaki does, and it’s the key facet to the far-reaching impact of his films.
If you’re a Ghibli fan, a filmmaker, a writer, or anyone who enjoys great stories and how they come to be, you owe yourself this video.
We recently updated Paper Aircraft with improvements in gameplay, added leaderboard settings as well as general bug cleaning.
Download the game on IOS and Google Play! (Don't forget to rate us 5 stars!)
Our first mobile app is now on iOS and Google App stores!
This is a first part of a three game mobile project. The remaining two will release in 2017 with one game being a premium mobile experience.
Please check out the game below and rate us 5 stars.
This is a vital topic in game design: are you designing a game or you throwing one together? Yes, creativity is part of game design, but it only amounts to about 10% of the whole. The rest is more or less engineering: you identify problems and propose solutions, implement the solutions, test the results of those solutions, and so on. Scientific method is involved in your testing, and engineering is involved in your solutions. Occasionally inspiration and creativity are involved.
What game design definitely is not, or at least should not be, is trial and error. I'm using the meaning that was prevalent when I was young: guessing what might work, and then checking to see if it does. I now call it "guess and check", because there seems to be a notion today that trial and error is a form of scientific method. No, it's guessing. Game design is not a guessing game (though as in all other creative or engineering endeavors, sometimes you get a lucky guess).
Let me use an example from a beginning programming class to illustrate. While I was a college teacher I substituted for a teacher who was ill, in a programming class for beginners. Many the people were not going to become programmers, but everybody was required to learn some programming, which made good sense in a computer department. The students in the class already had a program to work on, a simple one, so I walked around trying to help in general, as their programs didn't work.
This is not surprising. Programming is very logical, and people often are not taught logical methods in K12. The proper response when the program isn't working is to figure out the program flow, identify where it went wrong, change the program, and test the solution. It works the same way in game design. Much of the purpose of playing a prototype is to identify problems and test solutions. This includes some intuition, and the solution might involve some creativity, but mostly it is logic.
But what did the students do rather than try to figure out why it wasn't working? They just guessed, changed the program in accordance with their guesses, and compiled/ran it again to see what happened. If that didn't work, they guessed something else. They were using traditional trial and error, guess and check, and they were frustrated, of course, because it wasn't working. I tried to show them how to figure out the logic and flow of the program rather than just guess.
Game design ought to be the same way; some people won't do it that way but I think it's the most efficient way, and it's the way that I like to teach people. Certainly different people have different design methods. Some design more from the gut than from logic. But it still involves hypotheses and tests: if you're actually designing something you are primarily using your brain in an organized way, I hope, and not just relying on inspiration.
Inspiration is not very reliable. “Inspiration is wonderful when it happens, but the writer must develop an approach for the rest of the time . . . the wait is too long.” (Leonard Bernstein, the composer and conductor - and writer.) Inspiration comes and goes. The more you treat the modifications of your game as an engineering problem, the more efficient you're going to be.
Some people may think of a game as art, rather than craft, and the more that you think of it as art, the more you might be inclined to rely on inspiration and intuition. So we might say that you're not designing a game, you're creating a game, though it's mostly craft once you have a playable prototype. A playable prototype is going to change a lot if you're doing a good job. Game design is not throwing things against the wall to see if they stick, which is what trial and error and error amounts to. It's "try this and see what happens. Then let's try that and see what happens." Some things might happen better than others, but it's a terrible way to solve a problem.
When I did the video version of this piece, I had not realized why this guess-and-check method might be common. Unfortunately, changes in game playing have led to much greater use of trial-and-error (guess-and-check) than in the past, and to puzzle-solving rather than problem-solving.
When I was a kid (more than 50 years ago) I searched for games that required you to think to succeed, but which were not abstract. The classic games such as chess and checkers were just too abstract, I wanted something that represented, modeled, some (possibly fictional) reality. Avalon Hill's wargames finally filled the bill for me, followed by Diplomacy (for more than two players).
With the advent of video games, gaming became a matter of athletic skills more than brainwork. No matter how well you could think, if you didn't have the reflexes and hand-eye coordination needed, you'd not be good at most video games. Video games were athleticware, not brainware.
Moreover, video games tended to be single-player puzzles, where there was an always-correct solution, owing to the inadequacy of the computer opponent. There was no substitute for human opposition.
When you play an opposed game of strategy, a game you can lose - which is usually a tabletop game - you cannot afford to simply guess at what to do. That's the road to Loserville. But now we have so many single-player and co-op video games, games where you can save the game at will. Many players try lots of different choices to see what works best, saving each one, and then use the best to move on to the next challenge. They don't have to figure out anything, they can just guess-and-check. In the extreme I know of someone who, finding a chest with random contents, will open it, save it, open it again, save it, and so forth, dozens of times, in order to get the best result. Ridiculous! Alternatively, some play games with online help open. If something isn't working well, the player will look up the best way to "beat" it, and continue. But it's these kinds of mentality that are the opposite of what you should be doing when you design a game. These mentalities amount to "throwing things against the wall to see what sticks."
Further, with the advent of Eurostyle games in the latter 90s, we entered the era of parallel competitions (which I called "contests" in my book Game Design), players all trying to solve the same puzzle. Even though there were usually several different solutions ("paths to victory"), they were still always-correct solutions. Many tabletop gamers became puzzle-solvers. People learned to look for the solutions, because they didn't need to worry about the opposition. Some games coming out of the Euro style transcended this, but most have not.
In designing a game, you do have, in effect, a "Save Game" option. Because you can try a solution you've devised, and if you decide it doesn't work, you can go back to the old way of doing it. But this takes a lot of time (one playtest often isn't enough to determine the success of a modification). Maybe you have lots of time to waste guessing at changes, but I certainly don't, nor does anyone who wants to design for a living.
Furthermore, knowing that there's always a best move (as it true of puzzles) is quite different than having to decide among uncertain alternatives, as in a typical wargame. Game design is problem-solving far more than puzzle-solving. There is rarely an always-correct solution in game design.
As a result of these changes in how games are played, many people who want to become game designers have learned the wrong ways of doing things, learned the wrong set of skills, to design games! Obviously, not everyone plays games this way (I don't, even when I play a video game), but the majority of gamers do.
I've seen the throw-against-the-wall method dramatically illustrated. Recently a beginning tabletop designer had his simple, multiplayer, 30 minute game, which involved cards and scoring only, playtested by players new to the game. The game had already been successfully Kickstarted but clearly it was far from done. Most of the cards were handwritten (not even computer-generated) for example. He also made the error of playing the game without having any rules with him (to test the rules as well). I asked why? His response was, he played it six or seven different ways, and was also changing it to satisfy backers as well, so he didn't bring the rules!
So here we had a game that was already Kickstarted and the rules writing wasn't being tested. When he said he was trying out a particular rule change my reaction was, how can you try a change when the rest of the game isn't stable? You're only trying to change one of those half-dozen ways to play. When you playtest, you playtest the whole game, not just the part that you're experimenting with. If the rest of it keeps changing, how can you evaluate the effect of one change?
My next question was, how are you recording the results of the playtest? He said he usually had a notebook, but not today, but he did have a laptop and he took notes after he was eliminated. (Yes, he played in the playtest, worse, without rules at hand. Bad Idea.) I can point out here that it was a game with player elimination, which is not desirable nowadays, even in a 30 minute game, and it was a scoring game yet he hadn't bothered to bring the scoring devices, so everyone scored on their smart phones. This is just sloppy. You've got to test the actual game, not substitutes!
I've talked about some of the obvious flaws like player elimination, but there was another one. It was a card game of direct attack on other players. There was no overall constraint on whom you could attack; the lesser constraint involved categories of who you could attack that is, your strongest attack in your hand at any given time could only be aimed at some of the players rather than any of them, depending on their characteristics. They had about five or six players in this game. I didn't watch the game much as I was doing other things. I asked afterward if there was a strong tendency to attack the leader, and the answer from the players was, yes. The game suffered from leader-bashing. I'm not sure the designer actually recognized the term when I used it, and only had a glimmering of why it was undesirable. People then started to suggest solutions to the leader-bashing, but the first, only allowing attack on adjacent players, would have pretty drastically changed a game that's already Kickstarted! (I'm often critical of Kickstarted games because of the nature of the audience, but I'm really offended by the idea of Kickstarting a game that is so far from complete.)
As an aside, why is leader bashing undesirable? It takes the strategic decision-making out of the game, you just attack the leader. It makes people want to sandbag (if they can), they don't want to be the leader until the very end. In fact, given the nature of the game, there was virtually no decision-making involved. You picked your strongest attack that could affect someone in or near the lead, and that was it. I'm not opposed to simple, even shallow, games, but they should still give players viable choices, the "horns of a dilemma" of traditional board games. This one didn't.
To continue with this egregious example, what we have in this designer is a case of somebody throwing things against the wall to see what will stick. He tried to playtest the game in various ways to see what seemed to work better. It seems to me to be trial and error in the undesirable sense. It also helps show that Kickstarter is often about ideas and intentions rather about an actual game. He had a little bit of the art for the actual game for a small number of the cards and that looked quite good, and probably helped the Kickstarter a lot.
So let me talk briefly about the proper way to go about this part of design, not just trying this and that, not throwing things against the wall. I use a fairly detailed diagram and a simpler version. This is an engineering design process. It's also something like project management, because each time in project management you're doing something that's rather different than what you've done before. I'll discuss this simpler project management diagram here.
The Plan is about you creating the game to the point where you have a playable prototype.
Execute is playing a prototype, first of all solo, then other people.
While a game is being played, you Monitor whether it's doing what it's supposed to do, whether it's going according to your plan, the vision you had in your head.
Control is when you monitor something that isn't going to plan, you do something to fix it, to make it work the way you want to.
Successful changes go into the Replan, where you modify your prototype. Then you go back to Execute and you play it again, and you keep going round and round on that, gradually making your game better.
I despise the word "iterate". Yes, this is an iterative (repetitive) process, but the word iterate, which is often used in video games, must be one of the ugliest words in the world, yet only covers half of what you're doing. You are modifying and testing, not just playing again and again. The scientific method is involved. To be termed scientific, a method of inquiry must be based on gathering observable, empirical and measurable evidence subject to specific principles of reasoning. A scientific method consists of the collection of data through observation and experimentation and the formulation and testing of hypotheses. (Wikipedia)
Game design is lot more than that, though. Unlike scientists, in most cases you have to rely on relatively few tests. (Nowadays in video games we see "open beta" testing, and testing after release, in order to increase the sample size and use statistical methods of analysis.) Unlike the scientist you're making changes in the design, an actual product, as well as experimenting to see what happens. Fortunately, this is usability testing, not scientific testing, and usability testing does not require a large number of trials. I strongly recommend that you check out the Nielsen Norman Group's website at alertbox.com, and read their articles. They are talking about web design usability, but most of what they say applies to game design, especially video game design where user interface is very important. We have user interfaces in tabletop games, but they have over many centuries settled down and don't change rapidly.
Being a literal-minded person, I don't venture into analogies much, but I'll try one here. This question of engineering versus trial and error (guess and check) is comparable to how people learn software or home appliances or electronics. Unlike most people I read the manual. It's amazing how much you can learn that way and it's far more efficient. But what most people do is a just dive in and try things, or they simply remain ignorant. I read the manual and find out all you can do (if it's a good manual) that most people who just dive in and try things are not going to figure out.
The engineering style of game design is like reading the manual, the trial and error style is like diving in and trying things. It's much less efficient, but it is easier, just like not reading the manual is easier, and we can apply this to games. I would rather read the rules to a tabletop game in order to learn it, unlike most people who would rather be taught. It may take longer, but I miss less when I read the rules and understand the game better when I read the rules, if they're good set of rules, than when somebody teaches me.
The major point to make here is that you follow a process that relies on solving problems you've identified. You also have to know what kinds of problems might occur, like leader bashing in a card game, and that's why I make so many of my videos to educate people about those possible problems.
Method is important, and trial and error (guess and check) is poison unless you have no choice but to use it. If you rely heavily on intuition or inspiration, more power to you, but that's not something that I want to teach aspiring game designers. If you think it's all about inspiration, I think you're dead wrong, any more than getting ideas is all about inspiration. You have to work at something to do it well on a consistent basis. You can't hope to be bailed out by random flashes of brilliance.
For today's post, I want to explore the trouble of balancing probability in your game.
Keep em Guessing:
Probability when it comes to game design and mechanics is when the outcome of an action isn't black or white. From 0 to 100, chance is the great decider instead of the player's actions. We can see this in any game built on abstracted mechanics.
While players can influence the probability in some cases, ultimately it will come down to luck. There are cases where we've won with a 20% shot, or missed with a 98% chance to hit (and yes, that did happen to me).
Probability's greatest role in game design is keeping a game from being predictable. Especially in strategy games and how you don't want the game to become one note. You don't need to have complex mechanics; as in Star Vikings' case. The game allows you to upgrade your characters so that their abilities will have the chance of performing a secondary effect.
The beauty of probability is that it can impact a game in powerful ways and make things exciting. When I spoke with Mark on Star Vikings, he talked about how he didn't want people stressing over making complex plans. With the probability of the game, a five turn plan can disappear thanks to one lucky or unlucky break.
The fact that you can't make plans is what makes probability so great. It forces the player to think about the moment or the immediate plan, instead of having the game bog down. In XCOM, all it takes is one lucky crit or missed shot to completely change your plan.
With that said, communicating the joys of probability to the consumer can be a nightmare for game developers.
"Your Game is Rigged"
Probability's other major role for game design is annoying the hell out of gamers. For every game that makes use of probability, there will be one person who says that the game is rigged against them.
Just as probability could mean win after win, it could mean lost after lost. The fact that the player has no real control over probability can make the game frustrating to play. It's hard to tell as a player if you're doing better because you improved, or that luck was on your side this time.
The more of an impact from probability, the greater the frustration can be. With XCOM, missing a 90% or higher shot can have huge repercussions for the player.
For many people, having their success be out of their hands can be a deal breaker for them.
With that said, good players can get around probability to some extent. Experts at XCOM know how to use the mechanics to mitigate probability's impact on their success. If they miss a shot, it's not the end of the world, and they never leave themselves in a position where it all comes down to chance.
However, getting players to that point is a feat in of itself.
Telling the Odds:
Probability is very hard to explain to a player due to its very nature. If you have a skill that increases your chance of doing X by 25%, how will you know that it is impacting the game? In most games, all we see is either the "yes" or "no" of probability. We'll never know if we were close to having something worked or a snowball's chance in Hell.
If you're going to use probability for making important decisions about playing your game, then they need to be spelled out for the player. In XCOM, the game breaks down your chance to hit based on your factors vs. the enemy's. You'll always understand why a chance is good or bad before taking the shot.
Another case was in Renowned Explorers International Society. In the game, you spin a roulette wheel to decide if you succeed in events. The higher your chance of winning, the more "success" points will be on the wheel.
Darkest Dungeon slipped up in this regard in my opinion. The game shows you the chance of hitting, but it never shows you why that is. If you have quirks or items that raise the chance, their impact will not be shown to the player. Even worse: The game does not calculate your chance of skills working on the enemy; it only shows your chance vs. their defense, and asks you to do the calculation yourself.
An interesting tangent would be the game Tharsis. The game combined rogue-like and board game design to keep things different.
The problem was how playing the game was literally left up to chance. One bad event could cascade into complete failure. While you could learn how to play the game, every major decision was built around chance.
The only way for players to learn how to use probability to help them is to know how to control it in the first place. Once again, if probability is only being used for item drops as in Diablo 3, then it's not a high priority to include the chance in the game.
But when a decision can either cause the player to win or lose, you have to tell them everything about their chances.
The Numbers Game:
Probability is one of those elements that you're never going to completely win with. You're always going to have someone like me who somehow will lose regardless of the chances. It's important to figure out how much probability is going to impact your game and balance it accordingly.
Good game design is about presenting the player with the means to affect or mitigate chance and not be completely ruled by it. While it may be exciting, having your game's final boss fight amount to nothing more than a coin flip can be frustrating.
As Vulkan spec has been updated few days ago, I think it might be interesting to look at how it compares to what Apple gives us with Metal. First of all, a disclaimer: this is mostly from an academic standpoint, I am interested to comparing the APIs, the provided fetures and their relative merits. I hope that some other people here who are curious about GPUs, APIs and API design could offer their thouhgts on the matter.
Some folks (me included) were quite dissapointed to learn that Apple is jumping the Vulkan bandwagon. After reading the spec, I think I understand why. And I am starting to believe this might be a very reasonable move by Apple. Here are some thoughts.
I think it should be fairly clear that Vulkan offers higher performance potential then Metal. Metal still does a lot of hand holding and behind-the-scenes management for you, while with Vulkan you are responsible for — literally — everything. And man they were NOT kidding when they said that the API is explicit. Its actually quite ridiculous how diffficult and detailed the API is. Of course, the nice thing is that you can optimise the resource usage very precisely in regards to the specifics of your engine, and you get quite precise performance guarantees. On the other side, you need to make sure that the data you use for a particular pass is in the device memory, which means juggling data around, recreating resources, breaking down yoru renderign commands and doing all kinds of weird memory dances. In fact, I can't imagine that many people will use Vulkan directly, instead we will see a bunch of wrapper libraries that abstract the tedious tasks like manual memory management and operation synchronisation.
At the same time — and that is the funny thing — Vulkan does not seem that much more powerful to me. Yes, it supports stuff like geometry and tesselation shaders, it has batched bindings updates, sparse ressources, command buffer reuse and atomic texture operations. But all these things can be trivially added to Metal (and I'm sure Apple is working on that already). The ressource binding model of Vulkan is more efficient, that for sure, but it is certainly not more powerful — it does not allow you to build more complex shader inputs than what Metal already offers.
The explicit nature of Vulkan might offer additional optimisation opportinuties to applications seeking to squeeze those 100% out of the hardware, but at the extreme expense of usability. Metal is a more casual API, which is very convenient to use and still offers very good performance (and performance guarantees) that will satisfy an overwhelming majority of applications, both for graphics and compute. With some extensions, it will basically have feature parity with Vulkan, and it can easily borrow some of Vulkan's optimisations without sacrifising ease of use (e.g. batched binding updates, reusable command buffers as well as synchronisation primitives). And let's be honest here — applications that really need explicit control like Vulkan provides are high-end game titles, which are not targeted at the Apple platform anyway (because they require really beefy GPUs, which Apple simply does not ship in their machines).
I think Apple might have lost the initial interest in Vulkan after they saw what it was shaping up to become. They were interested in having a convenient and efficient replacement for the difficult to maintain and erratic OpenGL. Vulkan is certainly efficient but I wouldn't call it 'convenient'. Its not an API that would draw developers (especially small-time developers) away from using OpenGL or encourage them to make more titles for OS X. Instead, Metal hits the spot exactly. I still would like to see Vulkan on OS X and iOS at some point (to make it easier for devs to port from other platforms), and from what I gathered, it should be actually possible to implement a Vulkan wrapper on top of Metal (which will of course lack features such as sparse resouces, tesselation shaders etc. — but thats is still perfectly legal according to the Vulkan spec). Personally however, I'd be much more interested in a Metal implementation on top of Vulkan to use on Windows/Linux.
As a rule, any skill related to game development is useful for designers to know because it helps them understand the limitations and possibilities of games and helps them work together more effectively with devs in other disciplines. A working knowledge of coding is usually cited as the main secondary skill for designers to have, but there is another discipline which can be particularly fertile ground for design: the art of character animation.
So why is that?
ANIMATION IS COMMUNICATION
In games, the player needs to understand what is going on in the game world and how it’s reacting to their actions. If there are non-player characters, the player needs to understand what those characters are doing and why.
This is typically solved with so-called "barks", NPCs declaring their status verbally (eg "Find the intruder!" "I lost him," and "It was probably rats"), or with abstract HUD indicators, numbers and icons existing outside the fiction of the game.
... but there is another way.
Animation is the art of communicating thought & emotion through moving drawings.
Expression change = thought-process
In the 1930s the animators at Disney figured out that you could show a character thinking by changing their facial expression.
“When the character has a new thought or has a realization about something during the scene, he will change from one key expression to another, with the timing of the change reflecting what he is thinking. If the thought process is a sudden realization, then it will be a quick change. If it involves a scheming action, the movement will be slower.”
(The Illusion of Life, 1984)
How a character moves and the expressions they make can tell you what that character is thinking and feeling at any given moment. It turns out people are really good at reading expressions.
Say what you will about memes, but they know how to quickly communicate an idea. Why not use such an effective tool for communication in our games?
I came across a quote recently by (noted IF developer) Emily Short that said:
"It’s pointless to simulate anything in AI that you don’t also have a plan for communicating to the player - otherwise they don't see how clever you're being or (worse) what is actually sophisticated behaviour winds up looking like a bug."
If the player can't read the AI's behaviour, it just seems random.
Now, you can solve some of that with dialogue (aforementioned "barks"), but why not animation?
This is, after all, a visual medium.
Reading their next move...
By showing a character visibly reacting to player actions and to their environment you signal their thought process, both their awareness of the situation AND what they plan to do next.
People (and creatures) look at things before they interact with them.
When you see a character looking at something and pausing to observe it means they've *noticed* that thing and odds are they are going to interact with it in some way...
By showing the AI's thought process, anticipating their action, you create an opportunity for the player to respond. This creates a more interesting back and forth than if the player is just having to react to seemingly random actions from inscrutable NPCs.
While all these tools can certainly be used for your traditional videogame scenarios, animation is especially suited to creating other types of interaction.
... like talking to people.
If you want to explore social expressions outside of text, you're going to need facial expression and body language... and not just in your cinematics! There is no excuse in this day and age for not having characters believably and *interactively* emote in-game.
Now, that's all very nice, but maybe your game doesn't have characters. You probably don't care about poses and facial expressions if you're making Tetris.
Animation remains seriously underused in games as a tool for creating dynamic interactive characters and believable reactive worlds. We could be doing more with this.
IMPRESSIONS: NEW YORK'S STARTUP SCENE
I spent last week in NYC for a Board meeting, some investor meetings, and a few presentations around town. If I were starting up again, I would seriously consider locating in the Big Apple, for a variety of reasons:
NY's startup scene is relatively mature. In contrast to other regions, NY's startup ecosystem has been developing for over two decades, since the days of "Startup Alley" in the late '90's.
There's money there. NY has among the highest concentration of wealth on the planet - though to be fair, a lot of it is in real estate and finance. Nonetheless, there's a solid funding scene with VCs like ffVC, First Round, Indicator, Union Square and others representing the seed stage. NY Angels and NYU Nexus round out the scene.
It's relatively cheap(er). True, an apartment in Manhattan will set you back at least $4k a month, but there are dozens of surrounding boroughs that are a sub-30 minute commute where you can live for half of what it would cost in SF or Palo Alto.
There's talent in spades. NYU and Columbia churn out top-notch technical talent, and I find that New Yorkers have an innate "hustler" vibe which startups need so acutely.
Overall it's a nice balance, IMO. Plus it's fun as heck.
I am going to say what most investors and many savvy entrepreneurs anywhere know but aren’t saying: just as there are zombie startups, there are zombie VCs out there and they walk among us. These are partners at venture firms who are 3-5 years into investing their fund, don’t have very strong results so far, and are struggling to raise new funds. These investors are not doing new deals, opting instead to use their remaining capital to double-down in follow on rounds with their existing portfolio, but in some cases they’re taking meetings anyway.
In the same way at a VC will often send you to an associate because they’re “too nice” to say no, zombies will meet with you and make you feel like you’re making progress on the fundraising path, but can ultimately wind up being a huge waste of time. Since you don’t have your own associate to pass them off on, you need to watch for the warning signs yourself and ruthlessly protect your precious time. You’re here to raise money and get back to work, not make friends.
Once you have identified that you may be meeting with a zombie it can be frustrating, but what you need to understand is that just like Bruce Willis in the 6th Sense zombies usually don’t realize they’re dead. Politely complete the meeting and update your spreadsheet accordingly when you get home. If they contact you to set up another meeting or request that you send over your deck it is appropriate to ask them how serious they are about doing new deals before you provide more information (decks get emailed around) or offer up more of your time.
If the investor seems angry with you for asking about their (lack of) recent Series A this is a red flag.
You have every right to do your due diligence on them. On to the next one.
The prototyping phase is critical in turning a high level idea to a plan with known content. It acts as a foundation of a project that gives it direction and scope.
It helps to answer the ‘unknowns’ of development. For our Enlighten VR showcase, these mainly comprised of:
Choosing the right VR platform is crucial in delivering the best demo experience. With Enlighten fully supporting all VR platforms, selecting one from the vast range was going to be challenging, as each has their own unique benefits and challenges.
Although Enlighten fully supports mobile platforms, it was decided early on, that we would not select a mobile VR platform, as our the team has already created a vast selection of them, including Ice Cave and CaveVR, hence the all the non-mobile VR platforms such as the HTC Vive Oculus Rift, PlayStation VR were instead considered for the new VR demo.
The Enlighten art team has a lot of pre-existing knowledge of developing VR demos on both the Oculus Rift and Gear VR that could be used for this showcase. It was decided early on that Unreal Engine 4 would be the engine of choice as it offers a high level of support for VR which would ease the development process.
Before proceeding with the prototype development, some things needed to be taken into consideration.
Both the Oculus Rift and HTC Vive presented unique challenges and capabilities for our final demo, so we decided to create some basic prototype scenes for each platform while exploring each major element.
Platform: Oculus Rift
Purpose: To assess the impact of light interaction and sound on a scene.
A simple room featuring various objects with two “firefly” lights flying around, changing colour and intensity. The user is able to control the fireflies’ light colour, visibility and movement, with the global illumination updating and responding to the actions accordingly. In addition to changes in light, the fireflies also emit a faint buzzing sound which can be heard as 3D spatial audio, giving cues as to their position and distance from viewer.
Behavioral responses added a great deal of character and personality to the fireflies. They turn red when they hit an object, evoking an angry emotion. With this approach the light sources themselves could be used as an effective means of emotional storytelling. Interaction with the fireflies was essential in adding an extra dimension of immersive presence within VR and spatial audio strongly supported the lighting in communicating with the user and controlling their attention.
Platform: HTC Vive
To further explore the impact of light while investigating different navigation and interaction techniques.
The user starts in a pitch black room, with nothing but a torch. They notice a locked door, which must be unlocked by finding a four digit code combination. Using nothing but the torch and navigator controllers the user must move around the room and solve a series of light related puzzles in order to obtain each digit of the door’s unlock code. When all puzzles are completed and the code obtained, the door becomes unlocked.
Trying to use light to solve puzzles in different ways showed how the use of light as a game mechanic can have a lot of scope and be effective. This is especially interesting as this is not something that is often utilised within traditional game development. It offered an opportunity for Enlighten to demonstrate a new approach to VR gameplay.
The original intention of this prototype was to investigate how a torch light would work and feel within a VR gameplay experience. Whilst this was initially achieved, it didn’t hold value without a purpose or context. As such, the team decided to create an ‘escape the room’ experience, using only light (or different features of the torch) in order to solve the puzzles. This purpose created a much more immersive experience.
During play testing, some people found the torch not particularly intuitive to use. As a torch is a real world object, it operates universally in the same way. As a result, any ‘real-world’ interactive objects created must replicate real-world functionality and behavior.
Interacting with the environment by having to solve environment based puzzles proved a very fun and immersive experience. This prototype used a greater range of playing space by making the user get down on their hands and knees, or stretch out an arm for example. This also proved a really great way of bringing in new and different types of fun gameplay, which is more unique to VR. Yet people’s preference for navigation systems seemed to vary. This means that for the demo it must be more intuitive, or give the user more flexibility of choice.
Platform: HTC Vive
Purpose: To explore the type of environment which compliments multiple dynamic light sources and attain performance statistics.
The user is placed in a dark labyrinth with a number of apertures. Armed with a glowing ball spawning controller and a shovel-like bat, the user must navigate through the environment. The balls glow when they hit a surface and illuminate the passage with various pulsating colours.
Batting balls around a level feels intuitive and satisfying as the physics supports this experience well. The level can be simple but needs three dimensional interactions with walls, holes and other props to create interesting indirect lighting effects. For example, moving through the labyrinth while throwing glowing balls behind walls to enable spectacular indirect lighting effects, especially on multiple levels, is very interesting. Varying the labyrinth design to enable more vertical gameplay (three dimensionality) or destruction elements would create more dynamic and challenging levels. Adding multiplayer support, scoring mechanics and different ball sizes would also make for a more engaging experience.
During the development of these prototypes, the art team gained valuable experience across all VR platforms. The Oculus Rift proved to have great benefits, including ease of set up (should we choose to later bring this demo to customer meetings) and great display quality. More work however needs to be done on the controller side and how it can be used effectively for our final demo.
The HTC Vive showed a lot of promise. Its display quality is unrivalled which is ideal for showcasing the importance of light in VR. The Vive controllers also provide unique interactive capabilities which the team can use to create innovative ways to play with light, leading to a more immersive experience.
As it stands, we are most likely to proceed with the HTC Vive as the target platform.
The prototypes have given the team valuable insights for the various key elements needed to be implemented, including controls, navigation, performance etc. These will be explored further in the second stage of the prototype phase as more work on the content side still needs to be done in order to identify the killer VR Enlighten experience.
Virtual reality is the most groundbreaking technology developers have got to grips with in decades, and we’re still just beginning to unlock its full potential. Presence. Immersion. These are the words used in vain attempts to convey the experience of virtual reality to those yet to try it for themselves.
Encapsulating the two concepts in VR projects you develop is perhaps the toughest challenge games makers have ever faced – but one that countless studios around the world have embraced with gusto.
But Vincent Martel, executive producer at Fated: The Silent Oathdev Frima Studio, warns that achieving this sensation is no easy task: “Everything in VR is so fragile. The smallest thing can break the immersion and when you’re trying to generate emotions, immersion is key.”
Triangular Pixels’ creative developer Katie Goode agrees: “In order to keep players feeling as though their world is real, you have to allow them to interact with it in all the natural ways that humans can. As soon as players try to interact with something as they do in real life and it doesn’t respond, the immersion is broken.
“The environment and objects within it don’t have to be realistic, they just need to be able to respond and their behaviour be consistent to the world you have created.”
THE INITIAL IDEA
Developing for virtual reality is not something you can dive into with nought but good intentions and a winning concept. Studios should be prepared to spend a considerable amount of time prototyping their ideas – and even shunning anything, perhaps everything they’ve ever learned about games development.
“Throw away everything you know and start over, approaching each new problem as a whole new thing,” advises Adam Orth, CEO of Adr1ft dev Three One Zero. “It’s one of the biggest things that makes VR awesome for developers. You have to constantly try new things and fail spectacularly at them – that’s where the good ideas come from.
“Even the most mundane in-game action such as opening a door becomes a challenge you have to think about from a whole new perspective.”
Goode adds: “As developers, we’re also experienced gamers and can see what works and doesn’t due to years of both making and playing games. When it comes to VR, no developer has that kind of experience yet. The kits haven’t been out for 20-plus years with countless examples of similar gameplay to call upon.
“What this means is that we’re often having to look at the limited pool of current experiences, recall how humans tend to behave in real life, and go with our guts to what seems like it will be fun. We have to always test our theories.”
Peter Pashley, head of development at Ustwo Games, stresses that both prototyping and usertesting is essential to honing your VR concept because it’s “impossible to tell how well a feature works without trying it on a range of other people”.
“In building Land’s End, we were constantly surprised by how our assumptions did not work as well as we expected when we tested them in VR,” he says. “We also found there was a huge range of unpredictable reactions from different people. So you need to test things frequently, on device – and not just the dev team.”
Willans suggests devs reign in expectations and keep their concepts high level until they’re able to try them out properly in VR: “As soon as the initial idea has struck, open up an editor and place some assets in a scene that even remotely represents the one in your head. It will inform all critical choices you make and avoid the pitfalls of applying traditional design methodology to a medium with a work-in-progress rulebook.”
Testronic’s head of VR testing Julian Mower offers some key learnings on how to ensure your title performs correctly:
"We have recently concluded testing on one of our first VR titles, with it successfully passing submission for the PSVR platform on the first attempt.
"During testing of both this title and other games on different HMDs, we learned some very interesting things. Firstly, when talking strictly about Functionality and Compliance testing for VR titles, the differences in how to test and what needs to be tested are minimal when compared to ‘normal’ games. Indeed, certain aspects of testing can become easier in VR when testers navigate a game environment by way of a camera fixed to their heads.
"Audio testing is an area that is often given too little focus in QA, but with VR concepts such as attenuation, radius can be immediately perceived due to a first-person perspective.
"The same is true for camera collision within a VR title, as the tester is operating with a heightened sense of awareness and will perceive risk factors much earlier. If your game dictates that the character is able to jump or crouch/crawl, then you can definitely expect testers to jump/crawl to replicate the action.
"Due to the above, exploratory testing can be a more efficient method than scripted testing when it comes to VR games. Whilst the latter is still essential, the narrower remit of most VR titles allows more time per area to check all possible interactions."
SEEN THROUGH NEW EYES
One of the earliest considerations for VR devs will be the art style. Since the medium requires a game to be rendered twice – once for each eye – achieving realistic graphics without affecting performance is tough. But then some may argue that anything other than a realistic style defeats the purpose of VR and makes it difficult for users to believe they have been transported to another world.
Mindfield Games CEO Ville Kivistö stresses that the “art style should be chosen by the need of the product”. His studio’s first VR venture, sci-fi outing Pollen, pushes for realism and highly-detailed graphics, but his team also have a more cartoonish project in the works.
“This is because the second game’s design requires a much more vibrant and casual look and feel,” he says. “Immersion can be achieved with any sort of graphics, realistic or not – just as long as the rest of the experience is done well enough.”
Kirill Yudintsev, creative director at War Thunder dev Gaijin Entertainment, adds: “Gamers’ imaginations are usually very vivid and virtual reality helps to expand it even more. Realism probably gives you more empathy. You can draw a parallel between what happens in the game and what you experience or see in the real world.
“In War Thunder when you are in the middle of aerial battle and you can see your teammate from your cockpit, his plane on fire, about to crash at any moment – it wakes up your feelings. You remember what you’ve read in history books or seen in movies. That makes you empathise with him stronger than if he was just a robot or cartoon.”
Willans believes there are arguments to be made for both styles, instead stressing that consistency is paramount: “If I’m in a highly stylised world, I expect that any visible parts of my avatar would match that style. I’m sure there’s also a case to be made for a Who Framed Roger Rabbit approach to mixing media, but right now I think we’re seeing great results from fully embracing the fantasy of leaving our real bodies behind.”
Martel points to his own team’s Fated – a narrative VR adventure with visuals reminiscent of animated films – as proof that you can make experiences more engaging with a stylised look.
“The style we chose proved to be right for both game performance and the ability to connect emotionally with our characters,” he explains.
“Hyper-realistic characters in VR are often creepy and a lot harder to connect with. A more stylised world is also usually a lot more colourful and works surprisingly well in VR.”
Pashley maintains that the current limits of the technology means there is “no such thing as realistic VR graphics”.
He continues: “The mind expects much higher fidelity in VR and even the most state-of-the-art graphics engines can’t deliver realism that fools the eye. Immersion doesn’t require photorealism, but it does require not breaking the rules of the place in which the player thinks they are.
Motion sickness is, of course, the caveat to virtual reality’s mighty promise. It’s the demon VR devs fear unleashing as they delve into the possibilities the technology affords. While we have learned valuable lessons in the past few years – maintaining a high and consistent framerate, avoiding unexpected acceleration, and so on – there is still much to learn as the games industry targets a wider demographic.
“People have a wide range of tolerances when it comes to motion,” says Willans. “The most common reports of motion sickness come from passengers within vehicles, but those sensations are not reported when the same person is actually driving the vehicle. Focus of attention through direct control is a strong factor in such circumstances.”
Yudintsev adds: “The reason for motion sickness in real life is that the signals your brain gets from your cerebellum do not match with what you see, like acceleration or gravitation. The same thing happens in VR.
“Focusing on the horizon or at far away objects can reduce any symptoms of motion sickness while driving a tank, an aircraft or a ship. Luckily, you always need to do that in the game.”
Simon Gardner, CEO at Climax, adds that his team were often warned that a concept or mechanic would trigger motion sickness, but when they prototyped the idea they found it actually didn’t affect people.
“Avoid what we call rollercoaster moments,” he advises, thinking back on everything else his team has learned. “It’s also critical to avoid any lag and framerate drop – this can make people feel nauseous very quickly when the world they are seeing is not behaving in the way their brain is expecting it to. Keep the framerate as high as possible, try not to drop any frames, since that will result in a worse experience and increases the chance for motion sickness.”
Orth added that, providing the framerate is high enough and the player’s gaze is never controlled, devs can push for that sense of inertia that truly brings players into their world.
“For Adr1ft, we embraced the simulation aspect of being an astronaut and fully went for it,” he says. “It’s akin to a rollercoaster – you expect to feel a little of that. We did a lot of work to make sure it was as comfortable as it could be, but it’s not for everyone. I personally don’t have any issues. I can’t go on a rollercoaster in real life, though. I get very nauseous.”
The danger of motion sickness goes hand in hand with movement in VR, particularly when that movement is controlled directly by the player. Since inputs are becoming wildly different to traditional games, devs have to consider fresh approaches to movement.
At first, VR devs relied upon the conventional gamepad but the advent of motion controllers has combined stick and buttons with one-to-one gestures. And a good thing too, as Force Field VR’s Martin De Ronde says gamepads aren’t as intuitive as you might think.
“Players can press buttons without having to look down whilst playing Call of Duty,” he says. “But now they struggle in VR when they cannot see the controller. Our mantra is the fewer buttons used in VR, the better. It also adds to the immersion if you are not constantly reminded that you are holding a joypad.”
Fierce Kaiju’s Paul Colls adds: “Motion controls in VR are the holy grail of gaming. They allow you to reach into the worlds we create and interact with them. It gives developers more options, having a representation of your hands in the game can allow you to feel more agency within that game world. We’ve seen people literally slapping ammo clips into a weapon.”
Goode agrees, adding that “there’s no going back after hand-tracked controllers”. However, the devices are only as good as the input schemes that make use of them. You also have to predict how players will expect to use them.
“As programmers and designers, we need to deal with the many different ways people pick up and use objects,” she says. “Take a screwdriver as an example. If we asked players to use a powered screwdriver, they would hold it to the screw, and press a button. When we ask players to use a manual screwdriver in Unseen Diplomacy, we’ve seen players do a Wii-waggle, twist their wrists back and forth, or actually try and use it as a real screwdriver.”
Paul Colls , creative director at Viral dev Fierce Kaiju adds: “Traditional stick or yaw control is not well suited to VR, so new methods of traversal are required. Fortunately there are some strong examples out there. If possible, look at ways to tie the movement up in the narrative, mechanics and visuals – this will help to make the project feel more grounded and cohesive.”
Force Field VR’s CCO Martin De Ronde points to Damaged Core and Budget Cuts as prime examples of Colls’ point. The former sees players hacking into different robots and cameras to see the world from their perspectives, while the latter uses portals in a fashion similar to Dishonored’s Blink move.
“Both create a contextual wrapper around the mechanic of moving around in VR without making you motion sick,” he says. “Not only do they do it in a believable way, they also manage to turn the feature into an actual interesting mechanic, opening up tactics.”
Meanwhile, Land’s End by Ustwo Games shuns such rapid jumps in favour of a system in which players click on pre-set points in the environment and the camera casually wanders to the chosen destination.
“Some people think that teleportation is the only way to move around in VR, but in our experience it very quickly disorients the player and ruins their sense of place, which is key to immersion,” says Pashley.
The movement mechanic of Land’s End is also a prime example of how developers need to design their VR environments around their traversal system. After all, there’s no sense architecting incredible levels if they are difficult, perhaps nauseating, for the player to explore.
“The only way to create successful environments is to iterate their design alongside the way that you move around them,” says Pashley.
“The points that you can move to in our game are pre-ordained, so it was critical to design the environment so that these points felt natural, were easy to notice, didn’t feel repetitive, didn’t involve uncomfortable trajectories between them, didn’t take too long to get to and so on.”
Orth adds: “Walking down a hallway and opening a door in an FPS is something developers and players know how to do. Doing that in VR is very, very different from every angle and all of that has to be considered into the overall level design. I have to reach out with my arm in the physical world to grab a virtual knob, twist it and pull the door open so I can walk though. That’s a complex thing that needs to be carefully considered from many new points.”
Mindfield’s Kivistö says his team had to redesign a level after they found a seemingly simple piece of architecture caused motion sickness.
“We had a circular staircase,” he explains. “While iterating our movement, test players got nausea after walking these stairs. Quite soon we found out that players moved up the stairs too hastily or too many times up and down, doing movements that would cause nausea even in real life.
“It’s just too easy to forget that in VR you’re missing all the feelings of acceleration in your body. So we had to replace the circular stairs with a regular straight ones.”
It’s not just the grand concepts like traversal and level design that require a unique approach when it comes to developing for virtual reality. Even designing your UI and presenting basic game information clearly will be vastly different from traditional screen-based games.
“A traditional style HUD would likely need putting into a helmet or cockpit,” Colls offers by way of example.
“You can have fun with this, though. Think of ways you could build the information required into the world, on control panels, weapons or even the characters themselves.”
Camera is also a crucial consideration. While the vast majority of VR games are played from a first-person perspective, that doesn’t mean their development is synonymous with the first-person games of the past.
Equally, some developers are experimenting with the possibility of third-person cameras and the impact these might have in VR.
“With third-person VR games there is less control over the camera, so level design is different from traditional third-person games,” explains De Ronde.
“We are currently working on two games where we have made the explicit choice to go for a static camera and build a game around that. Not all games or genres require immersion, especially third-person games. Yet they can still be introduce lots of interesting new takes on the genre as a result of VR.”
Oculus has proved this with virtual reality 3D platformer Lucky’s Tale, which controls much the way you would expect a Mariogame to but positions players directly within the level itself, watching as Lucky leaps between platforms around them.
Gardner’s team at Climax has also dabbled with this: “We’ve made third-person VR games with a character moving through levels using a camera to follow them.
“We’ve avoided having tight bends – 90-degree turns into side corridors, for example – because having a follow cam suddenly sweep around a tight bend makes people feel nauseous.
“We’ve had to design levels to either be far more linear with gentle curves to create a smooth follow cam experience, or have the avatar move through more open spaces where the player can easily follow their character just by looking left or right.”
Virtual reality opens itself to all manner of possibilities in terms of how it gets players engaged with your games. No longer do they sit there mindlessly pressing buttons – now they can physically perform in-game actions like aiming a gun, sword fighting or even opening a door.
The majority of virtual reality experiences – particularly those designed for motion controllers – require physical activity from the player. But not all users will be able to duck, weave and crawl around.
Triangular Pixels’ Katie Goode says despite the ‘assault course’ nature ofUnseen Diplomacy, it has still been developed with accessibility in mind.
“Physically disabled users can still play the game – and this goes beyond just button remapping,” she says.
“Many players cannot crawl around on the floor due to either unseen disabilities, old age or even being in a wheelchair. For those players, we had to create variants which were wheelchair-friendly, with widths of spaces being the width of a chair, having tools on a table rather than spawning on the floor, and making sure that lasers don’t go too low for those players.
“This wasn’t a small amount of work, and we would not have needed to do it if players were just in a cockpit, but it greatly opens up our audience.”
While it’s important to ensure your game is accessible, devs should still feel free to experiment with how active they want players to be.
“Unseen Diplomacy is one of the most active VR games available, with players being asked to crawl through vents, roll under and dodge past lasers and running between points – while actually having to walk themselves around a large environment,” says Goode. “Although, I can say for sure that more active games are harder to develop.”
Alternatively, the required level of immersion in your virtual world may require a more sedentary experience. Seated players will soon forget that they’re sitting on a nondescript chair if they believe they’re in the pilot’s seat of a starfighter.
“Designing a cockpit-based game is a little easier, because the player is contained and restricted to a very specific and limited set of abilities,” says Orth. “It allows you to control the experience a little more and has the ability to reduce motion sickness due to the static HUD and geometry that’s always onscreen, moving with your gaze as a single object.
“This allows the player to have a visual point of focus to stick to during the experience. Unfortunately, most cockpit-based games also are built around flying something, so there’s a balancing act there.”
Either way, there is a potential obstacle that no non-VR developer has to concern themselves with: unpredictable player movements. In a conventional game, users may try to break the mechanics or limits of the world but will do so through a more limited, pre-set control scheme. Motion control-equipped VR users, meanwhile, can move in any direction physically available to them, and your game has to be prepared for this.
“The player can – and will – look anywhere at any time,” warns Gardner. “Use camera target triggers to launch special events when the player is looking in a certain direction rather than just walking in to a trigger as they might miss something important.”
Goode advises: “Create systems, rather than scripting individual actions. Give objects properties, try to program them in a way in which seems natural in real life. Our game has big rocker switches which react to any physics collider that presses them. This means players can use a broom they find, reach through lasers, and press the switch – something we only found out watching a Let’s Play video.”
Herein lies another secret to achieving the level of immersion we all hope for in virtual reality: a world that reacts to you and your actions. Frima’s Martel says this even extends to seemingly minor details, like eye contact with NPCs.
There's a huge range of unpredictable reactions from different people. Test things frequently.
“You need to build a very good ‘look-at’ system,” he explains. “You don’t want characters to stare at you without blinking when you’re talking to them. That would be creepy. You need ‘natural’ eye movement and blinking. NPCs should also be aware of your presence, or you’ll feel like a ghost.
“You also need to create a lot more content. Someone can decide to look around when they should be focusing on the action right in front of them. There’s a lot of stuff in Fated that nobody will ever see. For example, in our cart chase scene, there are very few reasons to look behind, but if you do, you see the other characters reacting to the scene.
“While it is very important to steer the player in the right direction, restricting actions and movement too much can also shatter the sense of presence. At some point you need to assume that the player is willing to ‘roleplay’ a little. Sure, they can walk away during a conversation and miss an important piece of the story, but people don’t normally do that. Don’t ruin the experience for everyone by locking the controls just because one person might do it.”
De Ronde agrees: “Many players ‘maintain’ the immersion themselves. We have a game where you are on top of a tower and people could easily step off without falling, or in other areas reach their arms through the walls, but they don’t. It doesn’t help them and it detracts from the experience. I guess it’s similar to playing a traditional RPG and constantly pressing the jump button. People don’t usually do that even though they can whilst for example chatting to NPCs, cause it breaks their experience.”
Kivistö adds that Mindfield made the screen fade to black everytime Pollen players did something the game wasn’t designed for. Rather than breaking the immersion, users soon learned how to avoid triggering this.
Another unpredictable factor for developers is play space. While Unseen Diplomacy is designed for a specific area at events, there’s no way to know how much room players have at home.
Colls suggests implementing alternate control schemes to account for this: “If you take a room-scale experience where you are supposed to physically walk around, how would you do that on a device that is unable to do room-scale?
“Different control options allow the players to move around that space without walking around. It also means your game can be adapted to various HMDs, reach more people and potentially make you more money.”
When you think of the investments made in the medium over the past few years, it’s no secret that many believe VR is the future – but it’s crucial to bear the future of VR in mind. While the technology continues to amaze those experiencing it for the first time, as it becomes more widely available that initial excitement could wear off.
“In my experience, ‘presence’ is quite subjective,” says Colls. “Experiences where I once felt ‘presence’ don’t make me feel so in awe these days.
“Ultimately, presence is about building a convincing enough experience so that the player is fully immersed in the world that you create. Ensuring you have a slick, well crafted project will go some way in helping ensure that the illusion doesn’t slip, then people are perhaps more likely to get that connection with your title.”
Immersion can be achieved with any sort of graphics, as long as the experience is done well.
Fortunately, there is a plethora of VR tech demos, experiences and full products – led primarily by the games industry – to learn from.
“Don’t ignore what the VR community has been sharing over the past few years,” urges Goode. “Take it in, evaluate it, implement it and see for yourself why we’ve been saying these things by testing your ideas on others. Then try to do something new.”
Three One Zero’s Orth concludes by reminding devs of the end goal: mainstream VR able to transport the broadest possible audience into new worlds of entertainment.
“If you want to do a big virtual reality experience where the goal is to penetrate a mass market, you may want to guide the player and treat the experience as casual rather than hardcore,” he suggests.
“It’s important to remember only a tiny fraction of the potential VR audience has ever even seen a HMD in person, much less tried one out. Most of these people might not be gamers either, so the interactivity has to be simple, intuitive and universal in order for anyone to grasp an interactive experience, let alone VR.”
One final but crucial topic of debate in VR development is how long a play session do you design for?
“For player onboarding we offer shorter, less intense scenarios,” says CCP’s Andrew Willans. “But our game modes range from a two-minute free roam round an asteroid field, to a 20-minute action-packed fight versus a capital ship. Some of our sessions are up to three hours. Of course, there is some downtime between battles to allow players to catch their breath.”
Frima Studio’s Vincent Martel says the five acts of VR adventure Fated weigh in at around 20 minutes each, with players able to take a break in-between. Fierce Kaiju’s Paul Colls says Viral’s stages were designed to be small so players using the Gear VR touchpad could have a rest – but he believes they will want more.
Climax’s Simon Gardner adds: “Research shows that average VR gameplay sessions are up to 45 minutes. Our first games had levels of three to four minutes as we thought that players would get fatigued quickly – but they don’t.
“We’re now designing games that cater for longer sessions. I think seated gameplay, with games that have a gentler pace to them – like an adventure game – are a great fit for longer VR gaming sessions. This is something we are exploring right now.”