Let's Brainstorm on How to Make a Near-Codeless Game Editor.S

There's a post under this post. You should read it first before continuing.

In my last post, I talked about why a low-code game editor is crucial to fostering diversity within the ranks of game designers. Now comes the long overdue part where I talk about how such an idea might be implemented. It's long overdue.

First, let me give you an anecdote. It’s a little bit long, but every part counts so stay with me. As a child, I wanted to make to make video games, but I was terrified of programming, which I’d failed to learn on at least three occasions. It’s an old story, and one you’ve probably heard before. It might even be yours. And maybe because of my situation, I tried to get as close to making games as I possibly could. I could make any other aspect of the game I wanted: art, sprites, music, lengthy design documents, anything really. (Something that, now that I think about it, is a pretty bad sign.) I picked up spriting before I graduated 1st Grade. By 2nd Grade, I was cutting out hand-drawn “sprites”, putting them behind a distorted bottom of a plastic container for a pixilated effect, and moving them around if they were the real thing. Whether it was an act of enthusiasm or desperation I’ll never remember. But a few years later, I discovered Wrecking Crew.

Let's Brainstorm on How to Make a Near-Codeless Game Editor.

The level editor in action. Note the rectangular, orange and blue outline for a cursor.

Wrecking Crew was a puzzle game in which you played as Mario and Luigi, who had taken up jobs as demolitionists and had to destroy all of the structures in a particular stage without getting nabbed by their rival Foreman Spike and his gaggle of goons or accidentally breaking helpful structures like ladders and support beams and stranding yourself.

The second catch was that it came with a level designer. You could put a set of four customized levels together in the editor, and then play them out, advancing from one stage to the next. After looking around, I noticed other games had these level designers, too, particularly motocross racing game Excitebike (which you’ve probably heard of) and arcade-style platformer Milk and Nuts (which you probably haven’t.)

Level designers were heaven. Because the structure of the levels tied so heavily into the identity of the otherwise fairly simple 8-bit games, it felt as if you were making a game of your own within the game. There was a real sense of authorship that came from making your own section of the game, sections where you could point something out to a friend or relative and say "I made that! Want to know why I put that there?" It was the closest I had ever gotten to making a game.

So I made the most of it. I tinkered around with the tilesets and difficulty with the intent of making the biggest masterpiece I could muster. The culmination of my efforts was a stage entitled "Showdown," in which you raced Spike to the top of a condemned building and staged a showdown that ended with the entire building exploding and sending both of you over the edge in a spectacular fashion. I was in love.

But more importantly, it fairly easy to use. Putting structures together in a level was no less intuitive than building a block tower. All you had to worry about was what the combination was, which left much to be mastered, as level design tend to do. Some modern examples of this concept include Super Smash Bros. Brawl and Askiisoft’s Tower of Heaven, which not only lets you define the structure of the level but even the mechanics that apply in that stage. It lets you force the player to keep from turning left. It lets you make grass dangerous. It does crazy things. But the craziest thing of all is that it is the only example I can think of of a game that can be modified on the mechanical level in a way that maintains that block tower level of simplicity. That’s one of the missing links: a way to define mechanics in the editor.

The second missing link is versatility. It goes without saying that there are some fairly easy to use game design tools out there, like RPG Maker or Twine or Inform 7. And although all of are wonderful tools that have liberated a good deal of designers, it should be brought to attention that they each only work within one genre. This is because each of those genres are well enough-defined that the people who created the tools could make an educated guess of the kind of things that their users would want in their games. But nobody’s yet been able to make those sorts of connections between video games in general.

At the same time though, the five-minute experiment and the complex, high-profile game are generally made according to a different set of standards and priorities, and if we really wanted to dip into the full spectrum of possible games, it would be a good idea to include two modes of operation, a quick mode and standard mode, respectively. Which brings us to Anna Anthropy.

Let's Brainstorm on How to Make a Near-Codeless Game Editor.S

Fred Wood's Love, the game in question.

Any of you heard of her? She’s a writer and game designer (with more style than I will ever have) who, in her book Rise of the Videogame Zinesters, in considering the ideal tool for easy gamemaking, mentions a game with a sketchpad-like level editing system. This isn’t a bad idea, and it all ties into how we think. Out of all of us that wanted to design games as children, and among the children I know now who want to now, it was and is natural for us to conceptualize our ideas through drawing, and afterwards talk about what they were and what they did.

