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
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).