My friend Nathaniel was just watching me code, and he suggested using the event queue to process input instead of polling for every type of input every frame. To be honest I don’t exactly understand how the event queue is any faster than polling (like, at some level there must be some logic checking every key, right?), but it is much faster. Since most of the controls involve holding down keys, I’ve got a lot of code to go through and rework to use the event queue!

I’ve been implementing a level editor feature or two each day. Now we have a little display on screen that tells your current tile coordinates, which paves the way for our status display of health, items collected, and so on.

There’s also a neat little blinky cursor that shows exactly where your tile will land if you place one; this is nice because the reticle can actually move one pixel at a time, making it hard to know which tile you’re in at any given moment. I was going to make the cursor its own special item when I realized I could just use our existing particle system: I make the reticle spawn tile-sized square particles every 11 frames, which fade away just as the next one is being created.

It’s great how much of the code for Paraplu is stolen directly from Soft Landing as I need it. Much of the coding is just simplifying and generalizing the existing code. When we return to working on Soft Landing, I’ll copy that code right back in, cleaner and faster and more flexible.

So Paraplu’s level editor has so far only supported changing the map layer of a level. But there are two other layers in each level: objects and “entities” (meaning enemies or townsfolk). It was surprisingly difficult to adapt the level editor to work on these other layers, because each layer was kind of a special case in itself, and used its own batches of images and such. So I had to rearchitect the way ground tiles and objects are loaded, such that they’re all living in one big list of dictionaries now, with data about what kind of thing they are, instead of being in their own special lists. Now I can use the same logic for editing all of the different layers: when you cycle through the palettes, each one just knows what type of palette it is, and thus which layer it should draw on. If we need to, we can add an arbitrary number of layers on top of the three we already have!

Oh yeah, and Jules drew these gorgeous trees and shrubs and rocks, which is the reason I wanted to get objects working in the level editor anyway. Please don’t let my random level-editor testing style ruin your perception of his source art, though. :D

I just transplanted what’s probably the most complicated class in all of Soft Landing, “Interface”, into Paraplu. Along the way I chopped off a ton of messy code that I’m planning on rewriting. This is the class that draws all of our text boxes, menus, health bars, and so on. It’s not gorgeous, but it’s working:

I just finished much of the work on the improved Paraplu level editor. It’s a mode you can enter when you start the game, in which the character is replaced by a translucent square cursor. There are buttons for cycling through the various batches of tiles we have, each with 9 tiles in it. Then you can hit keys to lay down a particular tile in the batch. It’s blowing my mind how quickly we’re making progress on this project; it seems like every time I sit down to work on it, I reach what would be considered a major breakthrough for Soft Landing.

We also have enormously long lists of enemies, items, and recipes, and it seems like every time I go back, Jules has added a few more…

So, I think last night was my major breakthrough that I had been waiting for. I’d like to thank Flight-Plan in particular for inspiring me to re-attempt the style I was originally going for, and to get it right this time. I studied some GBA games they’ve made and it was really useful. Strangely, my error essentially was that I was being too elaborate and ornate. All I needed to do to get my tiles looking right was to take away detail, not add or fine-tune it. With that in hand, I was able to finish all of the tiles I had already been working on and a fair few more on top of that. I’m going to get back to it again tonight and hopefully get this all sorted out.

Fet realised that we haven’t actually written down anywhere what this game is like yet. Maybe we’ll keep it that way, and then no-one will have any preconceptions or expectations. I like that idea.

Well, Jules and I decided that pixel-level collision is not really going to be necessary. We’re just going to have a kind of rectangular collision mask for each entity and each obstacle, and test against those. Given the tiled nature of the maps, this should work fine. It took about ten or fifteen minutes to implement the whole thing, in keeping with the hilariously quick pace of development so far.

Then I noticed that pygame 1.8 actually includes support for collision masks, which was surprising because I thought that the term (if not the concept) was something Jules and I made up!

Next I need to make it so that entities which are trying to push up against an obstacle at an angle instead “slide” along the edge of it. I thought of a good way to do this while lying in bed this morning.

We’ve been keeping big long lists of items and crafting recipes for Paraplu at Backpack; the lists are growing quite quickly as we both stop in throughout the day to add our wacky ideas.