Super Tony Land: First Look at the Alpha

Super Tony Land: First Look at the Alpha

So, I’ve played through the Super Tony Land alpha demo levels that have been released so far (that last level is a killer!), and I’ve tried out the level editor, and here are my thoughts so far.

See that guy in the upper left? He really sucks.

Super Tony Land is, of course, heavily inspired by the Super Mario Bros. series, right down to many of the enemies having similar behavior but a different appearance: it has snails instead of turtles, “pipe snails” instead of piranha plants, and so on. This is not a surprise; the name “Super Tony Land” already kind of gave that away. And it’s not a bad thing; there’s a reason that Super Mario Bros. has been such a popular game.

But if Super Tony Land were just a Super Mario Bros. clone with different graphics, there wouldn’t be much point to it. And of course it’s not. There are different power-ups, and there are some new kinds of blocks. More importantly, there’s a bit more physics to it; thrown blocks and fired missiles have more complex trajectories and environmental interactions. And the levels have up to three layers, and you can see the lower levels in the distance when you’re on the upper levels. But the biggest thing that Super Tony World brings to the table, and the feature that most sets it apart, is something the developers call “tronics”. These are tiles that can fire signals in response to various events, and/or perform certain actions in response to signals they receive. Tronics are connected together by colored lines called “wires”.

This pinball machine from the demo is implemented through a huge mess of tronics.

There’s a lot more I could write about the game, but this blog is supposed to be about game creation systems, so… let’s talk about the level editor.

I should emphasize, of course, that this version of Super Tony Land is an alpha release, and the final version will no doubt have a lot more content and more features, will surely be more stable, and may be much improved in many other respects. (For one thing, it’ll have a custom block I’ll help design.) But I think it’s still worth taking a look at what’s there so far. Obviously, many of the criticisms I have of the level editor as it stands may and probably will be fixed in the final release.

For the most part, the level editor is, well, pretty standard. You select the type of block, monster, or item you want to place, you click to place it. You can also select rectangular blocks of tiles, and move tiles or selections around.  Again, that’s not a bad thing. There’s a reason this method is a standard: because it works well. Oh, there’s a little more to it; you can place many blocks in the background, and you can press F to rotate tiles. (Why F? I honestly don’t know. F for… flywheel? )  But for the most part it works about the way you’d expect, and it’s pretty intuitive.  You can scroll around the level with the arrow keys, and switch between the level’s three layers with the Page Up and Page Down keys.  A master map at the bottom of the screen shows the entire level, with all three layers superimposed.  (One minor annoyance: the mouse wheel seems to be the only way to zoom in or out. It would be nice to have an alternate keyboard control for this for people without mousewheels.)

The level editor in action

One thing I did miss was a fill feature, a way to fill an area with a particular block. I wanted to fill a level with water, but there was no obvious way to do so aside from laboriously clicking on or dragging over every space in the map. (Maybe that’s what the F should have been for.) Also, there doesn’t seem to be a simple way to see where a door or pipe goes after it’s been placed in a level. Oh… and a way to copy and paste selections might be nice, too, so when I wanted to have two identical arrangements of blocks I didn’t have to recreate them manually.  Okay, three things.  But again, this is an early alpha release; maybe those features will be in the final version.

In a neat little touch, the level data is stored in .png image files, the image being essentially a screenshot of part of the level and the actual data presumably being in ancillary chunks. What makes this kind of nifty is that it makes it easy to identify a level at a glance in Windows Explorer.

Okay, wait, there is one more minor thing I missed in the level editor.  Many tiles had alternate versions that the editor randomly chooses between.  You can re-randomize them by clicking on them with the Move tool, but there’s no way I could find to manually select which version of the tile you wanted.  In one of the levels I was creating, for instance, I was using the ship tiles to fill in for tree trunks, which looked okay but required a lot of clicking with the Move tile to avoid portholes in my trees.  So four things.

But again, what really sets Super Tony Land apart is the tronics. So how do those work in the editor?  Well, you can select tronics from the Tronics menu, and you wire them up with the Wire tool, clicking on the appropriate nodes you want to wire together.  The tronics are very versatile and powerful; the developers refer to them as a “block based programming language”, and that’s not inaccurate.  I’m not a computer scientist, but I’m pretty sure the tronics system is Turing complete, subject to the usual qualifier about memory limitations.

My first non-trivial tronics circuits

