This is it. I’m finally done.

A whole summer’s work is behind me, and I have a finished game. I’m not sure that I have too much I want to add. I could discuss the design of my final set of levels, but I also want to keep those a secret even for those who’ve read this blog start to finish (for some reason).

It’s funny – I actually feel really happy to not have to think about this game for a while. It’s not that I don’t like it – I poured so much of my heart into it that I’d have to at least like it – but it’s been a lot of surprisingly hard work. From drawing the last sprite to placing the last block, there really wasn’t an easy day in the whole process. I had to solve so many problems I wouldn’t even know would come up until I got to them. My brain is wore out, even with the vacation/wisdom teeth break.

I suppose thanks are in order. Thanks to my parents, who had at least enough faith in me to let me work on this crazy project instead of getting a proper summer job. Thanks to STEP for paying me for doing something I’ve always wanted to do, but couldn’t find the motivation to ever push towards. And thanks to you, reader, whyever you’re here. It often feels like I’m writing for no one in these posts, so if you’ve found your way here, I appreciate it.

Now play my game! It’s free!

Red beam levels! Let’s go.

SPOILERS AHEAD. IF YOU ACTUALLY WANT TO PLAY MY GAME, PLAY IT FIRST AND COME BACK TO THIS LATER.

Alright, so the idea behind the red beams was baked into the game from about day 3 or 4. If the default beams could be walked on, it made a lot of sense to introduce a type that doesn’t allow for that. Levels could be far more controlled and platforming-focused, without requiring taking into consideration every possible angle the beam could be shot at and where that could allow the player to walk to. Plus, it allowed me to create a sort of “checkpoint” for the beam – if it started white and needed to be red to finish, the player would need to direct it to a white-in red-out diode before getting it to the finish. But as I was designing the levels, I came up with the coolest idea I’d had for the game in a long while.

What I could use two starting beams at once? The player could use the white beam as a platform to adjust the red beam!

There was a small problem to that – I, as a lazy coder, made a bunch of assumptions that revolved around there only being one starting beam object. I tried making these levels with a bunch of stacked diodes pointing at each other, but it just didn’t work right. I’d have to fix previous me’s errors.

*queue hacking montage*

By the way, try searching “hacker stock photo”. Try it. Really. Every single image is ridiculous.

Just one more, I promise:

Anyway, I made the changes I needed to make, which allowed the construction of this level:

Just looking at it, you can tell the design is vastly different from previous levels so far. This isn’t the first level with two beam sources in the game, but it is the second, and to have the two types side-by-side as they are helps call attention to them immediately. They signal that things are vastly different and more complicated now, and that the player is going to need to stretch their brain hard for these levels. Additionally, more mirrors are mounted on walls and ceilings than on the floor in this level. The player gets to figure out where their platforms need to be, while under the tight constraints of the existing mirrors. In many ways, it’s the epitome of the idea I had when I was just starting. See if you can figure out how to get from the first picture to the second, or the second to the exit:

I’ll be pausing development for a while after this – I’ll be going on a family vacation and getting my wisdom teeth out over the next couple weeks. By the time you see my next post, I’ll probably be completely done with the game. See you then.

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.