Part 9 of 10: Vertical Slice [previous parts]

The main vulnerability of the Vertical Slice is that it demands the impossible.

Vertical Slice is not unlike public demos. It’s supposed to be representative, so there’s the same assumption: if the slice is enjoyable, then the entire game will be, because it's made of multiple slices sitting next to each other. The problem is, Vertical Slices are requested early, and require large amounts of content as well as playable experience.

Let’s take a brief look at chess. The rules governing the movement of pieces are the game’s principles. Then there’s the board and the initial placement of pieces – those are the data you feed the game with. Neither will work without the other. However, principles actually convey some meaning on their own; for instance they tell you what kinds of data are needed or valid. Data without principles mean nothing: the chess board without chess is just a square with a checkered pattern on it.

The Vertical Slice is meant to be playable, but it also contains a large amount of game data. In order for the data to make sense, you need to know what the principles are first. Since the slice is supposed to give a good idea of core gameplay, virtually entire game needs to be in there. It seems to many that most of the work is saved, because the demo is short. But that only saves time spent on data, while the remaining chunk of content still needs to follow the game’s principles. It amounts to squeezing 80% of game creation effort into 20% of your schedule.

The task is impossible and something needs to go. The only thing you can discard, and get away with it, is the game’s principles, because, unlike assets, they’re not immediately apparent. With just a short demo, the player will have trouble figuring out what those principles are, apart from the very basics. They won't notice if the actions available to them are poorly balanced, for example.

And that’s how game prototyping essentially died in most projects I’ve seen. There just never was time for it. Some basic pieces of mechanics were implemented out of necessity, but they were never verified to actually hold together. Which they didn’t. The issue would hit us from behind later on, because, as the amount of data grew, it would become apparent the principles were not making as much sense as they should. That would lead to an awkward dilemma: either change the principles and discard the content that doesn’t fit (just think of all those man-months wasted!), or keep the content and give up on the pursuit of a better game.

Ironically, the idea of making a vertical cross-section of a game makes sense, as long as you don’t insist on piecing everything together into a single demo. After all, you can create informed concept art without a single line of code at your disposal.

Lesson Learned: Develop horizontally. Tackle various principles of your game, one at a time, and postpone data creation until all relevant principles are in place.