The Teslagrad approach to puzzle platformer level design

I got a question online the other day about level design that i gave a long and rambling answer to, but i figure it might be useful for some of you who might be starting out making games yourself:

“So I’m interested in getting into game development. I’d also like to make a platformer puzzle type game. I have 0 experience outside of being the consumer of games. I’m a developer and I’m sure with enough time and research (and tools like Unity) I can handle the programming side. For me what I think seems most daunting is level design. What was your team’s process for designing the levels?”

-Best laid plans, trial and error, killing your darlings and iteration! No one is born a perfect level designer and things rarely work just as you intended when you play the first iteration you build of a level- and that’s ok. The important thing is being able to identify what you are trying to achieve with the level and change it to fit that vision if something doesn’t work as intended. Or alternately, seeng when something unintended works outbetter than the original idea. Most of teslagrad’s levels changed a lot from first to final version! one thing to keep in mind is that level design that seems easy on paper can be very hard to play, almost all the initial designs had to be simplified and made easier-and teslagrad is still considered a fairly hard game!

Also, never start out trying to make levels with a high degree of graphical fidelity-always stary out just building them from grey boxes or basic tilesets, and decorate them when you’ve nailed the gameplay aspect. This makes it far easier to iterate. make sure you think of what parts of the level are visible to the player in-camera from any point in the level, if you keep that in mind you can imagine the experience of playing it for the first time from another person’s perspective, and try to make it an enjoyable experience for them.

Get people to play your WIP levels (anyone, but keep in mind how their skill level relates to your intended audience). Don’t talk to them while they’re playing, even if they get stuck. Never try to help them along, just observe and see what seems like it works for them and what doesn’t. This can be very hard to do. Afterwards you’re free to ask them anything about their ecperience, what they enjoyed and what they didn’t, what they found too hard, too easy, too obtuse or what confused them. Results may be surprising.Sometimes the part where they looked like they were struggling was their favourite part, sometimes it can be the opposite. Try to adjust your levels if it’s obvious that spesific parts aren’t fun for the majority of players. Listen to suggestions, but keep in mind that not everyone is great at problem solving and what they suggest may not actually be the solution to the problem they were having in the game. Never dismiss people outright if they are struggling in some way, even though something seems like it should work for you, it might still be a bad design choice. That’s not to say you should compromise your vision or make a dull design by comittee game, but try to find a balance!

Lastly there’s a Shigeru Miyamoto quote that applies to almost every aspect of game design-paraphrasing here, but it’s something along the lines of “A good idea is not an idea that solves a single problem, but an idea that solves multiple problems”.

Ole Ivar Rudi