Merrak's Non-Isometric Adventures -- Planar Programming

merrak

  • *
  • Posts: 2576
Towers of Vallas is done!... and has been for a little while now. I'm not ready to release it yet, but I am ready to move on to another project.

I started a full-color isometric "Vallas game". While I got the programming side of things down pretty well, artwork and level design proved to be a significant hurdle. I started tinkering with my entry from Stencyl Jam 18 and realized that it was refreshing to have new challenges. It's easier to think about levels in 2D space than 3D--and certainly it is easier to draw artwork for 2D.

I began expanding on the Stencyl Jam game... mostly for practice at first. I like the direction it's going now, and it's still fun to work on. Enemy AI is my most significant programming challenge. The remaining challenges are mostly design related--an area I'd like more experience in. It's good to have some personal goals for a project--"what would you like to learn?"

I do want to make another game in this series. I introduced a cast of characters in Towers of Vallas. While this game would be a prequel, I can still add to the story. I don't like the title: "Thief of Vallas". It's a working title for now.

One potential problem I thought about--would it make sense to have a mix of 2D and 2.5D/3D games in the same series? I don't think that, in of itself, is a problem. There are plenty of examples of series that went from 2D to 3D: Mario, Sonic, GTA... some with better results than others. Those that lost their unique characteristics met with less favorable reviews, which brings up the next question--what makes a "Vallas game" just that? Besides the graphical dimensions, what do the games in the series have in common?

So far there are two completed games: Towers of Vallas and Temple of Idosra. Idosra may not end up being canon, though... at least, not as exactly presented. Reworking that one has been on the to-do list for a while. That makes Towers the only completed game, although there were several incarnations of Thief of Vallas going all the way back to my very first Stencyl game.

Here's the working list:

  • Action Adventure. This genre has been a consistent staple. Towers is the most slow-paced.
  • RPG Elements. All of the games, except Idosra, had some form of experience points and other RPG elements. I've purposefully omitted exp-grinding, though. There is a finite number of experience points in the game, and the player usually needs to clear an area just once to get what they need to progress.
  • Speedrun. The player is rewarded for moving fast: a higher score, spare resources, or some combination was the reward.
  • Books. Reading has always been the main avenue to advance the player character.
  • MUD Elements. A nod to text-based MMORPGs from the 90's. The usual RPG fare is there: individual character statistics, lots of skills to learn and character abilities to acquire. Many aspects of the game rules come from one MUD in particular... one I ran back at the turn of the century... including...
  • Style Points and Rogue Rating. Small bonuses at the end of the level (like the Smash Bros. "Special Bonus") and a rank assigned. The ranks have always been P (perfect), S, A, B, C, D. The perfect rating has always been 800. If you're a bit older and from the US, then you know the significance of the number.
  • Secrets. Lots of secret areas to find. Towers has tons of them!

All of the "Vallas games" have been a nod to some past computer system. I have a Gameboy-inspired game, an 8-bit inspired game, but no DOS game. DOS was the system I grew up with, too! So my "new game" will use the default 256-color VGA 13h palette.

Here is a short video play-through of the first level. It's not finalized, though. In particular, some of the graphics will be redone. There are some tiles I'd like to redraw. I definitely will redraw the enemies. All of the enemies are using their original sprites from the Stencyl Jam 18 game. They should all be bigger than Marika--not smaller.

<a href="https://www.youtube.com/v/7ccfJVXT8AY" target="_blank" class="new_win">https://www.youtube.com/v/7ccfJVXT8AY</a>

Getting a prefect rating is tough. One feature that was oddly satisfying to implement was the "Cool!" bonus that appears when you collect several gems in a row. There's a story behind that (of course!). I still remember in the instructions for Commander Keen 4 there was a line about how some of the candy collectibles were arranged so you can get them all "in one cool jump". I spent many hours in my childhood trying to figure out how to get extra points by collecting all of the jawbreakers at once. Of course, that feature wasn't programmed in. But now I have it in my game!

Bombini

  • *
  • Posts: 1363
Towers of Vallas is done!

Big cudos and congratulations!
All the best fun with the new game :)

merrak

  • *
  • Posts: 2576
Big cudos and congratulations!
All the best fun with the new game :)

Thanks! :)

merrak

  • *
  • Posts: 2576
Map Making May


Thief of Vallas: Working Title is coming along nicely, despite not having a proper title. Since my last post, I've put some more thought into how to organize the game.

I liked the way I have the levels arranged in Towers of Vallas: Four groups of levels (in the form of towers) linked by a central "hub map". TOV:WT will span across a larger geographic area, so an overworld map makes more sense than a hub area. I spent some time today setting up the map, illustrated above.

