I am testing Game Maker Studio’s run-time executable option. I finally have a small build of SUPER III for you all to play!

W1 Preview

NOTE: Due to a depreciated xinput extension, I had to strip out all of our gamepad functionality. This first build is KEYBOARD-ONLY. I will have gamepad compatible controls in the next build (As well as AUDIO and more CONTENT)! Thank you for your patience!

ARROWS -> move
Z -> jump/teleport (in-air)
R -> game reset
ESC -> game end

The teleport resets when you touch a surface (wall(s) OR floor). Have fun!


Thank you for playing!


SUPER III has a composer!

It has taken some time, but we finally have everything squared away in terms of who will be responsible for music and sound design in SUPER III. I am very happy to welcome Joel Corelitz to the team! Joel has worked on several titles including The Unfinished Swan and the upcoming, Hohokum.

“Composer Joel Corelitz is known for creating emotional, design driven scores by fusing music and sound design into a unified audio experience centered around texture and mood. His technique of blending classical and electronic elements, utilized in his work for some of the most established brands in the world, is how Corelitz is proving himself to be one of today’s most innovative young composers in gaming, film, and interactive installations. Recent projects include Sony Playstation’s The Unfinished Swan, for which Joel received a British Academy Award-nomination for Best Original Music as well as Game Audio Network Guild’s Best Audio in an Indie/Casual Game Award and Rookie of the Year Award. His work on Loom garnered Siggraph’s Best in Show award for his work, as well as the Leo Award at the Braunschweig Film Festival.”

Find out more at

Joel contacted me way back during the development of FROG SORD. He seemed eager to work on an action-platformer that featured pixel art and I am more than glad to be able to have him on board for SUPER III.

The video in the link below shows off some of the progress that I have been making on our alpha build and also showcases the sample track that Joel sent the team several weeks ago.


Screenshot Saturday

Screenshot Saturday is worth a post, right? This shows off the new UI elements (possibly still WIP), new portals that take you to side missions during levels, and the teleport-stamina mechanic.


Design: Iterating on Mechanics

I have been asked by several people how I choose the base mechanics for my games. The answer isn’t simple, nor is it always the same. However, in this case I was asked how I chose the game mechanics for SUPER III by our friend Christian from of Indie Game Enthusiast.

He has recently started a popular thread called, TIGForum DevLog Showcase and in that thread you can see my answers to his questions as well as a bunch of information about a ton of other impressive DevLogs.

Excerpt from TIGForumDevLog thread:

Zack Bell on deciding the core mechanics for SUPER III:
“For starters, the teleportation mechanic was something that I have had lying around for quite some time. Awhile back, I had met Tommy Refenes of Team Meat and decided to replicate the controls seen in Super Meat Boy. I got the controls feeling tight and was fiddling with several different maneuvers to be used as a double-jump replacement. One of the many was a dash that was very similar to what you may have seen in FROG SORD. Another was the teleport that you now see in SUPER III.

I prototyped SUPER III for the IndiE3 Game Jam quite quickly. The level design was similar to Mario or Megaman titles. They were basically open, horizontal levels that left a lot of room for players to do as they please. However, limiting teleport distance was something that I wanted to avoid and long-distance teleporting left me with some jarring camera issues. To combat this, I made the levels more vertical and limited them to be a single screen wide. The screen-wrap was added to bring back some of the freedom and movement options that I lost by restricting the level size.”

Other games featured in the same thread include upcoming titles, Return of the Obra Dinn and Heart Forth, Alicia.

Return of the Obra Dinn

Heart Forth, Alicia

Anyway, I thought it would be nice to support someone who has been supporting me since the early days of FROG SORD development, as well as point out a few other games that are looking amazing!

Stay tuned for more SUPER III news!


Lina Strikes Again!

I don’t always search for Twitter mentions of #SuperIII, but when I do, I am often pleasantly surprised by what I find. I feel like I just got ahold of our World 3 tile set a day or two ago, and Lina has already pumped this out!

You can check out more of Lina’s stuff on her Tumblr page, or by following her on Twitter.


Update: Art

I just thought that I’d post updated images from each of the worlds that we have teased so far! Stay tuned for more! Also, note that the World 2 update is the most recent and includes a redesign of our character, III (Three). With that we are responding to feedback that mentioned that our player sprite(s) looked a bit static.





Inside Look: Flame Trap

For those of you who don’t know, the PC build of SUPER III is currently being developed in Game Maker: Studio. Some believe that GM is an inadequate programming tool, but I find that it is great for what I do and I wanted to share some of the tricks that I have learned along the way.

In this series I’ll talk a bit about GM code and a bit about how to polish the edges of your game concept to add “JUICINESS”. I hate that term, but I’m going to roll with it.

To begin, I’m going to discuss a single game object that I have recently implemented into WORLD 3 of our current project, SUPER III. A few people have already asked how I got the fire to look the way it does, and the answer is quite simple: minimize art and maximize your manipulation of the art.

The fire trap actually consists of two objects. The first one, “oFlame”, simply plays this small explosion animation.


That’s it. That’s literally the only “fire” art we have in the game at this point. It’s the second object, oFlameTrap, that does all of the work. After being triggered by the player, the flame trap runs the following code every frame, for 15 frames.

with (instance_create(x + 8, y + 12, oFlame)) {
    image_angle = random(360);

    hspeed = random_range(-0.5, 0.5);
    vspeed = -random_range(2, 4);

    image_speed = random_range(0.25, 0.75);

Is it efficient, not really? Does it work? Yes, and it looks how I want it to look. Part of making independent games is knowing that perfect engine architecture and program design is NOT number one. DO WHAT WORKS.

For those of you who are new to GM, this is what’s going on:

1) Choose a random angle at which to draw the sprite attached to oFlame.
2) Select a random (but slow) speed for the flame to be moving horizontally.
3) Select a random (but quite a bit faster) speed for the flame to be moving vertically.
4) Select a speed for the sprite animation to play at (this makes some flames last longer than others).

It is a simple process and it gives you the following as a result…


There are also other small things that make the trap work well. For one, the flames only damage the player for the first half of their animation cycle. This allows the player to safely jump through the smoke towards the top of the flame bursts. Also, the trap base shakes for 8 frames prior to releasing any flame objects. This is done simply by drawing the sprite at a random offset.

That’s all for now. Let me know if you would like more small articles like this in the future!