Dungeon Game Thing WIP Babble Bubble


the menu flow is going to see some serious adjustments over time. the first pass is straight up etrian odyssey, because i wanted a base to work from before we start reinventing stuff.

a UI designed for portables just doesn’t play that nicely with desktop interfaces. Currently actually the second tier stuff opens more cleanly with mouse control rather than controllers! which is kind of goofy tbh.

and if anything were actually confirmed wrt music i’d say something, believe me. i don’t like promising things that aren’t actually locked in, in some way.


You know, after working on several JRPGish projects I feel pretty confident at this point saying manually line breaking (and page breaking) text is the way to go.

I know implementation is trivial, but you’ll end up fighting things like awkward breaks and single hanging words anyway; I’ve found most well written JRPGish games seem to be manually line broken. Does Gideon still post here?

I must know: what are your keybindings for ADQE ? Apol likes A/D to turn and I’ve come around to it a bit, but conventionally they’re strafe…


A/D work as sliding, Q/E for turning, But you can also do Shift+A/D to turn.

Arrow key left/right are turn, unless you’re holding shift, then they slide.

edit: Whenever I get around to it I’ll add configurable keybinds though so it’s all good!

the code to set the debug keys looks like this:

InputMap.AddKeyMapping(openfl.ui.Keyboard.W, -1, MOVE_FORWARD);
InputMap.AddKeyMapping(openfl.ui.Keyboard.S, -1, MOVE_BACKWARD);
InputMap.AddKeyMapping(openfl.ui.Keyboard.A, -1, MOVE_STRAFELEFT);
InputMap.AddKeyMapping(openfl.ui.Keyboard.D, -1, MOVE_STRAFERIGHT);
InputMap.AddKeyMapping(openfl.ui.Keyboard.Q, -1, MOVE_TURNLEFT);
InputMap.AddKeyMapping(openfl.ui.Keyboard.E, -1, MOVE_TURNRIGHT);
InputMap.AddKeyMapping(openfl.ui.Keyboard.UP, -1, MOVE_FORWARD);
InputMap.AddKeyMapping(openfl.ui.Keyboard.DOWN, -1, MOVE_BACKWARD);
InputMap.AddKeyMapping(openfl.ui.Keyboard.LEFT, 1, MOVE_STRAFELEFT);
InputMap.AddKeyMapping(openfl.ui.Keyboard.RIGHT, 1, MOVE_STRAFERIGHT);
InputMap.AddKeyMapping(openfl.ui.Keyboard.LEFT, 0, MOVE_TURNLEFT);
InputMap.AddKeyMapping(openfl.ui.Keyboard.RIGHT, 0, MOVE_TURNRIGHT);

whenever I add a config file it’ll be fine.


he even animates and stuff

this is also the first persona art


I’m curious about the meaning of the -1, 0, and 1 values.


“I haven’t written enums for this yet”

That’s the parameter for a modifier key.

-1 = Any can be pressed or unpressed, don’t care
0 = No modifier keys allowed
1 = Shift.
2 = Ctrl.
4 = Alt.

Basically if you set add the modifier keys you want together it will only accept that combination, and disable if the others are pressed. But you can also set it so that they don’t care.

They should really be constants, but, well, I was in a hurry when I first wrote that, so…
edit edit: look, ok, better now

        InputMap.AddKeyMapping(Keyboard.UP, InputMap.MOD_ANY, MOVE_FORWARD);
        InputMap.AddKeyMapping(Keyboard.DOWN, InputMap.MOD_ANY, MOVE_BACKWARD);
        InputMap.AddKeyMapping(Keyboard.LEFT, InputMap.MOD_SHIFT, MOVE_STRAFELEFT);
        InputMap.AddKeyMapping(Keyboard.RIGHT, InputMap.MOD_SHIFT, MOVE_STRAFERIGHT);
        InputMap.AddKeyMapping(Keyboard.LEFT, InputMap.MOD_NONE, MOVE_TURNLEFT);
        InputMap.AddKeyMapping(Keyboard.RIGHT, InputMap.MOD_NONE, MOVE_TURNRIGHT);


See? The code review process creates a better result for everyone.



Selections added! There’s an outline/highlight on selected targets. Currently it even lets you highlight dead chars which is kind of oooooops.

These aren’t actual enemies but PC sprites, i’m just using them to test with.

With scripting and combat basically ‘feature complete’ I’m focusing on cleaning up the art assets now.

Current todo, code-wise:

  • Some sort of battle arena so the characters aren’t embedded in walls anymore. Either camera motion or an actual battle transition.
  • Effect Animations
  • Gradient shader so the characters are more varied colors
  • Finally, finally adding sound.


they bounce and jiggle




this is delightful. hit me up if you want a br-portuguese translation.



video clip! what’s here:

  • Full combat system and UI
  • Character portraits (animated)
  • Palette shader (will be applied to enemies too)
  • Fully animated enemies!

What’s not:

  • Damage calculations are still stubs with // WRITEME
  • Visual effects on attacks/hits/etc


My brain is completely done for the day, it’s been a long week.

Road to scenario building time:

  • Combat effects (heal/etc animations)
  • Fix a number of minor UI issues; like adding animation to portraits or fixing the ghost outlines on selections.
  • Sound… This’ll probably be next because it’s not hard.
  • Asset loading for 3d dungeon content like walls (easy because the framework’s already there!)


