While playtesting and planning on filling content, there’s a few missing things I still need. (Well, immediate things as opposed to a mile-long list of features I want to do.) So I’m doing a bunch of things that are best described as things you encounter as you play along and progress through levels.

First of all, I organized my levels and added all the assets for each level:

I think I will have 8 levels or floors to the “dungeon”. Each floor defines its specific stuff:

While a couple assets remain common ones to all dungeons, as there isn’t any real difference to level-specific ones:

While testing level transitions and such, I also made the lose and win panels not show the buttons for a little while right after they appear, so the player doesn’t accidentally hit them and so they can actually see their character die or teleport away:

I am reusing this sort of logic is a few places. When I don’t need any other fancy UI timing, I can just slap this script on the UI and point it to the right place and then tell it to run whenever I need:

And for when the player enters a level, I want to show the level name to them:

I can extend my timed element logic to have different “styles”, such as both fade in and out, all on timers:

And this works great, announcing the level:

I’m also adding an editor debug script to manage current level progress, so I can quickly jump between levels:

I also realize I have way too many options for generating the layout. I can’t have versions for each level that I need to adjust every time I make a small change. So I’ll do the template-definition separation again. It’s the same thing I did for AI belief stuff. I have the template with all the data:

And I have the definition with any overrides:

So it would just collect the steps, but not change anything I don’t want to. Here, I just enable/disable steps if I want:

I can then add the actual values I want to override. In this case, I want to change the count for the steps, specifically the arenas in first level (I don’t want that many):

This way I can tweak my levels only where needed with minimal effort, while keeping a common data source. I don’t think I even need to modify any other options than counts, as all the other options are specific to those steps (like restrictions or origins or purposes) and don’t need custom rules there.

I also split up my boss into three versions by ability:

That way, each boss has its own unique ability (and, honestly, I don’t have the time to make multiple abilities per boss, I rather tweak versions of the same ability). And I can use my AI belief health rule checks to enable or disable it use, so each of the ability “tiers” happens at specific remaining health — boss gets tougher further into battle:

While going through levels, there currently isn’t any feedback for player’s upgrades (besides the upgrade terminal, but that only shows the ones that can be upgraded). In fact, I want something reusable I can show in multiple places. First, I’ll make a new info panel for in-gameplay viewing:

Then I can add an element that shows all the player’s upgrades:

I won’t bother with prettifying this yet; I just want the pipeline to be there. There is a new keybinding now to open this info and close it whiel in gameplay. And the game keeps running.

I similarly don’t have any feedback on player’s progress through the dungeon. So I am similarly making an element I can add to win and lose panels that display their current progress:

Again, I’ll do the pretty stuff later.

Anyway, these are a bunch of mini-features I can’t really fit anywhere else and I’m not expanding enough for individual posts.

MicroRogue DevDiary #55 – Level flow improvements
Tagged on:         

Leave a Reply

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