Crashing In

Crash Bandicoot 2

Crash Bandicoot is like taking a hike in the forest.

You’re on a dirt path for the most part, running across animals while leaves and flowers brush past you, with just enough light bleeding through the canopy up above. You feel like you’ve been funneled into something by the outdoors, a natural interior that envelopes your imagination, and with that comes a natural tension as well. The trees, the change in elevation, the twists and turns obscure your vision–the most important tool to playing a 3D platformer–leading every several steps towards discovery, and surprise.

You could only ever see a few meters ahead of you, and a few feet behind you (or the opposite, if a boulder/bear was chasing you). Occlusion is something that the thrill of most video games, especially platformers, thrive on. Our television sets become viewfinders, our hands moving them back and forth.

Whether or not the context of a larger world begins to make sense to us is only a side-effect to this layer of interactivity. Crash never asks you to envision that entire space–just what’s up ahead, or around the corner. You couldn’t plan too much ahead even if you wanted to, and the temptation of crashing into/onto a crate, than onto a skunk, then onto a platform and back onto the ground is a rhythm so satisfying in motion you’d rather just keep pressing buttons and moving forward.

The pacing of Crash games (at least those developed by Naughty Dog–I’ve never played the current generation Crash’s) were incremental and moment-to-moment, without completely ignoring the scope of its larger surroundings. Between levels you would leave the more claustrophobic forests and return to larger islands, indicating where you were in Crash’s world. From there the environment also became your interface as you’d pan between which level to play next. As unconcerned as this mode of presentation was with detail or hand-holding tutorials, it still seemed to get the job done.

Crash was pretty satisfying with so little to be said. It was focused, undistracted by duct-taped features creeping in, or a desperate excuse to leverage internet access. It was an ancient tiki island filled with secrets, and that’s how I found them.


Creating an Environment: Pt.5 Playtesting, Cont.

Playtesting any game design for the first time  is unlike most other forms of critique: experiencing people experiencing your work for long periods of time. If it’s multiplayer, then you get the real treat of watching people affect each others’ experience back and forth. What sets games apart from other media in this regard is that traditional art-forms are less prone to collapsing in on themselves unintentionally (unless that’s the point). Of course, playtesting has its practical role of locating bugs, visual snafu’s, and optimizing performance, but all of this eventually funnels back into the player experience.

Getting critical feedback on design work is a tough pill to swallow the first few doses. However, I’ve found it helpful (in both the fine and applied art) to recognize that critiques are of the work, and not of the maker. With that aside, onto specifics.

When should I playtest my level?

The earlier you’ve built playtesting into your regiment, more than often the better. This is a pretty difficult question to answer, and yet it’s very necessary to ask because determining what is helpful for you to at each stage in development gives you a better read of how players are behaving and why. Keep track of the revisions you make, because any significant one can change the flow of traffic and/or action dramatically. Making a number of large changes at once isn’t a bad idea, just as long as you know why you’re making them.

There’s also something to say for playtesting too early on in creating your level. In a game like Team Fortress, gameplay will begin at the dynamic between character classes, which is then morphed and redirected by the environment/s designed for them. For example: if you make a functioning map that’s essentially a large box, completely flat, and lacking a play oriented goal, it becomes useless to playtest because you can nearly guarantee how players are going to operate. If there’s not much to it, then there’s not much to “test”. The point of playtesting is to put a hypothetical design through the ringer of players and see if a theoretical idea is well implemented or not. Make sure there is some substance worth testing before anything else, even if it’s early on.

Day of Defeat map, Blaze. While it looks far from finished in this shot, there's probably enough worth testing.

One extreme not working isn’t solved by another, however. Playtesting can focus your efforts in sections at a time. As I wrote about way earlier in this series, the relationship between your gameplay mode in conjunction with the geography is a crucial decision to make at first, but this doesn’t mean you need to wait until absolutely everything is in place.

After playtesting Arc Mountain over the past year, I found that my game mode and architecture evolved alongside one another over time. From Capture the Flag, to Arena, to King of The Hill now, each time I’ve had to make significant revisions to the buildings to accommodate the pacing for each mode. Even the small deviations King of The Hill makes from Arena gave players much to desire from the flow of each team’s fortress/spawning area. On another note, I only got to playtest the placement of ammunition and health packs just months ago. For such a long time, the map wasn’t as eager to figure out how pick-up items fell into the design before the bulk of the geometry and elements of cover did. It’s a lot of back and forth any way you slice it.

What are the resources needed to playtest, and where can I get them?

People, and computers. In some cases, you may even consider a brief Q&A sheet for those who can’t stick around to give you immediate feedback after testing. Though, from personal experiences and ones I’ve observed via peers, survey forms of any kind only work if they’re given to people who make up your target audience — fans of a game are the ones who’ll spend time thinking about and discussing new additions to it.

The next set of questions is who do you ask to help test, and how do you ask them? Playing with people face-to-face is a rather optimal situation because you can observe people’s reactions and emotions as they play in your environment. If you happen to have friends in the area who enjoy gaming, the game you’re developing content for, or are interested to help at all, you might want to get their opinions. Getting some food and making a LAN party out of it is a really nice way to get feedback and have an enjoyable experience all at once, too.

There’s also remote testing, which occurs more frequently than local happenings for a game like Team Fortress 2. is probably the best place to go for this because it’s a one-stop shop: they’ll host your map on their server for others to download at their discretion, they host playtest days on their Team Fortress 2 servers every week (sign-ups required before hand), and they have an incredibly large community behind it already willing to give people feedback and share advice in a number of ways. Convenience is the big plus here: they provide a set of free services and tools to gather dozens of people at once who share a common enthusiasm. It’s a great platform for other players to give your design a shot and stress test the hell out of it, in the hopes you’ll continue to refine it. You’re not guaranteed to always get the most useful or glowing feedback, or necessarily get into a testing slot (they tend to fill fast), but it’s really helpful to participate.

What should I be looking to get out of playtesting?

Not everything is quite ready at every play test session, so one approach is to inform your playtesters about what you’re looking for feedback on specifically. Is it the layout? The capture times for goals? The distance between checkpoints? Being proactive in what specific characteristic/s you want attention drawn to will help focus the feedback, thus focusing your next goal as the creator. Make sure your playtesters know what your intentions are for their experience, because their fresh take can provide insight as to what makes that sort of experience work better, and how your map is addressing its concerns.

You’ll probably know when to put the whole package to the test and see how it feels as a full experience from front to back, but most important is that enough people are engaging in it and telling you what they think. This only further enables you towards making the right decisions for the map, level, or game play mechanic you’ve probably had in mind for awhile now.

(To close Pt.5 of this series, I’ll be making screenshots available of each revision Arc Mountain underwent between game-modes, and why.)