Anyway I’ll be taking a break from post spamming for awhile probably.


edit: reupped the videos in the previous posts because of course sb deleted them

edit edit: new gif, fixed the blank frame bug, higher frame rate, etc


Finished effect code! More or less.

So this basically leaves sound/music and a bunch of UI stuff.

Everything here is super modular-reusable so I’m giving thought to just doing a few small-ish projects instead of trying to use this engine to do one gigantic uber project that never gets finished.

I have some stuff in mind here! That need to percolate a little more.


Been a rough month, have had to refactor a bunch of code to fit New Functionality but think I’ve finally made it past the humps and can get this to a ‘done-ish’ state in May.

Main focuses right now are:

  • Making the dungeon art nicer
  • Adding sound effects to everything
  • Adding music. And making it flow nice, so it doesn’t just restart the tune every time you get out of battle or whatever.

Dungeon art’s the one that needed the most refactoring. Music actually needs some too, just in the libraries I’m using because they handle looping incorrectly! Oops!

This is a “I am not doing nothing” post. Kind of taking time off social media for the weekend or so to get this hammered out.


Finally the post you’ve been waiting for!


So I’m finally getting around to adding combat algorithms and I needed to decide a basis for how to balance the game, so that I don’t end up shooting myself in the foot when I design the primary/secondary stats, so that I don’t want to curl up and die six months down the road.

First step was to decide on an algorithm. I decided to go full-on ratios, so the damage value is going to be multiplied by a ratio of the form (2 * atk / ( atk + def ) ). This means that if attack is equal to defense, the ratio is exactly 1, so damage will be transmitted directly. Otherwise, damage is scaled based on the difference between attack and defense.

In the upper left chart, you can see this ratio in action. You’ll do roughly 2/3rds damage against something with twice as much defense, and about 20% more damage against something with 2/3rds as much. This might seem like something bad, but bear with me here.

My core rule for game balance is that I want the average enemy to take a set number of average-powered hits to finish. For now, I’m sticking with 3, but probably going to switch it down to 2.75 or something so that there’s some leeway for players. In the upper right chart, you can see that when you have half as much attack power, it takes 4.5 hits to kill an enemy, which is quite a bit more! But still in the ‘doable’ range.

But while that’s kind of important, it’s not that big a deal in the long term. Primarily this just tells us how long it will take us to kill tanky enemies (pretty long!) vs not so tanky enemies (not too much faster!), and that’s a good balance, but what we’re really interested is the level differentials.

And there enters the lower left chart!

That one shows how many attacks it would take an average level 20 character to kill an ‘average’ enemy of higher or lower level. You’ll notice it’s a fairly straight line but scales up rather rapidly. Not terribly unexpected nor terribly out of line. But why does it work that way?

Well, to achieve the enemy dying in 3 hits at ratio 1, on average, you set the HP value to the average damage they will take times 3. Their defense is still higher, and still mitigates damage from lower damage levls.

What does this mean? I have exactly two coefficients for balancing!

  • The average number of hits to defeat an enemy.
  • The rate at which defense scales wrt attack with level.

With these two values I will know (a) exactly how long fights will take, and (b) what the viable range for the players is. I can then make the players scale lower so that they have to use more powerful skills/items to push through what would normally be an ‘easy’ fight. I also know how far ahead they can push before the game gives them diminishing returns and forces them to grind a little for stats and/or items.

Next: Primary and secondary stats!


So after a lousy couple months and being hung up on graphics/sound upgrades, I’m taking a bit and working more on game engine/loop/UI stuff as a break from that.

Because my brain is fried and demoralized.

I know I promised stats but I haven’t decided on them yet and I have things to say about them at some point.

Since I’m aiming for classic Wizardry/Etrian style, what we get is:

  • Town navigation! (a map you click places on? A menu? I dunno!)
    • The inn, of course, because you have to have an inn
    • Some place to hire/fire characters/handle party stuff in general.
    • The shop, which is probably going to be the most complicated UI code in the game tbh
    • Figure out some other places? Quest place? Generic Useless King In A Palace Asking You To Do Stuff?
    • Dungeon entrance things? Pick a location?
  • Camp screen stuff
    • Item management
    • Equips
    • Stat screen
    • Skill allotment/configuration?
  • Globals
    • System screen
    • Configuration stuff?
    • Going to just dump everything into json. Don’t care.

This sounds like a lot but it’s all fairly piecemeal and mostly making measurements/mocking things up.

Actually it is a lot.

RPGs are Work[tm]

I would like a game that plays nicely w/ touch/mouse interfaces so I need to actually plot out layout a little bit. Probably just going to do a few silly mockups of each screen.

I mean, it’d be fun to just ‘copy’ Etrian but I’d like to think about user patterns here and realize that most users are going to be on mouse/kb/touch and not gamepad. (still aiming to support gamepad though! there is a plan here!) so I’m probably going to think in terms of how many clicks deep I need to get for anything.

these notes are more for my own use than for anyone else to care about, trying to get momentum back up by doing simpler things than the big ticket items


:kissing_heart: :ok_hand:[quote=“mauve, post:39, topic:4188”]
mouse/kb/touch and not gamepad. (still aiming to support gamepad though! there is a plan here!)

accounting for variable display and input densities can be a hairy little set of problems. am interested to see where you go with this.