Virtually everything in the game beyond just mapping is done with tronics.  I struggled for some time to figure out how to get NPCs to talk before I realized that it wasn’t done by setting anything on the NPC at all; it was done by putting tronics near the NPC, and triggered by the PC’s entering a certain area (or by other criteria).

The gist of tronics is that “Flow” is carried between the tronics by the “wires”, and each tronic is activated when the Flow reaches it.  Some tronics generate Flow under certain circumstances—when something passes through a certain area, or when the player bumps them or presses directional buttons near them, or simply at particular intervals.  Most tronics have a Flow In and a Flow Out node, so the Flow can pass through them into the next tronic in order.  The main exception is the Data Tronics, which essentially act as variables, storing data (numeric, text, or even objects) that certain other tronics can read or write to.

There were a few things it took me a while to figure out, though this is largely because the alpha was, understandably, sparsely documented; there is a “work in progress User Manual“, but it doesn’t go into much detail.  I’m sure the final version will have much better documentation.  I was stuck for a while figuring out how to group objects together so they would move as a unit.  (As it turns out, there’s a certain small number of types of block or tronic that can be used for the foundation of a group, and in order to make a group, your selection must include one and only one of these tiles.)  The Move Tronic baffled me for a while, but only because I hadn’t noticed the two nodes on the left side.  All in all, though, it’s not hard to get used to, and it’s a fun system.

There are a few things that did bother me a little.  If while you’re wiring you pass over a node that the wire could connect to, the wire currently attached to that node gets automatically disconnected, which was sometimes an annoyance.  I kept wanting to hit Escape to get out of submenus like the Enter Data submenu for Data Tronics, but no, Escape brings up the main menu; the only way out of those submenus is to hit the OK or Cancel buttons.  Also, there were some times it would have been convenient to attach multiple wires to a tronic’s Flow Out node, but this didn’t seem to be possible; a tronic could have multiple wires connected to its Flow In, but not its Flow Out.  My guess is that this may be because of the programming language metaphor—well, it’s not exactly a metaphor; the tronics really are effectively a visual programming language; but that doesn’t mean they have to work exactly like other programming languages.  Generally, of course, a particular subroutine in a programming language can be called in multiple places in a program, but a single line in a program can’t simultaneously call multiple subroutines, or execute multiple commands.  For the tronics, though, you can already have simultaneous flows by, for example, having multiple Pulse Tronics; there doesn’t seem to me to be any good reason not to make it possible to have flow simultaneously leave a tronic through multiple wires.  Or at least, if not to allow multiple wires to be hooked directly up to the same Flow Out node, to maybe have a Splitter Tronic with a single Flow In node and multiple Flow Outs… there are times something like that could really come in handy.

Anyway, I’d hoped to be able to make a little game with the alpha demo of Super Tony Land, and I made a good start on one.  It wasn’t going to be a very long game, because it would have to be completable in one sitting, given that there’s no way to save.  (Presumably there will be in the final version.)  Unfortunately, though, the alpha just seems too unstable.  I ran into a few glitches here and there, but the first major setback was when I found later the same day I took the screenshot of the tronic circuits above that all the wires had disappeared.  I tried rewiring them, but the blocks that had been grouped before refused to re-group (or at least refused to stay grouped after I tried playing the level), and I eventually had to go back to an older save.  Later, though, things got worse, and my level stopped loading at all, either freezing the program or causing a weird error where the entire screen was brown and the only blocks were pipe ends.

The Brown Screen of Death

I think I may have just made the level bigger or more complex than the alpha version of the editor could handle—the level is currently 268KB, and the largest of the sample levels that comes with the alpha is 160KB (and I couldn’t load that level in the editor either!)  I thought maybe it might be just due to the limitations of my laptop, but I ran into the same issues when I tried running it on my desktop, so… either I’m just going to have to make simpler levels, or I’m going to have to wait for a more stable version of the editor before I can finish them.

Again, though, this was an alpha version of the game; I knew going in that there would likely be bugs, and so did the developers.  And in any case, the work I put in on these levels that I now can’t load won’t be for nothing; I’ve got a much better handle on how the editor works now, and hopefully these levels will be loadable in later versions of the game, so I can finish them then.  In the meantime, even if the issues with the alpha have prevented me from finishing the levels I was working on, I had fun playing around with the editor, and I’m looking forward to getting a more stable version so I can really do something with it.

(At the time of this writing, the Kickstarter still has sixteen days left, so there’s still time to pledge if this sounds like something that would interest you.)

Spread the love

Leave a Reply

Your email address will not be published. Required fields are marked *