The Gamasutra Deep Dives are an ongoing series with the goal of shedding light on specific design, art, or technical features within a video game, in order to show how seemingly simple, fundamental design decisions aren't really that simple at all.

Earlier installments cover topics such as building an adaptive tech tree in Dawn of Man, achieving seamless branching in Watch Dogs 2’s Invasion of Privacy missions, creating the intricate level design of Dishonored 2's Clockwork Mansion, and the tech behind Gears Tactics.

In this edition, developer Patrick Traynor explains what went into making Super Mario Maker-inspired gem I Wanna Maker.

Who:

Hi, I’m Patrick Traynor, one of the main developers working on I Wanna Maker. Our team is nicknamed The Elephant Crew, and we are composed of three main developers (Freedom “YoYoYoDude” Garcia, Klazen108, and myself), two artists (Tralexium and Dribix), and about five others who do additional programming, moderation, design, and misc. tasks.

What:

The game is a precision platformer with a robust level editor and online level sharing, based on I Wanna Be The Guy (IWBTG) fangames. We’re all from the IWBTG fangame community, and, inspired by Super Mario Maker, we set out on the ambitious journey to make our own game based on the idea. The team works on I Wanna Maker as a hobby project - the game is free and has no monetization.

I Wanna Maker’s current main menu

The game has a lot of features relating to online level sharing, but all of those features are underpinned by an intuitive and powerful level editor. The game’s level editor has quite a lot of features and has evolved a lot over the years. This article will focus on one key subsystem of the editor: the event system which lets you flexibly program object behaviors, which opens up tons of level possibilities. Hopefully, seeing how its design has evolved will be interesting, and maybe give you ideas for how to iterate on your systems.

A killer apple which moves back and forth, and every time you jump it toggles whether it’s lethal or not

Why:

Our first principles

Our goal with I Wanna Maker was to make a level editor for IWBTG fangames. Many IWBTG fangames are focused on funny traps, brutal difficulty, and a certain attitude toward fairness. But there is a large subsection of them, especially in recent years, which focus instead on the tight and versatile player physics and making intricate obstacles and mechanics around that, akin to something like Celeste, but focused more on humor and unfair gameplay. Our focus in I Wanna Maker was largely on the intricate obstacles, and the ability to create traps/trolls was kind of a consequence of that while not being a focus.

Our first principles which inspired creating this system were to give people the power to make a bunch of the best tried-and-true dynamic obstacles in IWBTG fangames that we were familiar with and inspired by. Obstacles such as spikes moving slowly back and forth along a set pattern to force an intricate maneuver, platforms that start moving once you touch them, shooting a spike to make it move for 2 seconds before stopping, spikes that pop in and out every time you jump, or shooting anywhere to toggle the collisions of certain blocks.

We wanted the ability for the user to create any type of object interaction they wanted, even if it wasn’t a part of an object’s original behavior, without the daunting feeling of writing code. So, we started with a drag-and-drop system with “activators” and “actions”, which performs a behavior specified with an action whenever a condition set by the activator is met. This seemed like an intuitive and simple way to create these specific dynamic obstacles. It was functional, and it allowed users to create much of what they wanted to. Over time, we gradually added more activators, actions, and functionality to enable more possibilities.

The event system fairly early on, with only a few events

Organic evolution

The event system evolved organically as the dev team made more levels and as other parts of the editor were improved. Often, we ran into limitations or had a want for a certain tried-and-true IWBTG fangame element. The Metronome activator is a simplification of a common Timer event setup, like a cannon that fires every 1 second. Move Set Distance was added to easily make spikes pop in and out of the ground. The Activate Trigger and On Trigger events allow objects to communicate, like a cherry that triggers a death wall whenever you let it reach the bottom of the screen without destroying it with a bullet.

We added graphical selectors for angles and speeds as typing became cumbersome. We overhauled the UI to allow multiple actions from one activator, and allow an arbitrary number of parameters. This overhaul was a lot of work, but it was also important to us to get the initial system up and running in an efficient manner, as we weren’t sure if this was something we would end up wanting.

