Merrak's Non-Isometric Adventures -- Planar Programming

merrak

  • *
  • Posts: 2738
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: 1400
Towers of Vallas is done!

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

merrak

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

Thanks! :)

merrak

  • *
  • Posts: 2738
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: 2738
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 »

merrak

  • *
  • Posts: 2738
Video October. For a change-of-pace, I made a video devlog entry. Enjoy!

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

Bombini

  • *
  • Posts: 1400
hi merrak!
i love this format.
it is very personal, easy to digest and holds so much information.

Very nice! Please do a november one as well :)

merrak

  • *
  • Posts: 2738
hi merrak!
i love this format.
it is very personal, easy to digest and holds so much information.

Very nice! Please do a november one as well :)

Thanks! :)

I've been thinking about making one per week, although I picked a bad week to start if I want to do that. Bi-weekly may be better. I think for this sort of thing, updating regularly is more important than frequently--and, of course, having something interesting to say.

Based on some feedback I got from the Discord, I've steered toward AI this week--which I think would make a good topic.

Bombini

  • *
  • Posts: 1400
One small thought to make it more even more appealing (and should not be a lot work): Show game footage when you talk and dont do anything on screen like in the beginning of this video.

Looking forward to the next one!

merrak

  • *
  • Posts: 2738
One small thought to make it more even more appealing (and should not be a lot work): Show game footage when you talk and dont do anything on screen like in the beginning of this video.

Looking forward to the next one!

Sounds like good advice! Unfortunately, I already uploaded Devlog 2 before I saw it--but I'll keep it in mind for the next installment. Thanks!

merrak

  • *
  • Posts: 2738
Devlog 2. Making the "knife guy" a little more fair by adding a delay between alerting and attacking.

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

merrak

  • *
  • Posts: 2738
Devlog 3. In this week's update, taking a look at frame hitboxes and character states. Good stuff!

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

merrak

  • *
  • Posts: 2738
Devlog 4. This week's update includes solving two common problems: implementing "achievements" and persistent actor deaths (once an actor is killed, it stays killed if the scene is reloaded)

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

mdotedot

  • Posts: 1654
Wow those resources in the dashboard are immense.

I never thought that the game had so much depth and things going on.

Again: very interesting.

The Unique Identifier thing is nice. I am more of a puzzle designer so I don't use the scene editor of Stencyl much. I use text files for levels. Actor creation is dynamic and every actor/object has its own unique number. A range defines which actor type.

The persistent-npc-death and achievement system is nice!  I like the fact that you can revisit a level to get every item. But I would show the possible achievements graphically and an option to do'nt advance to the next level but go back.
That is : if you can go back instead of starting the level over. Going back would be a much better immersive feeling.
(Allthough the game looks too dificult for my skill-level :D )


The book-mechanism is a bit confusing to me. Do you get the powerup AFTER you read the book. Or do you get the power up when you have earned enough XP ?
From your design document:  "Books. Reading has always been the main avenue to advance the player character."
If in fact you only get power up after you read and especially when you regard it kind of as a tutorial it should be better brought to the player. From what I understand now : you have to access it through menu system?!?


You state that refactoring code is a bad feeling because nothing visually changes.
I usually get a good feeling about refactoring. Just like what you describe: hours lost on debugging a strange system. Not sure in what part of your code is actually involved in states/mechanism.
Also working on simplifying stuff feels good.
But I do realize that it depends on the project. For a game jam  for instance you just try to do things as fast as possible even if it relies on copying a bunch of stuff that could better be grouped together.
Your current project has a scope that is much broader and you , indeed, need to keep your eye on complexity.

Keep up the great work with these developers VLOGs. Excellent stuff!

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

merrak

  • *
  • Posts: 2738
Keep up the great work with these developers VLOGs. Excellent stuff!

Thanks!   :)

Quote
But I would show the possible achievements graphically and an option to do'nt advance to the next level but go back.

I like the idea of having a list of possible achievements. I made a comment about having a prompt at the beginning that lists of the "mission objective", so that would tie in nicely. It's worth pointing out that there's still a lot of work to do on the user interface front. I still haven't replaced the current level select prompt.

You can always go back to previous parts of the level, but some of the achievements are time-based. The only way to get those would be to play the level again.

One idea I've been toying around with is having a 'hard mode' version of the game that doesn't allow level replays. While it would take some careful thought to make sure the player can never enter an unwinnable state, I like the idea of having a 'hard mode' that is more meaningful than just raising the stats on the enemies.

To gain a new skill, you have to have both the book and the required experience points. The experience points are then spent by reading the book. I mentioned MUD servers a couple of times: the skill system in the game is loosely based on the one found in ACK!MUD (the base code my own server was a derivative of). Instead of having one "level" for the character, the character leveled each of their classes (as in 'warrior', 'thief', etc.) separately. Since the player had a choice, leveling was not automatic--the player had to spend EXP to gain levels in their chosen classes. ACK!MUD also had 'practice points' that acted as a sort of proxy for time spent learning. In my own server, I started moving away from this system. I added books to replace 'practice points'. By the fifth version of the code (which was never released) I ended up with a system much like what all of the 'Vallas'  games have.

As far as refactoring goes: I was starting to find the fun in level design again when I started hitting brick walls with the old system. It's a setback and I'm wanting to move on from the animation system. I think the results will be worth it, but it's not how I was planning to spend my free time.