The overworld map is similar to the map in the Commander Keen games. The colored segments of the map open up as key levels are cleared. (The player won't see the colored paths. Those will be used by AI Tools so the player character knows how to get from Point A to Point B when the player selects a level).

Prior to the map, I've spent most of my time overhauling graphics. I wasn't liking the look of the first level: chunky brick walls, boring floor. The trees were okay, but I think I can do better. I'm not quite done, but I think the first level is looking a lot better.

Little details, like rounding out the bricks, adding some variation to the grass, and such go a long way. Here's a side-by-side comparison.

     

One challenge I've found to be more fun to work with than I thought is sticking to the VGA mode 13h default 256-color palette. This is, admittedly, a very arbitrary limitation. DOS games at the time could easily change the palette to consist of 256 out of 262,144 colors. I have a tendency to prefer darker colors, which this palette is lacking. The result is much brighter art assets than I'm used to, but I don't think that's a bad thing.

This is the color palette:


Here is the second revision to Level 1. I haven't done much with the level geometry yet, but that is still planned. The major updates are artwork related. There is also now a visible floor, and I added some new style bonuses.

<a href="https://www.youtube.com/v/iEw-69RUgUs" target="_blank" class="new_win">https://www.youtube.com/v/iEw-69RUgUs</a>


merrak

  • *
  • Posts: 2576
Fun with Frames.

TLDR--How I implemented a per-frame hitbox system. Also, playable demo with debug draw. See end for demo instructions.

Like the other games in the series, Thief of Vallas: Working Title is an action RPG. With larger sprites and more complex moves on both the player character's and NPC's parts, I've started borrowing from the beat-em-up genre. My experience with it is somewhat limited, so I've had to do a crash course in conventions like frame data, frame advantage, etc. Luyren shared this video with me a few days ago: (link!) and I also found another quick guide (link!).

The most significant technical challenge has been finding a way to define hitboxes that update every frame. I'm separating hitboxes from collision boxes here, since I want each to serve a different purpose. Collision boxes function as they always have on the physics side. A "hitbox", on the other hand, is only used to determine if and where one actor's attack hits another actor.

I'll use the player character, Marika, as my example. My next big hurdle will be drawing the images for the first few enemies. They've been set as placeholder images for a while, but I need the proper ones so I can configure their hitboxes.

Drawing Hitboxes. Since Stencyl doesn't provide a hitbox editor for my purposes, I had to make my own. I thought about making a full-featured editor, like I did for so many of these kinds of problems with my isometric games. In fact, I will probably do that at some point. When I'm done with this game, I'll be porting a lot of these features over to my isometric framework. For now, GIMP was an easy solution. I took my sprite sheet and drew the hitboxes over it.

Here is the running animation. I don't want to get too elaborate matching hitboxes to body parts--nor do I think I need to with all of my sprites roughly 20x48px. The three basic areas are: Head, Torso (referred to as Body in-engine), Legs. The intensity of red (or green for attack hitboxes) defines a damage factor. Brighter red is most vulnerable; brighter green is most powerful. I probably won't end up using the power factor for attacks, since each attack already has its own damage roll--but it wouldn't hurt to have the data there if I find a use for it later.


I didn't have this system in mind when I drew these sprites, so I got a bit lucky with how some of them worked out. Here is the dodge backward animation, which best protects Marika's head and least protects her feet.


When I'm done, I export the hitbox images without the sprite background. I drew the head, body, leg, and attack boxes on separate layers. I can have as many boxes and layers as I want, but two boxes cannot overlap on the same image. Overlapping boxes have to be placed on separate images.

Managing the Data. Loading the data into the game was fairly simple, but I needed somewhere for that data to go. I made a new HitBox class. I'll link the two .hx files below, which you're welcome to use if you want. They would go in as "Freeform Mode" behaviors.

HitBox
VUtility (supporting macros)

One of the nice features of HitBox is that it automatically adjusts for facing left or right. All of the coordinates are defined with the character facing right.

The database is the clunkiest part of the whole operation. The Hitboxes are stored in this beast:

Code: [Select]
public static var mapDB:Map<String,Map<String,Map<Int,Array<HitBox>>>>;
which represents the nested data: actor type name -> animation name -> frame -> list of hitboxes for that frame

A better solution would be to attach the hitbox data to the Actor class, or even Animation class. I still might do that in the future. For the moment, though, I want to avoid modifying the Stencyl engine. I'm early enough in development that I can see wanting to update my version of Stencyl before I'm done. This works for now, and I structured my behaviors so that upgrading would be easy if I decide to do that later.

Keeping the hitbox data up-to-date requires a simple retrieval from the database. All of my animated characters have an "Animations Handler" behavior. 'FrameUpdate', below, will update the hitbox data. Updating an animation sets 'Last Frame' to -1, which forces an update whenever the animation itself changes.


FrameUpdate calls HitboxUpdate that does the actual retrieval. The 'set hitboxes to' is the only line I would have to update if I update my clunky database to a more elegant solution. This is inefficient, but I don't think I'll be doing enough database look-ups for that to matter.


The final routine lives inside each of the attack behaviors. The custom block checks if any of the player's attack hitboxes overlaps with any of the enemy's damage hitboxes. This check occurs once per frame. If an attack animation has multiple frames with hitboxes, then multiple hits are possible.


So far, the only attack to take advantage of this feature is the relatively slow standing-kick, which makes it one of the more powerful attacks in the player's early arsenal.


Another sneaky attack is in the axe throw animation. When Marika reaches her arm back to throw an axe, if an enemy is standing behind her then they'll get clonked on the head.


Loading the Images. I use the Image API to load the aforementioned hitbox images. Each image is a table, with one animation per row and one frame per column. For each 64x64px frame, I scan for an upper left corner of a box. When an upper left corner is found, I trace the top and right edges to find the lower right corner. I don't really need to draw the whole box, but there's no reason not to.

Demo!

Here is a playable demo of what I have so far. My target platform isn't Flash, but it seems to work okay. I haven't balanced the attacks yet. (Largely, because I haven't updated the enemy sprites either) The instructions have not been updated since I changed a few other things around. To hang off of a ledge and climb, you no longer need to press 'up'. If you're facing right, hold down the right key; likewise for left.

The move point system is the same from Towers of Vallas. If Marika runs out of move points, her attacks become weaker. Climbing drains energy the most, but she won't fall off a ledge if energy hits 0. Getting a 'Cool Bonus' restores energy to full. You can get a 'Cool Bonus' by quickly collecting all of the like-colored gems in a group.

Press '1' to toggle the hitbox debug drawing.

Game! http://www.stencyl.com/game/play/42250

« Last Edit: May 25, 2020, 09:39:38 pm by merrak »