My method of game development usually consists of the gradual unfurling of a playground area where I create, test, and refine all the controls, mechanics, enemies, and environments in the game in a jumbled, haphazard mishmash.
Then I start incorporating them into production levels, build out an intro zone, etc.
The test zone pattern isn't really a conscious decision, but it almost invariably develops in everything that I end up shipping.
I like Mark Cerny though. I wonder if the 'Cerny Method' was used for Sonic 3 (as an aside, though Sonic 3 is a great game, it contains one of the single worst video game UX nightmares of all time — https://www.youtube.com/watch?v=FogRh7CALFY).
Iterative prototyping is great. The Cerny method is mostly useful for games that have tons of content, rather than systems. For example: an RPG that has tons of areas and weapons and characters. It's totally a good idea to first build a vertical slice with only one area, and a few characters and weapons...
But for systems-heavy games this falls apart. For a game like SimCity or Minecraft, making a proper vertical slice would mean building 70% of the game! That doesn't really help de-risk anything. :). For systems games it's much better to do iterative prototypes, accumulating systems with increasingly longer feedback loops...
(Source: my experience making systems-heavy games :) )
Still I'd say that it does not apply to all RPGs. For example, the recent Divinity: Original Sin games are quite system-heavy, so I don't think it would be possible to have a vertical slice without building most systems. But for Diablo-like games, it would work great!
Isn't this also Miyamoto's/Nintendo's approach? Get the basic gameplay mechanics right by and play around tirelessly with basically nothing as far as 'production' work goes, and move on only when that's been achieved.
I only did some level design back in the day, so I don't have much experience with games, but I find this 'prototyping' thing to be hugely valuable in web development and design work I've done. I often just try all sorts of shit (whether front-end or back-end or design), focusing on quick feedback and iteration, and once things coalesce/work/'click', I might just scrap the whole thing and start with a more 'formal' version.
Especially with design stuff I've found that just getting something and then playing around with it works so much better than trying to go for a more formal approach from the start. And making a clear distinction between the 'playground' and 'formal' phase has also helped a bunch.
Finally, I've all but stopped doing the 'Lorem Ipsum' and image placeholder work. If I'm going to 'prototype' a design, it can be a bit messy, but it has to be as real as possible.
There is an interesting video series by Nintendo on the making of Breath of The Wild. In one of them [1] they talk about how most of the game mechanics were implemented in a 2D version of the game to see how enjoyable and effective they were before they spent the money to make the 3D version.
Last year at GDC, Nintendo's Hidemaro Fujibayashi,
Satoru Takizawa, and Takuhiro Dohta broke down the creation of the game in a full length session with video of the original top-down 2D prototype: https://www.youtube.com/watch?v=QyMsF31NdNc
I think it's the most organic way to build a game, at least for my projects.
It sort of becomes a fractal process as well, where I'll end up with a sandbox zone for each different segment of the game, which then evolve into the production stages for each different area.
Prototyping is a must especially on the game mechanics and to find the fun.
It is a moot effort to build out the game until you have refined the game mechanic and the fun aspect. Iterations need to be quick and with as little tech weight as possible.
Even in small prototypes you can find fun that you could have never planned for, and see when something you thought would be fun just isn't yet or work with it to make it fun.
Finding the fun is the most unknown part of a development so it must be in the playground/sandbox and iterated on quickly.
Playtesting is also important but prototyping usually has lots of that from the developer themselves even.
A minor tip I saw on a video about the development of the Doom levels was to do them in reverse. The theory being that you get better at designing levels with time and the best levels should be near the beginning. Always liked the idea, but not had a chance to use it, yet.
Yeah, John Romero explains that the famous e1m1 was the last level he designed for the original Doom, in this fantastic developer commentary he did for the game's first episode with IGN, for the game's 20th anniversary: https://www.youtube.com/watch?v=YUU7_BthBWM
'the classic horseshoe design' - show inaccessible teasers of later areas of the stage near the beginning to drive the player forward
At least 43-years old, if the first edition of The Mythical Man-Month can be counted. Over 50 years if you consider the OS/360 project that book was inspired by. Centuries if you consider prototyping generally as an engineering practice.
It's pretty sound, in my view -- AAA budgets are gigantic. Spending a few million on a failed prototype is probably a wise investment compared to spending hundreds of millions on a failed product.
Edit: original title was "Why I'm using a 30 year old method", hence my reference to the age of the method.
> spending hundreds of millions on a failed product
Where are all these failed products though? I can name Mass Effect: Andromeda and basically nothing else in recent years. Hollywood has far more big flops.
Big-budget games are almost guaranteed some degree of success. If you follow the proven formulas and don't mess up, the game sells.
1. The projects that fail are often cancelled rather than bad releases, because they go so far off the rails that they are not even functioning, saleable products. When a film production goes wrong, you still have footage, you can still use post-production and editing work to make some sense of it and fit it into a 120 minute package - a Hollywood film typically doesn't get released with e.g. cuts shown in an unintended order, actors speaking out of sync, or visual effects accidentally shown upside down. A game that goes wrong is more like broken software, and does not function even on that kind of technical level.
2. There are plenty of games that fly under the radar, and the press will give them one review to lament their failure and then a follow-up when the studio closes and there's a massive layoff. Stories about failing games don't get traffic like stories about popular, beloved games. This has only become more true with the onset of digital storefronts.
So if you don't look, you only see a stream of hit products.
During the MMO rush due to WoW successes there were lots like Tabula Rasa, Star Wars Galaxies [1]. Curt Schilling was even part of one that entangled Rhode Island state funds at 38 studios for Copernicus. [2] Cheyenne Mountain, where I worked for a while on Unity games, unfortunately never released Stargate Worlds MMO and burned through 10s of millions, I think 60-70 million by the end. The main problem was warring design teams, new tech not ready for primetime and builds not happening early and often and really Unreal wasn't the best for large MMOs back then (UE3). A recent article "Confessions of an Unreal Engine 4 Engineering Firefighter" highlights not using continuous builds as being a big problem in failed games [3]
> Make Builds and Test Them: Imagine a game has a 2-year development deadline. Imagine the first playtest happening 1 year and 9 months into development. This happens. Make regular builds of your game and playtest them, even starting from week one. If you are a serious game development company, you probably should have an automated build pipeline of some sort. Pro-tip: Automation is cheaper and more effective than human labor.
Large games like this are generally smarter today taking it to market with smaller teams and getting funding and alpha/beta feedback all along the way. Fortnite for instance has been in development with available builds for Epic using Unreal Engine 4 almost since inception and became a better game for prototyping/early and often releases.
I don't know the story behind it, but fortnight was adapted into a PUBG type free-for-all mode which seems to have helped its popularity. Being able to jump on a trend like that so quickly shows impressive flexibility. They didn't need to make a whole new game to cash in, the ROI is probably crazy.
Yeah I would say Fortnite was influenced by Overwatch and PUBG and maybe even Splattoon, but originally probably started out as Epic's Overwatch type game that Blizzard was successful on.
You are right though World of Warcraft and Starwars Galaxies came out around the same time (mid 2003, late-2004).
I should have said Everquest (1999) as that one really started the craze leading to WoW.
But the WoW success is what led the insane MMO bubble/hype as it broke all types of records and everyone wanted to be the next World of Warcraft.
When I worked at Cheyenne Mountain on Stargate Worlds, part of the job was understanding WoW and playing WoW to level 70, then 80 on Wrath of the Lich King, our CEO had done it twice, everyone there played WoW because everyone wanted to replicate it.
Turns out WoW was an outlier not the norm or the future, but every game company wanted subscription money not one and done purchases and it led to tons of investment and hype.
Sony even couldn't replicate Everquest with Everquest 2, Planetside nor Starwars Galaxies, though I loved Planetside.
Mass Effect Andromeda isn't even in the discussion when it comes to the largest commercial flops. It probably sold 2-3 million copies in the launch window. (But yes, bad enough that they thought it best to suspend the franchise and even kill the DLC).
From last year, Agents of Mayhem was really in a league of it's own for AAA games. It had Steam sales numbers of ~20k a month after launch, so <100k across all the platforms combined. From the year before that the most high profile flops would probably be Battleborn or Evolve.
If big budget games would be a guaranteed success you wouldn't read about studio closures and layoffs every few months. Also you never hear about failed products, a game that you know about is more likely to succeed because obviously it was marketed well. Usually failed games sink without a trace and are forgotten within days or weeks.
I think you would find quite a few in the MMORPG space, other then that you're probably right - big budgets are usually reserved for "sure things" such as rehashing popular franchises like COD, Battlefield, etc.
Then again Star Citizen probably has its day of reckoning coming.
Projects get killed in production pretty often. Also, if you go through releases on steam, there is a lot of stuff that is unlikely to earn enough money.
A lot of bad publicity and public fights is not only way to fail, often simply nobody cares.
My guess is that the marketing budget is a big percentage of the costs so abandoning a failed project even several years after development is a viable strategy.
Interestingly, I see a parallel with the "vertical stripe" nature of "stories" in XP. A lot of teams will spend considerable amount of effort making an MVP (Minimum Viable Product), but when you look at it nothing works properly. It can be used, but you would never want to use it if you had any other choice. As the product grows, those pain points never quite disappear and they complicate the design forever. Even if you are successful, your competitors can learn from your mistakes and build something coherent that takes considerably less time -- second to market can have a big advantage.
In contrast, with a vertical stripe, you are encouraged to build something that is not just done, it is done done. With the information you have now, you would not change it (NB: this is considerably different than perfect). Each stripe should be as good as you can make it allowing for imperfect knowledge.
So in the same way you are limiting scope, but trying to make the result "final quality". From there it is a lot easier to iterate your design. I'm not sure I think it is necessary to nail down all your decisions quite in the way the article suggests -- good ideas are good ideas even if you have them later on in the process. Building on a solid foundation is just dramatically easier than trying to reinforce a Jenga tower.
I know nothing about game development, but I can see that a useful analogy is with a big-budget TV series rather than a movie. Make a pilot episode first, full production quality, and use that to greenlight (or not) the rest of the production. Even with one-off movies (or a hoped-to-be franchise) I'm aware that at least sometimes a test scene is shot and produced up to close-to-finished quality in order to win support for financing the full production. This could be a key point of dramatic inflection in a story/character led piece, or a demonstration of unique special effects ("bullet time" springs to mind here) if that is the USP of the proposed production.
Like I said, I know nothing about game development, but if I was to get into that line for some reason I would want my business to be protected by taking a similar approach.
This is a good approach. The only downside is that depending on the scope of the game and features involved, the prototype phase can become super expensive.
What if the design says, that we are going to have characters talking to each other and it involves voice recording and mocap studio time. This is cost prohibitive for a majority of the projects at the prototyping phase.
Overall though the two biggest problems in game dev are building what people want and R&D. When prototyping starts both of those are unknown. Often prototype proves that certain game mechanic MVP is super fun, but in order to make it scalable across the whole game, months and months of R&D needs to be done. For example, one can put a quick level together which plays great, but to make 40 more levels, a level editor needs to be created, which is a huge undertaking.
In my experience, if people want what you are making, 9/10 times you can survive the "bad" production process, due to the fact that even if project 2x-3x over budget, the market will easily 10x-100x initial investment lifetime.
> In my experience, if people want what you are making, 9/10 times you can survive the "bad" production process, due to the fact that even if project 2x-3x over budget, the market will easily 10x-100x initial investment lifetime.
(Emphasis mine.)
But this is the point, isn't it? If people want what you are making. But how do you know they want it? If you already have a successful franchise, it's easier, but many games don't, and with a well known franchise there's often an incentive not to be _too_ innovative (I'm looking at you COD, FIFA, Assassin's Creed, etc.). For most games, if you're building something that simply isn't fun then you should stop, and ideally you want to stop early in the process so you can spend your time and money on something else.
The issue I have with your conclusion is that in a very specific set of circumstances it's true, but not a useful observation.
Look at it like this: the PS2 has over 2500 titles and you know full well that a lot of them were costly to produce, yet are still absolute bilge. You also know that there are a lot of great games in there that didn't succeed commercially. So you need to hit sweet spots on multiple axes, and you need to de-risk on all of those as early as possible to succeed.
You _might_ get lucky even with a bad and overly expensive production process for something that people really want[1], but it's a very high risk to take, even if you don't end up at the extreme of a Daikatana or a Duke Nukem Forever.
[1] I wonder if something like Half Life 2, which was quite heavily delayed, might fit this category.
> ... the two biggest problems in game dev are building what people want and R&D.
What's even harder again about point one, building something people want, is this is a purely creative industry so it's REALLY hard to know what people want.
Making a new coffee machine would involve simple market research to understand what people want, but painting a picture is a different story entirely!
When Blizzard makes Overwatch or HotS, they have a good initial idea that it is going to be popular because games of similar gameplay already exist and popular. On top of that when they play internally and if it is fun, they can be pretty sure that it is going to work.
Obviously, if someone like Jonathan Blow is making a completely new game like Witness, then all bets are off.It is basically up to him and people who he trusts with feedback to determine if this is the game worth making.
Making Call of Duty version 21 at the same time as close to risk-free as it comes.
In terms of production quality, sometimes it takes years of iteration on art side and tech to get the look.
You want to nail it down early, but in real life concept artist does the image, artists model and texture the scene and then art director comes back and says, those bricks don't look good. Engine guys say, if we put more polys to make them look good, it is going to kill performance. Then someone says, look we can write this shader using this new GPU feature which is going to make everything awesome, but it might not work. And in any game production, there are 1000s of cases like that, where the thing you want does not exist or you don't have people who have the knowledge. So you just roll into production hoping shader works out and that you are going to hire people who are going to solve XYZ.
> you should have one level of your game that is indistinguishable from a completed professional product
This artifact becomes the goal and the plan. It unambiguously communicates what is acceptable addition to the game. Fully internalized, it now should be possible to farm out development have every single level hit the look, feel and gameplay of the original level. All issues end-to-end have been hit and addressed, there are no unknown-unkowns at this point.
This is way Rango [0] is so damn good. All the techniques used in the movie were honed in the Pirates of the Caribbean movies. It wasn't just a tech trailer, they could focus on the story while using cutting edge production workflows.
I guess these days indie developers often use this method where step one is to get a high quality first level that is used for crowdfunding to finish the game.
However, I have noticed that most games start out fun for the first few levels, so I would say as a game player that developers should really not worry so much about the art being perfect on the first level before production but to have a complete game that can be played through that is fun the whole time. Because from personal experience the vast majority of games do not accomplish that.
I'm just starting out making my first game and I'm beginning with mechanics. Movement, inventory, NPCs, compbat, character build, stats, etc. Once they're solid, then I can build whatever worlds I want which includes the art, sound, and critically, the story.
I agree that starting with mechanics is the necessary first step. I have seen some games where the mechanics made me entirely uninterested in proceeding past the tutorial or very early game and others where the mechanics made the game worse the whole time but not completely unplayable. Maybe I see games unplayable due to mechanics about as often as I see games unplayable due to technical issues (as someone who generally does not buy games when they are first released).
It seems to me (without having actually designed games) that level design and the story can be done with basic artwork and sound and that making sure that stuff is great before spending a bunch of money on artwork would improve things.
I wish developers would avoid violence as a core theme of games. There must be other themes you can use even with the same basic mechanics.
Good luck with your game! I really love story driven games and there are so few good ones.
Then I start incorporating them into production levels, build out an intro zone, etc.
The test zone pattern isn't really a conscious decision, but it almost invariably develops in everything that I end up shipping.
I like Mark Cerny though. I wonder if the 'Cerny Method' was used for Sonic 3 (as an aside, though Sonic 3 is a great game, it contains one of the single worst video game UX nightmares of all time — https://www.youtube.com/watch?v=FogRh7CALFY).