This ties into that "quick mode" idea. In the program Anthropy mentioned, you literally drew out the level and let the physics system figure out how your character would deal with it. Going a step further, you could draw a character into a scene and then specify what the character does or draw objects into the scene and tell what they do. You could add touches like allowing you to turn your messy terrain line into a straight one, or setting whether the characters can move freely in any direction or are restricted to side scrolling, or even drawing in frames of animation for a character, as if they were paper cutouts. There are a hundred million ways you can do this, and I’m not going to try and tell you exactly how, but starting with the way we think in real life is a good place to start.

As for the main mode, that’s a little more complicated, but not much more. If anyone ever gets it right, it will probably look something like an advanced level designer, since that's such an easy concept to understand. Users would define characters, objects, and structures, maybe drawing or importing them into a magnified square the size of a tile and then drop into a level in any place, building the game one screen at a time and setting things like angle (Isometric, top-down, etc.) physics, and rulesets.

The hardest part of either mode, and the most crucial part of all is figuring out how to tell the computer how rules work. One idea is to come up with a comprehensive series of core rules that we can expect of most designers (pressing X key will cause character to speed up or jump or get pulled in by a force or charge up something,) and allow them to mix, match and elaborate on any of those (charging, for instance, could be used as a stand-in for any kind of timed action, although fortunately it’s there for the people who will inevitably need it.)

Game Maker is a good example of how not to go about this. Actions are made from other actions, starting you at the bottom and having you work your way up. Only the actions are so dissected and basic that they become unrecognizable and it isn’t immediately clear how to put them back together again.

Going back to taking inspiration from the way people think, it would be more comfortable to make this process like a questionnaire, since we often think of game design in terms of questions (what happens when I get here?) and elaboration, starting with a simple concept and going into further detail from there.

For example, I could ask you to make a floating high jump with a bounce at the end from the following actions:

  1. Move Free
  2. Move Fixed
  3. Jump to Position
  4. Jump to Start
  5. If Block
  6. Set Friction
  7. Execute a Line of Code
  8. Gravity Direction
  9. Keyboard Event
  10. Keyboard Press
  11. Keyboard Released

...Which, even for those of you who could do it (and here’s a hint: You don’t use either of the commands labeled “jump.”) would take a little more experimentation and a lot of guesswork, especially considering that there are many more actions to choose from than those. Everything is very low-level, and it’s an example of a bunch of programmers designing a tool for designers and...thinking like programmers, who really have no choice but to work with relatively low-level concepts. Making a game suddenly requires both halves of the brain.

But one other way I could ask you to tackle this challenge is by asking you a series of questions directly:

  1. Press a key.
  2. What will your character do when this key is pressed? (for instance: jump, speed up, slow down, charge, duck (reducing hitbox,) warp position...)
  3. Will your jump use the default parameters, or will new parameters be set?
  4. Which ones? (for instance, height, speed increase, weight, float)
  5. What will the height of your jump be?
  6. What will the weight of your jump be?
  7. Will there be any special features added to the jump?
  8. Which ones (for instance: fast takeoff, bounce, double jump, etc.)
  9. Will your bounce use the default parameters, or will new parameters be set?

In this case you don’t have to deal with as many steps, and you know exactly where you’re going from the get-go. It's a more natural solution, and it's built around the way we come up with games, starting with a vague outline of an idea and elaborating as necessary.

As for other features, well, I could do this all day. The point is that it isn't logically implausible. There are a million other ways it can be done, too. And really, why not? Once again, I have nothing against programmers, and there will always be games that require technical mastery, but what I'm talking about is entry-level stuff that shouldn't require the level of technical expertise it does. It doesn't mean that no one should code at all, especially now when there aren't any real viable alternatives. By all means, code right now if you can, and learn right now if you can. Even the game editor should have some compatibility with programming and coding, in case of the occasion technical limitation, although hopefully they'll be just that: occasional.

Now, instead of wasting your time with half-baked dreams, I'm going to invite you into the conversation. Sound off in the comments and tell me, us, everyone what would be the best way of pulling off a tool like this. I am now signing off. See you soon!

This is also on my blog.