Merrak's Isometric Adventures -- Dimetric Dilemna


  • *
  • Posts: 1400
Very good stuff!
A couple of thoughts i want to share:

QOL Tuesday. My to-do list has dwindled to a mere 30ish items--down from more than 300. Granted, some of the items aren't very quick... such as "make all the cutscenes from the game". Still, it feels like I'm closing in on the finish line.
I think this is so very important. Ask yourself if you realy need it. I cut so much stuff i wanted. Iactually cut all some weeks ago to have an empty "i still need this"-list and i am still surprised how much effort it is to finish the game with no new features planned ahead. I am encouraging to cut as much as you can. I actually filled my "i still need this"-list with stuff i need to remove from the game again because it woudl take too much time to implement it properly or it does not have the impact i wanted. obviously i found out while playing and testing which i could never have done if i hadnt implemented a simple version of the feature.

Another big item on the to-do list: "Make music for the game". I think I have a pretty good handle on sound effects, but I realized I'm just going to have to license music. I think stock music is going to be the way to go, since it fits my budget.
Go the simple way yes. Make sure you buy/use music with the licence you wan to use it for (commercial/non commercial etc). There is fantastic stuff out there for a low price.

The last to-do item is to play through the entire game, from start to end. I've actually yet to do this since every time I find an issue, I tend to have to start over.
And this will take time. I force myself to play in context. I have a cheat menu which allows me to jump inside the game but this respects how the game works and i also force myself to play the entire game. its also important for the pacing and flow.
I think it gradually takes more time to finish the game the closer you are to the finish line. But its doable! Just dont loose motivation which i dont think you will :)


  • *
  • Posts: 2738
The Cutting Room Floor Special

The to-do list has been pruned of all known bugs and discarded ideas. Of course, new bugs may surface with renewed playtesting, so it's not quite over yet. I ended up tossing out some features I thought would be a lot of fun to implement. But then there's more to put into a sequel 8)

The limitation actually wasn't time--it was resolution. I wanted a lot more NPC interaction, but the tiny 160x144 screen doesn't allow  for much text or detailed images. In some ways, that's a good thing. I don't think players will be interested in reading walls of text... at least not until they're invested in the game. The small screen space has forced me to think of creative ways to get the game lore into the game itself.

Each map has an implied objective of entering a locked office, which may contain the goal. Any office that does not contain the goal contains a memo (sort of a 'your princess is in another castle' mechanic), but gives some clue to the bigger picture. The memos have to fit on one screen, so they read more like tweets.

So what didn't make it?

The big one--dialog system. This would've taken a significant chunk of time with little return because of the screen size. Definitely on the list for next time.

AI--I had bigger plans than what I actually implemented. Also on the 'definite' list for a sequel.

Graphics--Of course. The next big move will be to explore hardware rendering and see if I can get a full-color version of the game running smoothly

In-game tutorials--I hated to drop this one. The original plan was to have a 'z' or 'x' or whatever key hovering above an item the first time the player encounters it, so they'll know how to interact with it. I had the icons drawn up and then ran into a problem: the game now allows the player to customize the key controls to their liking. I could use text, but there's also gamepad controls, too. In the end, I don't think it's really necessary. The player is already alerted to special items with the prompt, and one button is used for all object interactions.

Various map editor tools--Aside from occasional bug fixes or tweaks, I'm done with map building. I had a short list of features to add to the edmap map editing tool, but they can easily wait.

...Ask yourself if you realy need it...
I have a cheat menu which allows me to jump inside the game but this respects how the game works and i also force myself to play the entire game. its also important for the pacing and flow.

Was a good advice! :)

I have my game console which works pretty well. Just type "cheat" in the console and away I go! The little navigation arrows and mini-map do a lot more to improve pacing than I thought they would.


  • *
  • Posts: 2738
TLDR: I learn some things about ARPG game design... also, beat the game for the first time.