The Paint Roller tool is a notable case. When making levels, sometimes we would make an interesting behavior for an object, and then decide we actually want 10 more of them in the level. We added a duplicate tool to let you do just that! But then, when you tweak the speed of one of them, you’d have to delete all the copies and re-duplicate the original. So, we added a paint roller tool inspired by the Paint format tool in Google Docs (which I’m writing this in right now!) which lets you copy over the events from one object to another. This quick-and-dirty tool is quite handy!

Note that there is no concept of an object blueprint or class in the editor, where you just edit it in one place and the rest of the objects auto-update. Sometimes it’s frustrating not to have that ability, since it’s basically a given when you’re programming your own game. But that awkwardness comes with some upsides too, like being intuitive, a simpler UI, a natural ability to copy events between object types, and a natural ability to make minor tweaks to individual object code.

A flying block vehicle, which moves left and right when you shoot the green and yellow buttons

Playtesting feedback

Later in development, we got a bunch of friends in the IWBTG fangame community to playtest and maketest. Later on, we did a week-long public beta with a lot of people making the best and most complex levels they could. And, with our current launch on Steam Early Access, we’re getting even more feedback from both newcomers and veterans.

These multiple playtest periods of increasing size were great for recognizing pain points to fix and important features to add. One large pain point was making objects that move along a set path. Earlier on, there were redirection arrows you could place in the level, but this was clunky as you would have to use many of these in a level for complex movement. We replaced the redirection arrows with a Follow Path event, which lets you set exact points in the level for the object to go. We also added a Move To (x,y) Position event, which was very convenient for people who were making complex boss fights which we originally never thought possible. (There are no boss-specific tools in the editor!) Additionally, we added the abilities to reorder and visually collapse events to make it easier to navigate for people making contraptions with upwards of 20 events on 1 object.

Dan Salvato’s level “Cirno’s Math Class!” open in the editor

Result:

This organic evolution based on tried-and-true IWBTG fangame obstacles ended up being distilled into some versatile building blocks. This ended up working great for easily making interesting dynamic obstacles, so we achieved our goal!

In addition, if you push the editor to its limits, people have made multi-phase visually impressive boss fights, slot machines, 3D driving games, Super Hexagon, Undertale fights, music made out of pitched sound effects, eventful bicycle rides, Sudoku, rhythm games, etc. It’s amazing what people have made, and it makes the team quite happy! However, the point I want to make is we didn’t directly intend for most of that to be possible; it was more of a fortunate consequence of the modularity of the event system.

All the activator and action events in the current version of the game

Another fortunate consequence is a design space that feels focused and cohesive. Every event (and every object, for that matter) was added to support IWBTG fangame-type obstacles and mechanics. Even when the events and objects get “abused” to create things like a complex boss fight, things feel grounded to the world in a way, for both players and makers.

A good example is making a health bar for a boss, which is commonly a long line of water blocks (or any other fitting object), which each move 1 space to the left when the boss is shot. The last water block has a collision event with an invisible trigger at the very left, which destroys the boss. Compare this to a normal game which would just have an internal variable for health and might not even display a health bar. Another fun example is giving the player an infinite number of jumps, using an invisible cannon which follows the player and fires a jump-refresher whenever you jump, which you instantly touch, and it plays the familiar sound and particle burst. Compare this to a normal game which might just set your double-jump variable to 1, and not play any sound or particles. If we had events like Set Variable and Set Double Jump, we would lose this special overall feeling of consistency, as well as some fun creative constraints.

We were careful about each and every event and object we added. This cohesion ended up fitting very well for a Maker-type game (and I’d say cohesion and consistency are important for other types of game too!). We certainly didn’t think this far ahead when starting out; we lucked out a bit with this and it came naturally.

Water blocks as a health bar in RandomErik’s level “Crushman Stage”

I hope this list of developments of the I Wanna Maker level editor and event system was interesting in some way, and maybe gives you some ideas for iterating on other systems!