So... back of the envelope RPG damage calculations?

[overclockedmind]

So, as I mentioned elsewhere, I am going to try and do a JRPG, in OpenXTalk. I am sitting here thinking... jeez, the calculations for "how hard did I hit that gnome" include character level, the Attack rating of the weapon, any elemental affinities or resistances it might have, the total Defense of the target gnome, probably his level...

You can see why this would have me all manner of messed up. I had heard that basically for FF1 on the NES, they just sort of borrowed a Popular at the Time (D&D) ruleset, and of course, there were bugs in the calculations where things that should have mattered got ignored or totally messed up.

I'm not trying to flat-out lift anything per se, in fact I think my other laptop has a list of stuff where I started with "OK, let's just list the involved factors as a start" but I'm not on it right now.

Does anyone wanna lend a hand? If we have any D&D players about, or something similar, I'm betting this gets a lot clearer, a lot faster.

[tperry2x]

This very much reminds me of the original borderlands. I was once part of the playtesting group a long time ago, on one of the early access builds. (I only played a small part: no pun intended).
There were all manner of damage calculations going on;

The level of the player,
The level of the opponent you hit,
What special items you might be carrying that enhance your abilities,
Any special items the opponent might be carrying that enhance their abilities,
Any environmental effects that may hinder / enhance the player's current skills,
The skill tree (abilities) that the player and the opponent have that might hinder or enhance damage received or done.
Any armor (shields in BL's case), that will also affect movement speed & attack time.
The particular class of enemy and player (as various classes or factions also carried their own damage perks).
The level of any weapons carried. (These could also be affected by any artifacts carried in the player's inventory).

Initially all this was calculated 'per hit', which really slowed the game down (you think about this being calculated upon each impact of each bullet).
In later testing builds, a lot of this was calculated at weapon equip time, (akin to a global variable), which meant only a few small calculations had to take place which dealt with the player and opponent variables. Things like weapon damage, elemental effects, artifacts in inventory, shields (armor) etc were all pre-calculated so that this was less 'expensive' on CPU time per impact.

Is any of that useful?

[overclockedmind]

Actually, yes, you've not changed until your equipment (excluding magic but that's just spell power / resistance which could also be done "at the equip phase") in a simpler sense. And anything that reduces the number of times you calculate a character's "everything" is going to make things quicker.

The stuff still has to be determined, but how many times and for what would be drastically reduced going this route.

I won't be doing "bullets," but this certainly reduces when at least half of those calculations need to be done.

Until someone equips a different weapon mid-battle... but again, reduced, not the entire bunch of calculation every time.

Thanks! Sort of shrinks down the when of "everything," which may be what I was originally thinking would be happening often enough that this strategy compartmentalizes certain bits, at certain times. Which may make my head spin quite a lot less.

[FourthWorld]

So, as I mentioned elsewhere, I am going to try and do a JRPG, in OpenXTalk...
...
Does anyone wanna lend a hand? If we have any D&D players about, or something similar, I'm betting this gets a lot clearer, a lot faster.

I've been studying TTRPGs and board games in general for the last several years. My preference for analog interactive media leaves gaping holes in my knowledge of things specific to computer games, but since most game design curricula start new designers working in cardboard to get mechanics and balance down before diving into the additional complexities of digital implementation, some of what I've been learning may be helpful.

If the question is just optimization of arithmetic, the discussion thus far about precalculating where practical is useful. But in early stages of any software I wouldn't worry so much about optimization as making sure the model does what you need. Computers are pretty fast with integer arithmetic, so an unoptimized system that's fun is a better investment than saving a few microseconds at the cost of balance or variety.

There's SO much out there for rules to inspire, a designer has vast resources for guidance. And while DnD and Pathfinder offer satisfying richness, there's an emerging interest in more-story-with-less-accounting, as with the popular Shadowdark.

One resource I've found especially useful is the Pathfinder 2e GM guide for encounter design, especially the part with tables to help design encounters that are challenging yet reasonably balanced:
https://2e.aonprd.com/Rules.aspx?ID=497

A couple years ago I started down the road of making a roguelike exploration game for the LC community. But sadly, with their audience size having plummeted when they dropped their FOSS edition and continuing in slower but evident decline since, I've set that aside to pursue other works which may have enough people using them to justify the effort (the roguelike had some interesting techniques worth sharing with devs, but without strong enough gameplay or graphics to bother attempting to compete in the crowded digital gaming space).

For now I'm very much focused on cardboard, and my RPG interest is mostly centered around studying those rulesets to find opportunities to adapt and simplify them to better meet the expectations of cooperative board game players.

So to wrap up this long-winded introduction, with 30 years of professional xTalk coding and six years of hobbyists board game study, I'm motivated to help and may be of assistance.

What is your specific question at the moment? Was it just about arithmetic optimization, or are you exploring options for mechanical design?

[OpenXTalkPaul]

I'd be willing to help with graphics, like making sprites, but I was never able to get into D&D type game play, I'm more of an arcade gaming person.

[overclockedmind]

Oh wow, imagine waking up to finding such response! My head doesn't exactly clear up the moment I awaken, but I'll be back with all of you shortly.

[overclockedmind]

So, as I mentioned elsewhere, I am going to try and do a JRPG, in OpenXTalk...
...
Does anyone wanna lend a hand? If we have any D&D players about, or something similar, I'm betting this gets a lot clearer, a lot faster.

I've been studying TTRPGs and board games in general for the last several years. My preference for analog interactive media leaves gaping holes in my knowledge of things specific to computer games, but since most game design curricula start new designers working in cardboard to get mechanics and balance down before diving into the additional complexities of digital implementation, some of what I've been learning may be helpful.

If the question is just optimization of arithmetic, the discussion thus far about precalculating where practical is useful. But in early stages of any software I wouldn't worry so much about optimization as making sure the model does what you need. Computers are pretty fast with integer arithmetic, so an unoptimized system that's fun is a better investment than saving a few microseconds at the cost of balance or variety.

There's SO much out there for rules to inspire, a designer has vast resources for guidance. And while DnD and Pathfinder offer satisfying richness, there's an emerging interest in more-story-with-less-accounting, as with the popular Shadowdark.

One resource I've found especially useful is the Pathfinder 2e GM guide for encounter design, especially the part with tables to help design encounters that are challenging yet reasonably balanced:
https://2e.aonprd.com/Rules.aspx?ID=497

A couple years ago I started down the road of making a roguelike exploration game for the LC community. But sadly, with their audience size having plummeted when they dropped their FOSS edition and continuing in slower but evident decline since, I've set that aside to pursue other works which may have enough people using them to justify the effort (the roguelike had some interesting techniques worth sharing with devs, but without strong enough gameplay or graphics to bother attempting to compete in the crowded digital gaming space).

For now I'm very much focused on cardboard, and my RPG interest is mostly centered around studying those rulesets to find opportunities to adapt and simplify them to better meet the expectations of cooperative board game players.

So to wrap up this long-winded introduction, with 30 years of professional xTalk coding and six years of hobbyists board game study, I'm motivated to help and may be of assistance.

What is your specific question at the moment? Was it just about arithmetic optimization, or are you exploring options for mechanical design?

Right, currently I'm looking at the factors that would matter, the sheer number of them, and stalling out. I kinda covered it with the "protagonist versus gnome" scenario, but we both know that I skipped/glossed over some things.

I mean really, I can just create a ruleset, throw it through the process, see what comes out, and adjust accordingly. In fact, that may well be what happens.

Edit: I'm finding the link you dropped quite fascinating, indeed.

[overclockedmind]

I'd be willing to help with graphics, like making sprites, but I was never able to get into D&D type game play, I'm more of an arcade gaming person.

Awesome. I have some "stock stuff" that I purchased for that, but then, if someone's used it "first," the second guy incurs wrath by fans of the first game because supposedly, Guy B lifted wholesale from Guy A. That's not what happened of course; both used the same assets, and in this case even purchased them for their use.

Perhaps thinking of this in a Legend of Zelda style kind of thing (I mean 80's Zelda, not now) would be an acceptable compromise.

And tbh, I don't plan on making any money on it. I *do* plan to credit OpenXTalk as much as can be, without being annoying.

[OpenXTalkPaul]

I'd be willing to help with graphics, like making sprites, but I was never able to get into D&D type game play, I'm more of an arcade gaming person.

Awesome. I have some "stock stuff" that I purchased for that, but then, if someone's used it "first," the second guy incurs wrath by fans of the first game because supposedly, Guy B lifted wholesale from Guy A. That's not what happened of course; both used the same assets, and in this case even purchased them for their use.

Perhaps thinking of this in a Legend of Zelda style kind of thing (I mean 80's Zelda, not now) would be an acceptable compromise.

And tbh, I don't plan on making any money on it. I *do* plan to credit OpenXTalk as much as can be, without being annoying.

Awesome, and the publicity would be much appreciated, I'd love to see lots of indy game dev being done with xTalk, that would be amazing. Certainly it's more than capable of being a game engine for a 2D 80s Zelda style RPG to be built on! Why hasn't anybody? It was the type of thing that HyperCard was used for quite a bit. (like the original Myst, but also bunches of lesser ones were built with HyperCard).

If I ever had lots of time I'd love to make a 2D Fighter framework built on xTalk, like Mugen or Beats of Rage (OpenBOR) engines, that users could easily swap out assets with, and then release it on GitHub and Itch.io so people can make there own fandom-fueled fighters. I've totally imagine a crazy unofficial 'Star Wars vs Star Trek vs Doctor Who Fighter'... BORG vs CYBERMEN, BEGIN! Sure there's open-source game engines like that but none built in xTalk script... (IIRC there were actually simple 2D fighters built with HyperCard).

[FourthWorld]

I'm looking at the factors that would matter, the sheer number of them, and stalling out.

Try stripping it down to the bare minimum, playtest with that, and if it feels boring add back one detail at a time until it feels interesting.

I've been using the board game Mice and Mystics as a test bed for more complex tactical options. I add in just a little Pathfinder- and wargame-inspired stuff as I go, looking for the optimal midpoint between too little dice-mitigating richness and too much cognitive load.

It's easier to add spice to a stew than to try to remove it.

[overclockedmind]

Thanks, guys, both of you:

Paul, you don't even know what you just started with OpenBOR + me.
And FW, the line about the stew... yep. So simple; not everything in the cupboard makes for a stew!

[tperry2x]

Certainly it's more than capable of being a game engine for a 2D 80s Zelda style RPG to be built on! Why hasn't anybody?

I think because of the varying rates of refresh when compared between platforms. There seems no way to set a reliable refresh rate of the stack / cards, so if you are locking the screen - making your change - then unlocking the screen between every 'frame' (for want of a better word), this is purely down to how fast the CPU can process it.

There's no 'frame skip' - so if you had 100 calculations to process - lets say we are moving two objects in iterations down the screen, while also changing size and colour, upon every screen unlock: this happens in the blink of an eye on an i9 processor. It takes an age on something like an intel celeron.

There's no way to reliably control this, so you can't have your game playing at light speed on someone else's computer, while on another machine, it runs like it's stuck in treacle.

That's one of the biggest hurdles to game creation in LC / OXT - parallel calculations which apply at the same timings regardless of platform and processor speed.

Also, this all has to be non-blocking ideally. However the CPU use climbs to over 20% even on a mid-range i5 processor, when simply moving a rectangle repeatedly while also changing colour. Even though (according to the user guides), stacks are read into memory first - at least the graphical side; the rendering of the stack / card by the IDE does not seem to be that efficient at all. I don't think it uses hardware support - seems to be all done in software rather than using any GPU that might be available.

[tperry2x]

Another hurdle is that key repeat rate comes into play when reading keypresses. These are delayed under MacOS by the system key repeat rate setting, so if this is set to a lower threshold for typing, this results in sluggish delays upon repeats (if a key is held down, as it is in lots of games).

If moving a sprite with the arrowkeys, the result is a jerky pause between key repeats as the sprite is moved.

The key repeat rate is ignored on Linux, and on Windows 7. In windows 10, it mirrors the MacOS behaviour. This means that key repeats can be erratic between platforms, and can result in the wrong 'feel' and frustrating user input.

If would be better to be able to use a hid Input class, such as like you might read back from a joystick input, rather than attempting to read keypresses, but then you also come back to the timing issue in my above post where the sampling of these inputs will vary greatly between platform and processor.

(yeah, I don't have solutions to this - sorry).

Moreover, imagine multiple sprites added to a card - to get them all updating between each screen unlock, you have to iterate through a list. You could do this in multiple ways, using an array / simple list / or a global variable.

You could have a variable with the names of each object, and dispatch / send a message to update the frame to the next frame for each sprite object, but when you have 10+ or so of these, you'll start to see a noticeable slowdown.

It reminds me of what used to happen on the Megadrive / Genesis - if there were multiple sprites on screen at any one time, it just couldn't handle it and begins to get 'laggy'

This is partly why I wish someone would write an xTalk language plugin for the likes of Godot, as the Godot engine has all the 3D and GPU support that the LC / OXT engine doesn't.

[richmond62]

You can 'fake' 3D quite easily in xTalk (LC/OXT), but what you cannot do is get the thing to move at any appreciable speed.

[overclockedmind]

These are good answers, too, even though they are "what won't work." I might as well know ahead of time what is going to cause me issues intrinsic or not... keep it coming, guys.

[overclockedmind]

Another hurdle is that key repeat rate comes into play when reading keypresses. These are delayed under MacOS by the system key repeat rate setting, so if this is set to a lower threshold for typing, this results in sluggish delays upon repeats (if a key is held down, as it is in lots of games).

If moving a sprite with the arrowkeys, the result is a jerky pause between key repeats as the sprite is moved.

The key repeat rate is ignored on Linux, and on Windows 7. In windows 10, it mirrors the MacOS behaviour. This means that key repeats can be erratic between platforms, and can result in the wrong 'feel' and frustrating user input.

If would be better to be able to use a hid Input class, such as like you might read back from a joystick input, rather than attempting to read keypresses, but then you also come back to the timing issue in my above post where the sampling of these inputs will vary greatly between platform and processor.

(yeah, I don't have solutions to this - sorry).

Moreover, imagine multiple sprites added to a card - to get them all updating between each screen unlock, you have to iterate through a list. You could do this in multiple ways, using an array / simple list / or a global variable.

You could have a variable with the names of each object, and dispatch / send a message to update the frame to the next frame for each sprite object, but when you have 10+ or so of these, you'll start to see a noticeable slowdown.

It reminds me of what used to happen on the Megadrive / Genesis - if there were multiple sprites on screen at any one time, it just couldn't handle it and begins to get 'laggy'

This is partly why I wish someone would write an xTalk language plugin for the likes of Godot, as the Godot engine has all the 3D and GPU support that the LC / OXT engine doesn't.

Don't think the NES was immune to this, either... games earlier on slowed down like that because they had not yet learned how to program the NES "tightly," and later games did it too because they were pushing the hardware "too far." If they made it survivable, it was sort of like free slow-mo for the gamer, and could be taken advantage of. The problem is, when is the NES going to "shake it off?" I remember using this as a kid, but it had one drawback... you ALSO had to know that moment when the NES was going to recover and start running at full speed, or you went from that slowdown effect to, hey it's all good again without you knowing when to expect it, and how to react; otherwise in an intense game, you were essentially dead.

[OpenXTalkPaul]

Another hurdle is that key repeat rate comes into play when reading keypresses. These are delayed under MacOS by the system key repeat rate setting, so if this is set to a lower threshold for typing, this results in sluggish delays upon repeats (if a key is held down, as it is in lots of games).

If moving a sprite with the arrowkeys, the result is a jerky pause between key repeats as the sprite is moved.

The key repeat rate is ignored on Linux, and on Windows 7. In windows 10, it mirrors the MacOS behaviour. This means that key repeats can be erratic between platforms, and can result in the wrong 'feel' and frustrating user input.

If would be better to be able to use a hid Input class, such as like you might read back from a joystick input, rather than attempting to read keypresses, but then you also come back to the timing issue in my above post where the sampling of these inputs will vary greatly between platform and processor.

(yeah, I don't have solutions to this - sorry).

I know exactly what you mean. The way I would try to do things like this is to create my own check loop using something like 'send "checkKeys" to me in gUpdateInterval milliseconds', at specific intervals that handler checks 'the keysDown' engine property for a list of currently pressed keys and then takes appropriate actions based on that, this way the keyRepeat rate never comes into the picture, and you can recognize 'chords' (like "Up' AND "Left" arrow keys at the same time for a diagonal direction). Then you do the expensive screen updates in between those gUpdateInterval milliseconds, the gUpdateInterval variable can then be adjusted to be appropriate for the Platform/CPU it's running on until there's no lag (but maybe not so good 'frame rate'). The same technique can be used with that cross-platform HIDAPI, an Extension wrapper I wrote a few years back (which uses the same library in 'PyGame'), to check for HID Gampad input instead of (or in combination with) keyBoard input. When stopping your update loop, you'll want to clear waiting messages and use flushEvents(all) otherwise it will keep processing the waiting events.

It reminds me of what used to happen on the Megadrive / Genesis - if there were multiple sprites on screen at any one time, it just couldn't handle it and begins to get 'laggy'

I also know what you mean as far as then Engine getting very laggy after moving bunches of sprites around on a card for a few minutes. I vaguely remember seeing that in a few SEGA 16bit games (like Robot Wreckage).
There are strategies that might make big performance differences. Most people nowadays have magnitudes of more ram in their computers (or even in their Phones) than whatever memory Sega MD/Genesis had, plenty enough that we can load imagedata 'frames' into a 'Sprite' Array and apply that data very quickly to an Image control. I did some tests using the drawing library's 'compiled ImageData' to Draw 52 full color SVG files (SVG deck of playing cards), and it renders so fast that I had to put in a delay in to see anything more then a sort of motion-blur, and that was like a 2Ghz Core 2 Duo.

This is partly why I wish someone would write an xTalk language plugin for the likes of Godot, as the Godot engine has all the 3D and GPU support that the LC / OXT engine doesn't.

Yeah that would be a lot of foreign function bindings to write, but it could be doable, and it would be super sweet to have a real GPU accelerated game engine that is xTalk scriptable. It might already be possible to use the web version of Godot in a BrowserWidget or Emscripten Engine or some other xTalk + JavaScript polyglot scriptiing.

Have you tried playing around with accleratedRendering and related settings like compositeTileSize? Looking at the docs it appears set the acceleratedRendering only uses CPU rendering on Linux/Windows but it can use OpenGL rendering on others (MacOS/iOS/Android). The IDE comes with two rendering engines actually, libCairo (https://en.wikipedia.org/wiki/Cairo_(graphics) that renders our cards/stacks/controls/etc., and libSkia (https://skia.org) which renders Widget canvas stuff. I believe both of those libraries can use GPU acceleration. Skia is much newer and seems to do things like rounded corners and anti-aliasing smoothing better than the older libCairo.

As I understand it, the engine uses two threads, one for scripts/execution an one for rendering. Lots of locking screen/unlocking screen can actually hurt sometimes. I've had smother animations by taking out the lock screens sometimes.
Another thing you might try if you have lots of image/graphics transformations going on in between each screen update might be t do all of your transformations ahead of time and then store the transformed versions in memory ready to paint on screen, you could store as Imagedata or SVG paths in a global Array.

[OpenXTalkPaul]

Interesting thread that may even apply to our thing:
https://news.ycombinator.com/item?id=16539446

[xAction]

Get an open source rule set and then you have a tested system to program, and a recipe of properties that you need.

Find the essential fun properties and pit them against each other

Make up some leveled lists of property modifiers like potions, jewlery, armor , weapons that inflate or deflate numbers,

Spend hours making menu choices and/or button clicks and/or answering multiple choice questions to make numbers change and objects on either side of the screen be visible, discolored, or whatever.

It boils down to having fun with the numbers, form follows function.

Once the numbers game works, insert graphics, animate one frame of every animated thing each turn of the game loop.

Never ever use key repeat rate for anything. It's terrible. The worst! It means you can't be lazy if other people are expected to use the software, you have to write traps for the keys and tightly control what can happen. While testing, sure, slack a bit with the scripting, seeing the IDE freak out is 1% of the fun.

You have to have a game loop that fires at a constant rate and then check the lastKey pressed (or whatever custom property/global you want to use) before updating whatever a key might modify. Every game is basically turn based but some games run turns extremely fast without pause. I'm about to rework my action game example to illustrate the game loop, or game controller as it's sometimes called.

Test the rendering engine speed, get a tile set, make a script to produce a grid of images...and inside the game loop offset it by some amount (the walking directions). How big can you get it before it becomes un manageable? What tricks make that faster?

A bridge between xTalk and the infinite game engines/frameworks is long overdo. I think the first step is defining what we can do in the IDE and language, then taking that to the all power all knowing AI and saying "Make X be more Y", from there we own the universe.

[overclockedmind]

I'm taking notes over here... LOL, or at least I would be, if the forum wasn't doing it for me.

(I'll be archiving this thread either way later on. Too much good info to be lost.)