First Playthrough! It took a couple of weeks, but I finally managed to complete the game. Yay! The usual showstopper was some kind of bug--either a coding error, or something wrong with the maps. While this wasn't a perfect playthrough, I didn't encounter any problem that made me have to start over.

Save games are a bit quirky. Anything other than minor adjustments to the maps will cause the save to not load at all. The state of every object in the game is saved, but not all of the data for an object. So editing a map can cause save games to 'misalign' with the world map data.

Anyway, how did I do? I got a final rank!

And died this many times

Death counts the number of deaths on his "abacus" in binary, with 0 on bottom and 1 on top: 1 + 2 + 4 + (8 is off) + 16 + 32... well, the game too hard. I didn't even attempt the secret map, although by the end I don't think it would have been hard.

I don't think I'm that far off the mark on balance, but I definitely need to move around some of the power-ups to smooth out the difficulty curve.

The beginning map, "Lobby Complex", feels about right. There are a lot of healing objects and is forgiving, but also hard enough to give the player some feeling of progress when they obtain the first few power-ups. At least, that was my feeling on it. We'll see how this goes in beta testing.

The A-level maps also feel pretty good. They get easy toward the end, but that was expected. I didn't want a strictly increasing difficulty curve. Instead, I wanted a general trend harder, but with ups and downs. I think a good comparison would be Mega Man--the first stage is hard, but they gradually get easier as you kill bosses and obtain their power-ups. But once you clear all of them, you move on to the next series of levels that gets hard again.

Each A level map has some kind of gimmick, darkness, projectile hazards, pits, etc. In the B level maps, I mix these up. B level maps can have multiple gimmicks.

The B-level difficulty is awful. HP, in particular, needs a lot of work. You start the game with 20 HP and by the end of the A level maps, work up to around 40. Enemies don't hit for very much in the A levels... about 8 on average. So by the end of the A levels I was feeling pretty strong... not immortal, but tough enough to handle everything. The first B-level enemy hit for around 30 damage... and I even did the maps in the intended order: B1, B2, B3, B4, which are designed with increasing difficulty.

You don't regenerate health in the game. I didn't want the player to be encouraged to sit around doing nothing... and since there's a finite number of enemies, regenerating health would trivialize long-combat. But this does mean I need to make sure there are enough healing items in the game. By the time I got to the third B-level map, I had consumed all of them. I had to edit my save game file to add more.

Once I completed the first C-level map, the game got easy again. At this point I felt like I really earned it--so that's good. But I think I could stand to make the C-level maps just a bit harder.

Despite all of the balance issues, I don't think it will be too hard to remedy. I took careful notes and have a good idea of what needs to be done:

More low level enemies. I didn't think to do this at first, but I can make enemies drop things. Putting more low level enemies and having them spawn power-ups at random can help with the healing object problem. In fact, I can even weigh the drop chances a bit. When the player is low on health, increase the odds of spawning a healing elixir. In conjunction, each map can have a weight so that lower-level maps are more generous with healing items than latter maps.

More skills. I need more passive skills that grant HP and energy. Adding more low level enemies will also put more exp in the game, so I'd need something to spend them on.

Enemy waves: At the moment, all of the enemies in the game load and once they're gone, they're gone. While I don't want random enemies, I can program some to not appear until some flag has been set (for example, picking up a certain key). This would also let me put some life back into areas the player has to traverse through multiple times. More importantly, this will let me smooth out the B level maps. Make the hardest enemies only appear after a key or some item deeper in the map has been found.

Make the last level larger: The lobby, A, and B level maps are large. The C level maps are small. This is intentional, since I imagined the C level maps as simply "boss maps".

The last level, "Cellar", is also small. But unlike with the C level maps, this time it felt lazy... like the game was now suffering from "Long Corridor Syndrome" that Jeff Vogel described.

But single-player RPGs have plenty of this too. So many of them fall prey to what I call Long Corridor Syndrome. At a certain point, late in the game, you can tell that the developers ran out of time, money and ideas

