Up until a couple weeks ago I had only created bits and pieces of levels that don’t resemble the actual game’s levels, just as a way of testing the various features I had implemented. Now I’m at a point where most of those features are implemented, and the next step forward is to trust my level editor and create the first level.

I was pretty happy with the result. It took probably 5 hours to get it mostly done. Since then it’s been a matter of finding a missing tile here and there, and fixing bugs in the game I’ve noticed because of the level.

It’s worth noting that when I say “creating the level”, for now I just mean the static tiles. This means no backgrounds, no items, no enemies, etc. It’s pretty bare, and it gives you a sense of appreciation for what all goes into just one level. Thankfully it is an iterative process and additional levels wouldn’t, in theory, require much more effort to add.

The Level Editor

I hurriedly wrote a level editor using WPF to support my game. It was odd to write a program to assist writing a program for myself, even though it happens in the “real world” all the time. As I stated in the readme, the code is crap. I didn’t spend hardly any time designing the thing, and the requirements grew a lot larger than I initially anticipated (as is common in development). Since the point of writing it was to save time, I didn’t want to spend a whole lot of time in it. Plus, I don’t enjoy it and thought of it as a distraction from the game itself. Still, it was necessary.

Now that I’ve built a full level with it, I can still say I’m pretty happy with the reliability and functionality of the level editor, even though it could definitely be more featureful. The worst part is probably having to place each tile by hand, instead of being able to place a whole row of 30 tiles that are exactly the same or something like that. Still, I didn’t feel it was worth the time investment.

There are three important pieces to the editor. On the left is a sprite sheet filled with tiles to choose from. My editor takes a file as input and splits it up into tiles of a size you specify (in this case, 32x32 pixels). In the middle is the level itself, of a size you specify, and filled with tiles you place onto it. On the right there are controls to set properties of the currently selected tile, such as collision, slope height, pole and edge booleans, and what layer the tile should be on. When the level is saved, the grid is converted into a text where one line represents one placed tile with the location in the sprite sheet and the properties from the right.

The Level

Unfortunately I can’t show off everything the level has to offer at the moment, because there are bugs (surprise!). This was most noticeable in the sloped tiles. I wrote the functionality for those in August and have avoided them since, so I haven’t been testing them as I’ve been going. As a result of building the level, I found some conflicting collision detection functionality between sloped tiles and one-way platforms. I have not solved this yet, so either one must be broken at all times. For the sake of the video demo, I’ve kept the functionality that allows for slopes to work and breaks the one-way platforms.

In addition to the slope bugs, building the level exposed a lot of things that need adjusting. Maybe the most noticeable to me is that Keen moves a lot slower than he should. I knew this already but the level draws this out a lot more and will help me make better judgments in the future with the “real” level to compare to. There’s also an interesting pole climbing bug. There’s one spot on the level where two poles are close to each other. Sometimes Keen will teleport from one pole to the other as he’s climbing down. This is because, as he moves up or down a pole, it’s constantly making sure he’s still on a pole otherwise it’ll boot him off. Sometimes it finds the other pole instead and pushes him onto it.

The most work I’ve put into it after building the level is the slopes. I still had to adjust the slope height for the steeper slopes. I put a couple hours into that last weekend and, as you can tell, it’s still far from perfect. For slopes that go up and to the right, it’s very difficult to get Keen to appear high enough on the tile. For the slopes going the other way, it’s not nearly as difficult due to the perspective difference. It may require reimplementing slopes from scratch with a different algorithm, but for now I’m considering it good enough.

Next Steps

Before I try fixing the collision bugs mentioned earlier, I’m going to work on some long-standing, somewhat related collision bugs. These may (or may not) drastically affect collision and I want to see how it changes things first. After that I can try the collision bugs again.

After I’m done with collision, there’s still a lot to do and I have that documented in DEV.md. Namely, I’m thinking of working on things like adding backgrounds and units to the level. This will take considerable work on the level editor first because at the moment it only knows what to do with static tiles. More to come!