This week, the plant levels… kinda. I actually don’t want to show an example level as much as I want to talk about the history behind some of the objects used in the plant levels, as they went through several conceptual iterations before reaching their final state. Cool? Cool. If you saw my first screenshot of a testing level, you may have noticed some vines on the left side of the screen, and a couple mushrooms scattered throughout. The mushrooms ended up staying and making up the basis of my plant levels, while the vines were cut entirely.
(Just in case you haven’t seen them)
At first, the vines were going to act as static spikes that would kill the player and reset the level, which would give some edge to platforming sections here and later in the game. There were two main problems with this philosophy, though – they weren’t very useful as a puzzle element, and I really didn’t want any obstacles between the player and the end door besides their own brain and jumps that could be quickly retried without slogging through most of a puzzle all over again. I tried to solve the first problem first by making them start out ungrown and harmless, and only growing in response to light, whereupon they would stay grown forever. I liked the idea of having something permanent in a level, in contrast to the easily changed light beam. But the fact that they killed the player was still too much, so I redid the graphics and turned them into simple walls, as you can see in the screenshot above. This was interesting, and allowed for a sort of “checkpoint” system where if the player could get light to one particular place, they would have something permanent (for the level) for their achievement. An early idea that was never fleshed out past the concept stage revolved around using the vines to grow higher and higher platforms until the door was reachable. It was almost ready to work.
But, at the same time, I was working on the mushroom objects as well. I decided that I wanted the mushrooms to be one-way platforms that couldn’t be fallen through or one-way walls, creating a unique way to wall off sections and force the player to traverse the level in more interesting ways. Two problems immediately came up – one of implementation and one of design. For the former, messing with the already clunky collision code wasn’t something I was looking forward to doing any time soon. As for the latter, it didn’t really make sense that the player could fall through the one way platforms but not these mushrooms. I solved both problems, however, by making the mushrooms bounce the player upward. By pushing the player back into the air instead of making it a dynamic piece of ground, the collision could be hacked together without diving back into the existing stuff. It also made players not even wonder why they couldn’t fall through, because the mushrooms weren’t platforms in the same way the rest of the ground was. And, on top of that, players just had fun bouncing off of mushrooms. The character’s jump height is pretty short for a standard platformer (six feet, or about 1/4 of Super Mario World’s version of Mario’s jump height), so being able to keep vertical momentum and sail through the level was extra dramatic.
As I was making levels, I couldn’t help but feel like the mushrooms did everything the vines did and more. So, I combined the two into one, making the mushroom only grow when light shined on it. After ensuring that puzzles could still be properly made with the new mushrooms, the vines were deleted from the game. I put a decent amount of work into them, but players don’t really care how much work it took as long as the end result is good.
Next week, I’ll be talking about levels with red beams, and how a late design change cracked open a new world of puzzles.