By the time I got to Cellar, I was blasting through even the toughest NPCs. It was actually a rewarding feeling. I had worked up to 128 HP, about 70 move points--enough to spam multiple powerful attacks in a row without exhaustion. I also hit for about triple what I started at. Since enemy knock-back distance is proportional to damage, I was sending enemies flying right and left. It would've been nice for the victory lap to last longer, and cap off with a final challenge that I knew I wouldn't have been able to beat otherwise.

The secret map is huge, so maybe I should've gone for it. By the time I got to Cellar, though, I was more eager to get to work implementing the adjustments I jotted down. I was looking forward to starting beta testing, but I think I need to do another revision and play through it myself first.

« Last Edit: July 24, 2019, 09:55:29 am by merrak »


  • *
  • Posts: 2738
Dauntless Debugger. One of the unexpected difficulties in debugging has been having to know everything in the code. If you've worked on larger projects before, you probably know what I'm talking about. But if you've only worked on small programming projects, one thing to look out for is the program becoming so large you start to forget key parts of its architecture.

Vallas Engine is huge: 2MB of code in 134 .hx files. Forgetting how certain parts worked wasn't as much of a problem in development. When I worked on AI, I focused only on AI. I didn't have to remember how the renderer worked or how gameplay actions worked.

But now that I'm playing the entire game through, problems can crop up anywhere and I need to be on top of the entire engine.

So that's a thing. On the plus side, with each playthrough I get past more and more of the game without a problem. I recorded a playthrough of the final level. It's a long video, but shows a lot of key features working together: lighting and shadows, inventory and objects, combat. I cut out the final scene that plays after entering the last room and ends at 'to be continued'... so there is more there.

The best part is at the start of Excavation Zone, around 5:10, where you use the lamp to explore a twisty cavern. This was the part I added after I played through the level the first time and felt it was too short.

Another highlight is the bridge room at 7:10-7:30. At first glance it's easy to miss that there is a chasm on both sides of the narrow walkway--it's very dark. The NPC in the room just through the gate was pushed off the ledge. I haven't added a 'screaming' sound effect yet. I have a love/hate relationship with Level 2B, which has a lot of these bridges.

<a href="" target="_blank" class="new_win"></a>

I'm also starting the process of looking for beta testers. I have a few lined up already, and I started working on a game manual. The game is a lot more complex than I thought before writing up all the instructions--but also much simpler than I would like. So it's an odd medium.

Mostly due to the resolution limitations, there is a far less focus on adventure and more on the hack-and-slash style of combat. My preference would be something closer to the RPG games I played growing up. Exile is one inspiration. Although it was a turn-based RPG, it's a good example of the adventure/combat mix I would like to have.

However, I do think starting with the simplest game was a good idea. For one, programming an even more complex game at this point may have been prohibitive. But also, I've always envisioned a series... maybe a trilogy. Starting simple gives me more room for the series to mature and grow.

So what's the (updated) future? Still mostly the same as the plan I've outlined before. When I'm done with Towers of Vallas, I'm thinking of immediately starting to revise it--add the missing features, full-color and full-scale graphics, and expand the story. One idea I've considered is using the Gameboy version as a freebie, then sell the full-color version. I don't want to just sell a re-skin, though, so would have the full version be a deeper game.

« Last Edit: August 05, 2019, 10:48:33 pm by merrak »


  • *
  • Posts: 1400
So what's the (updated) future? Still mostly the same as the plan I've outlined before. When I'm done with Towers of Vallas, I'm thinking of immediately starting to revise it--add the missing features, full-color and full-scale graphics, and expand the story. One idea I've considered is using the Gameboy version as a freebie, then sell the full-color version. I don't want to just sell a re-skin, though, so would have the full version be a deeper game.

You could also cut the current free Gameboy version (less levels) and release the full colored version with all current content. Use the Gameboy version as a teaser.


  • *
  • Posts: 2738
You could also cut the current free Gameboy version (less levels) and release the full colored version with all current content. Use the Gameboy version as a teaser.

I'd prefer the Gameboy version, as it's presented now, to be the cut-down one, then expand on it for the full version. The main reason for that is there are just too many ideas I couldn't even attempt because of both resolution constraints and engine constraints.

When I started developing the Gameboy version, I was still using Stencyl 3.4 with the legacy OpenFL. Stencyl 4.0 and the later OpenFL opened up a lot of possibilities I want to take advantage of. Per-sprite hardware shaders alone is a significant feature.

The game as it is now feels short--not too short, but short enough that I don't think I could cut anything else out. When it's behaving, I can beat it in under an hour. I imagine if you don't have the levels memorized it would take a lot longer, but I've also added some hints to help guide the player where they need to go, and added some features to help the maps feel less like mazes.


  • *
  • Posts: 1400
Ah that makes a lot of sense"
Plus you will be able to expand on the story universe you created.


  • *
  • Posts: 2738
hxScout Special! TLDR: A brief hxScout "tutorial" in the form of a walk-through of diagnosing a problem I ran into

One thing I've noticed walking around in dark rooms is an annoying lag spike every 15 seconds or so. You can see it in the video I posted, around the 6:41 to 6:42 mark. There is a brief pause when Marika is mid-swing. It's not related to combat, but that is when it is most noticeable.

hxScout is a great tool for diagnosing these kinds of problems. So I thought this would be a good opportunity to demonstrate how to use it, what to look for, that sort of thing.

Setup and installation is already covered in other threads on the forum, but if you don't have it, here's what to do to get started.

Download hxScout, then compile your game with telemetry enabled (it's in the advanced settings). You have to launch hxScout first, then your game.

When you launch hxScout, it begins listening for apps with telemetry enabled. When your game launches, you'll see a new hxScout session light up with a red box to indicate recording. You can stop recording at any time, or it'll stop automatically when the app closes.

At the very top of the screen is a timeline:

You'll notice part of it is highlighted (look at the right). The highlighted part is zoomed in within the larger window below it:

Each bar on the graph represents a frame. You can click on the bar to analyze the frame, or click and drag to highlight several frames. The total time of the frame(s) is shown on the right. You can see I highlighted the tall orange bar.

You want the bars to be short. Taller bars represent more time the game spent running computations. You can see on the right that one frame took a bit more than 2 seconds. 60 frames per second is the goal, so measuring seconds per frame is not good! But that's what we're going to fix  :D

Time is spent doing one of three things: Rendering, Garbage Collection, and Active Time. Rendering is represented in green, and Active Time in light gray (although I think it's supposed to be blue?) Normally, most of the time is spent rendering, which is to be expected. You'll see below if I highlight some frames and look at the profiler, I get a breakdown of each function in the whole program (this includes your behaviors you wrote, the Stencyl engine, and everything Stencyl builds off of...Lime, OpenFL, etc.)

The two things to look out for are Self Time and Total Time. Self Time reports how long the computer took to execute that one particular function, where as Total Time reports how much time the computer spent on that function and all functions it calls. A good example would be if you have a behavior that does some stuff, then triggers an event. Total Time would include both the behavior and the triggered event, whereas Self Time would only include the code or blocks in that particular behavior.

What this means is if you're looking for inefficient code, you should pay attention to where Self Time is high. "High" is relative to how many frames you highlighted. I look for high percentages of total frame time. It is helpful to have an idea of how long code 'should' take to execute. If you highlight a lag spike (a tall bar) and you see a function with a high Self Time, there's a good chance that's where the offender lies.

The profiler gives you an expandable tree that has to be opened up pretty far before you get to functions you're likely to recognize. This will show the internal names, but they should be recognizable. When you make custom blocks, give them good internal names so they'll be recognizable.

You can see below I opened up the tree several levels. Usually you'll find what you're looking for below com.stencyl.engine.onUpdate--so I get in the habit of opening the tree up at least that far.

Behaviors you created are usually preceded by scripts.Design, which in my example is "Isometric Renderer". This is a scene behavior in my game that does what you'd probably expect: draw the isometric parts of the scene. The next line is VallasEngine.MDSUpdate, which is an extension block I made, and everything deeper is part of the extension.

This particular example isn't interesting because it's working well. At least on my system, I tend to get an FPS penalty just from using hxScout. High 40s and 50s reported on hxScout tends to be 60FPS without it, so nothing here to worry about.

Now, let's look at the offender orange bar.

Garbage Collection is an interesting problem to solve. For those of you who are unfamiliar with the term, Garbage Collection is the process of reclaiming memory that is no longer needed by whatever variable claimed it. Any time you create a new string, image, actor, whatever, it claims memory. In older languages, like C, when you were done with that variable you would then have to free the memory so it can be used again. A common problem was losing track of some variables and not freeing their memory. This would cause "memory leaks": memory that couldn't be reclaimed until the program terminated. Garbage Collection automates reclaiming memory so you don't have to manage it, but comes with the cost of not having control of when it runs.

Notice that besides Profiler, the frame can also be analyzed for Allocations (memory claimed), Collections (memory freed by Garbage Collection), Activities (just a text display version of the graph above), and Trace.

Time spent in Garbage Collection is represented in orange, so the culprit is quite obvious: the lag spike occurred when the system ran Garbage Collection, and there was so much garbage it froze the game while it was being dealt with. Opening the Collections tab reveals just how much.

So what is all this stuff? Some of it will be obvious (although not always obvious where it came from), whereas some might require some research. Dynamic is the Haxe equivalent of the "Anything" type attribute, and a lot of variables in Stencyl use it. Like with the profiler, you can expand the tree to get a sense of what functions claimed the memory that is now being reclaimed... like so:

Unfortunately, I don't really recognize most of what this is. I could do some research--and might end up needing it--but I usually start with the easiest things first. Just because you see multiple symptoms doesn't mean they come from multiple causes. Sometimes addressing the issues I immediately recognize also fixes the ones I don't, so I'll move on.

Fortunately, the next one is in code I wrote, so I know exactly what is going on.

ClipVertex is a class that represents a vertex in a polygon. I use them in a lot of places, but mostly to handle shadows. When a shadow is cast against a wall and onto another wall, it creates a polygonal shadow. This shadow is represented as a list of ClipVertex's. Indeed, expanding the tree reveals this code is where all of these ClipVertex's come from!

If you go back to the master timeline, there are 4 orange garbage collection cycles in quick succession. This occurs when the level is loading, so I'm not concerned. I start playing the game after that, and play for about 30 seconds or so. During this play test I just walked back and forth between two dark rooms really fast. In that time, 1.5 million ClipVertex's were created, and now they have to be disposed of.

The next biggest offender is Array. 1.3 million Array instances were created. (For those unaware, this is what Stencyl refers to as list attributes)

But if I expand it further, I see that the offender is related: arrays containing ClipVertex's. So two of the three big garbage offenders were clearly related, and I'm hoping the third is as well. Sometimes detective work is easier than research. I don't get lag spikes in lit rooms. Shadows are only cast when lights move, and other than in level creation, lights are only moved in dark rooms when the player's lamp is lit. So I'm suspecting the Dynamic garbage collection is related.

Now fixing the code--that's an entirely separate issue! Half the battle is identifying the problem, and I think after all this I have a good handle on where to focus my efforts.

One of the benefits of writing your own code is you have a much deeper knowledge of how things work than if you use someone else's. That's not to say you shouldn't use other people's behaviors. Noone really writes code "from scratch" anymore. If you write your own behaviors or extensions, they're still on top of Stencyl--and Stencyl is built on OpenFL, and OpenFL calls system libraries on your OS. But I would say that if you write code you intend others to use, give your functions clear names, and write organized code, so that the next person can easily figure out the architecture when they need to.


  • *
  • Posts: 2738
hxScout Update. Fixed. The two "garbage collection towers" mark the level loading process. It's smooth sailing from there.

A good solution to a garbage collection problem is to recycle. Stencyl does this with actors. When you're done with a particular data structure, instead of abandoning it, store it away for reuse later. How this is implemented is by creating a list of recycled things... vertices in my case. When I'm done with a vertex, put it in a list. When I need a new one, try to pull one from the recycle list first. If the recycle list is empty, then create a brand new one. This adds a negligible amount of time it takes to process a new vertex, rather than processing millions of garbage vertices all at once.

Bonus tip. The game processes hundreds of thousands of vertices per second and runs smoothly. A frequent question is "how many of X can Stencyl handle at a time?" The answer varies depending on what "X" is, but if you're just talking about math, hundreds of thousands to millions of arithmetic operations per frame is a good answer.


  • *
  • Posts: 2738
Beta 1 is inching close to done! I've managed to play through the game with no errors at least a couple of times. There are still a few minor things to clean up, and one significant feature to implement. Other than that, things are looking more or less ready.

I wrote up a manual for the game. Click the link if you're curious about it.

Although a lot of the information is presented in the game itself, due to the small screen size I didn't think it'd hurt to have a more thorough guide. It's intended for the beta testers. Before final distribution I'll cut out the beta tester pages.

I added some more "quality of life" features. Hotkeys is one of my favorites. Before selecting an inventory object action, you can push one of the 1-9 number keys. Then any time you want to repeat that action, you just press the same number. It's simple to set them up and I like it better than giving the player a bunch of predefined shortcuts to memorize.


  • *
  • Posts: 1400
Beta 1 is inching close to done!Other than that, things are looking more or less ready.
Isnt that a nice feeling? ;)
I wrote up a manual for the game.

Very nice written. Good job!

Some thoughts i had:
  • You could add an index at the start. It helps to navigate the manual
  • The Beta Tester Feedback at the end: There is no call to action. Where should i send the feedback to or how? You could also put this in game which a send options. Makes it much easier for the palyer and you might get more feedback
  • You have a lot of very cool art and a nice artstyle. Dont undersell your game in the manual. I did a quick draft below (using text placeholder because i dont have the font).


  • *
  • Posts: 2738
Some thoughts i had:
  • You could add an index at the start. It helps to navigate the manual
  • The Beta Tester Feedback at the end: There is no call to action. Where should i send the feedback to or how? You could also put this in game which a send options. Makes it much easier for the palyer and you might get more feedback
  • You have a lot of very cool art and a nice artstyle. Dont undersell your game in the manual. I did a quick draft below (using text placeholder because i dont have the font).

Thanks for the feedback! The manual is in a sort of beta as well. I'd like to integrate more screenshots and artwork, but I also don't want to commit too much to the layout since parts of the game could always change in response to beta tester feedback.

At the moment I'm running a sort of "pre beta"--sending the game out to a few people who have never even heard of it, with the goal of seeing how easy the game is to pick up and learn to play. This was the group I had in mind while writing the manual--particularly the set of questions I asked. It'll also buy me some time to fix a few issues with the game code before the "real beta".

Chapters! One last-minute change to the narrative flow of the game--I decided to break it up into chapters. The game is non-linear, so this is a bit challenging, but I decided there would be several benefits.

First, chapter breaks also give me an opportunity to drop important exposition that doesn't fit with the current books/memorandums that can be found in-game. For instance, I can reveal to the player what Marika is thinking--and thus give hints on where to go next. These are the kinds of things that don't really fit in dialog. Other than chapter breaks, the only way I have to communicate to the player what Marika is thinking is through icons, and those don't say much :P

Chapter breaks are defined where an important item is obtained. The code structure is already there to support it, and this also makes the most sense from a narrative perspective. Obtaining a key, for example, opens up new parts of the game. Speaking to the prisoner in the first level reveals an important part of the story.

I made a couple of title cards to go with the transitions. There will be about six total... maybe one more or less, so I still have more to draw up.

I realized Marika looks a bit scared, or uncertain, in the above image. Though not intended, I like the way that came out. As the game progresses, I can show her looking more confident as she gains new skills.


  • *
  • Posts: 2738
Dimetric Dilemna. Although Towers of Vallas is not completely done until it moves out of Beta, I've been thinking ahead to the sequels and updates to the game engine. One thing that's been on my to-do list a long time is a good upgrade to the renderer: shaders, full-color, and improved resolution.

The latest question--should the Vallas games be isometric? Proper isometric perspective means that the angle between any two coordinate axes is 120 degrees. The common usage in video games (well, older ones) is a slight misnomer. When drawing an x or y coordinate axis, there is a 2:1 ratio of pixels across to pixels up/down, like so:
Code: [Select]
   oo    oo
 oo        oo
   oo    oo
The resulting angles are close enough, and the 2:1 ratio is easy to apply in pixel art.

But why not consider other ratios: 3:1, 4:1, and so forth? I took a quick look at some other isometric (well, dimetric) perspectives in use and thought about just how the selection would affect gameplay. It turns out that I don't think I should be using a 2:1 ratio for the kind of game I'm imagining.

First, here are some examples from a small, random selection of games.

Baldur's Game (original version)

Baldur's Gate uses a near 1:1 ratio pixels across to pixels up/down. The resulting projection is closer to a bird's eye view. Warcraft 3 appears to use a similar ratio (on average). 1:1 seems good for these kinds of games where you have a lot of units on screen, since it's less likely the view of one will be blocked by another.

I found a lot of examples of games using a 2:1 ratio. Of course, I searched for "isometric games", so this was bound to be the most popular result.

Diablo 1

Shadowrun Returns

Azure Saga

All of these games are the kinds of RPGs I'd expect most people to associate with isometric games. I found the number of modern examples interesting.

All four of these examples have one trait in common: height doesn't matter much in-game. Consider the "Z-Axis Test": Would the gameplay be significantly altered, beyond visual flair, if the Z-axis was removed and the game presented as a 2D top-down game? Based on the screenshots I've seen (I haven't played all of these games), I'd suspect the answer is "No."

The only game I've found that is presented in a 2:1 w/h ratio that makes use of the Z-axis beyond visual effects is Super Mario RPG. There's platforming: The game passes the Z-Axis Test, because the gameplay itself would be altered by taking the Z-axis out.

I never played Super Mario RPG, though. I played far, far more DOS games than Nintendo games. My first thought of isometric games with height was Apogee's Mystic Towers. It uses a 4:1 w/h ratio.

Mystic Towers

The game has platforming and height matters. It easily passes the Z-Axis Test.

There is one problem with Mystic Towers, though: I don't remember the game all that fondly. I recently pulled it up and played it a bit. It was more fun than I remember, so maybe my tastes just changed... but I still feel it fell short. Part of it may be the 4:1 ratio that makes aiming projectiles difficult. A 4:1 ratio means a few pixels distance vertically represents a large distance in the game world.  But platforming feels much easier because heights aren't foreshortened as much. A 4:1 ratio produces a perspective closer to that of a 2D platforming game.

So I can now boil down my observations into a simple rule: A high w/h ratio emphasizes platforming, and a low w/h ratio emphasizes unit position in a crowd. A real-time strategy game, for instance, should have a low w/h ratio so the player can easily see all of the units and visualize a strategy. A platforming game should have a high w/h ratio so the player can quickly assess height differences and plan jumps accordingly.

Vallas-- So now, what would be the best w/h ratio for "Vallas 2"? I created a few mock-ups with the Marika sprite from the StencylJam 18 game for reference. First, 2:1:

The 2:1 ratio is the one I currently use. While there is minimal platforming in Towers of Vallas, there is quite a bit more in the StencylJam 16 Temple of Idosra. The Vallas Engine renderer was really designed with heavy use of the Z-axis in mind. Neither of these games use it to the extent I'd like to. Platforming in Idosra was too clunky, and the resolution in Towers is too small to have large enough rooms for it. Even in the mock-up above I can only fit in three levels of height in a room.

On the other end of the spectrum, we have 4:1:

4:1 has some nice advantages. Not only can I fit in rooms with a lot of floor space, I can also fit in multiple levels. Four levels easily fits in the whole screen, and I could fit five or even six by using a room with less area. Another advantage is the 2D sprite fits.

In the 2:1 mock-up, the Marika sprite looks wrong. We should see more of the top of her head with her height foreshortened. This isn't a problem I had with Towers, because the resolution was so small. With the larger resolution I'd have to draw all of the character art in perspective. This makes it a lot harder to use tools like Spine.

The big trade-off with 4:1 is that the floor area doesn't take many pixels. I don't think this would be as much of a problem as it would be in a high-unit game (like an RTS game), but it could be.

I'm definitely considering 4:1, though. While Towers of Vallas is mostly a hack-and-slash game, that is a product of its resolution. I always imagined Vallas emphasizing exploration and adventure, not hack-and-slash. 4:1 would be more of an option than it would in the battle-heavy Towers.

Then there's the compromise-- 3:1:

I like this ratio, too. The 2D sprite still seems to work, although not as well as in the 4:1 example. I don't get quite as many tiles height for a large room, but that mock-up shows a very large room, too. I can fit more height in a smaller room.

The biggest drawback to 3:1 is math-related. All of my tiles are 64px wide. Since 64 isn't divisible by 3, I can't implement a 3:1 ratio without considering antialiasing. This is a feature I don't want to have to deal with. A quick solution would be to make tiles either 48px wide or 72px wide. 72 may be too large and give me less options for room sizes, but 48 may be too small for my sprites. If my sprites can fit in a 48px wide tile, then that would be the way to go. The optimal tile width would be a multiple of 12, which would make all three ratios possible math-wise.

I think 2:1 is currently out, unless something else I haven't thought of yet comes around to resurrect the idea. 3:1 or 4:1 seem to be the winners for the kind of game I'd like Vallas 2 to be. Reprogramming the renderer to experiment is doable, but I'm not looking forward to drawing tilesets in both configurations. A better solution would be to create some kind of texturing code instead. One idea that's definitely out is implementing both, and having the game switch between the two (or all three) when appropriate. That would necessitate two or three separate sets of sprite artwork, and one is more than enough work.

« Last Edit: September 15, 2019, 09:21:35 pm by merrak »


  • Posts: 1654
Very nice contemplation.

Personally, I believe that it is important to keep player-readability your main focus.
Especially when you want different height-levels in your game.
My advice would be to make mock-up of some scenes in a graphics program and to see what
problems arise if you put in walls and other things that would potentially overlap game playing areas.

" I always imagined Vallas emphasizing exploration and adventure, not hack-and-slash. "
Your towers game had some exploration and different switchable objects but the hack-and-slash was indeed dominant.
You have so nice story telling that it is a shame that the hack-and-slash takes a bit away from story-telling.
Although the way you can interact with the enemies was a nice thing. Not sure if you implemented that idea of having hacked-communication between the enemies.
That was a nice thought.

Your scenes look quite dark and that can effect player-readability. Lighting was nice and can help with that.
It makes a good atmosphere. And if you don't put in so many enemies the darkness can help in making exploration great!

As always it is great to read your thought-process and I applaud your efforts in making this journal!

Proud member of the League of Idiotic Stencylers! Doing things in Stencyl that probably shouldn't be done.