itch.io

Type systems should definitely be possible! It should be pretty simple conditional logic; just make a function like "If attack is Type X, check if defender is a relevant type and apply multipliers." I can even do a mockup for you if you like. (I've actually been considering making a proof-of-concept monster collector for a future Experiment.)

Level up mechanics are definitely doable, even though I didn't make any explicit systems for them; A Friendly Irin made a game that used them and released the source code, so you can check that out.

Oops! No, sorry, I forgot about the GitHub. I was having some trouble updating it, but I can do that shortly.

I'd like to take you up on your offer for testing if you're still available! I have a new microgame I'd like to test. Itch doesn't have a private messaging feature, but you can message me on Discord or Reddit under the same username.

Oh, that's actually due to an update to SugarCube. Since it's only a console warning, I haven't considered it a high priority to fix.

I was going to put this in the planned features thread, but I felt it deserved its own post. Would people like to have a human-readable graphic user interface for this engine, similar to what you would find in RPG Maker programs? As an example, instead of having to write your own JavaScript code, you could construct an action/item/other object by filling out text fields or checkboxes for every attribute, and the program would automatically translate it into the correct JS code block.

If there's interest in this, please direct me towards resources for how this could be made, because it's currently a bit above my experience level.

A while back, I released Another RPG Engine, an engine for making jRPG-style games using Twine. I was initially satisfied with what I had released, but recently, an idea for a very specific enemy type began to nag at me: one that couldn't directly attack. I started thinking of ways that such an enemy could still be challenging, and came up with this experiment.

This is as a small, self-contained RPG with only a single battle, so it shouldn't take much time to play. Try it out and tell me what you think.

Link: https://anotherrpgenthusiast.itch.io/another-rpg-experiment-01

One of the wounding messages for enemies says "It's wounds are deep" -- that should be "its". There is also a typo of "ressources" during some spoil scenes.

This looks very professional, but is very simple as a game. Without visuals or other personality to the areas and enemies, there's not much incentive to keep exploring. I'm also not entirely sure how the combat works -- sometimes I'll get hit multiple times in a row even when I choose to fight. If there's some sort of miss mechanic, you should make sure to provide a message for that.

I like that you give the player feedback on how badly wounded the enemy is without explicitly showing HP. A big problem in a lot of these games is that I have no idea how strong the enemy is and whether I should retreat if the enemy's strength is totally opaque, but telling the player everything can make it too easy.

I've made a similar engine in Twine myself if you'd like to compare notes, though it's a pretty different focus (jRPG based instead of roguelike).

Would you be willing to share your source code for this engine?

Yes, that's due to the nature of Twine. Don't refresh during battles.

Open question, as of version 0.61:

I'm having trouble balancing Forsaken with Archer's Shot.

Currently, when used by an unbuffed Mage against an average (30 SPC) enemy, Forsaken inflicts 30 points of Defense reduction, or 30 extra points of damage per hit for 5 rounds. This isn't actually much better than Rogue's Below the Belt, which currently inflicts 23 points of Defense reduction against the same, and it has to compete with Indignant Variati, which costs the same. Against an average (30 DEF) enemy, Indignant Variati inflicts an immediate 330 damage; you would have to make over 11 attacks in 5 rounds to make Forsaken the superior option.

Normally I would just make it stronger, buuut things get screwy with Archer's Shot. At its upper bound it hits 10 times, meaning every point of Defense reduction equals 10 extra points of damage. Against an enemy with 0 Defense (the result of using Forsaken on an average enemy) it inflicts 585 damage (!) even without Attack buffs. And this is without even getting into using Special buffs, or stacking Defense debuffs with Forsaken to reach negative Defense. Against an average enemy, Witch's Forsaken inflicts 45 points of Defense reduction, which translates to -15 Defense, which translates to 735 damage (one-shot kill territory!!) with a 10-point Shot.

In effect, this makes Forsaken pretty much useless unless you stack it with other debuffs or use the upper bounds of Archer's Shot, which makes it extremely situational compared to Indignant Variati or Perdition, which require far less setup to accomplish similar results.

I can't fix this by reducing the weight on Shot, because the core problem is the massive variance resulting from Defense changes, which is inherent to the multiple hits. If I balance Forsaken for regular attacks, Shot's potential becomes gamebreaking; if I balance Forsaken for Shot, Forsaken becomes useless with regular attacks.

I figure I've just designed myself into a corner and I have to accept that; creating a 10-hit attack was always a risky idea that I knew was going to run up against the limits of the battle system. I mean, maybe this is okay? It's not like it's easy to get Archer up to 10 points; maybe it's alright to let players break the game if they're clever and determined enough to pull off this combo?

This thread is a listing of planned and requested features. I am still a novice with JavaScript, so I do not necessarily know how to implement these yet. Please weigh in if you have an idea. You may also request additional features you'd like to see here.

Planned Features

• Stat grinding functionality
• Crafting system/equipment customization

Completed Features

• Using replace macros to transition through battle phases instead of moving to new passages. This should speed up battles considerably. DONE in 0.99
• Making the BACK button only go back one level instead of all the way to the main battle screen. So far I have been nervous about messing things up by using the actual back macros. Certain sections (such as the spell check) advance multiple passages at once, so the back macro would not work.
  • While not done exactly, the "last action" functionality added in 1.06.1 mitigates this.
• The ability to play with keystrokes, like a console game. DONE in 1.06
  • Still needed: Targeting hotkeys for all-targeting skills. DONE IN 1.06.1
• The ability to change background and tags of the battle passage DONE in 1.02
• Threat/aggro system DONE in 1.13
• Audio and music functionality DONE in 1.06.4
• Expanded menu functionality, plus hotkey support DONE in 1.07
• The ability to have redundant equipment slots, e.g. the ability to equip two "Accessories" at once. DONE in 1.08.1
• Loss-of-control effects (e.g. berserk and confusion) DONE in 1.14
• Item drops DONE in 1.13.1
• Cooldown for player actions DONE in 1.14
• A more compact action list, with details offloaded to an info box that pops up on mouseover. DONE in 1.15
• "Turn exchange" that forces an enemy action for every player action in the free-action system. DONE in 1.15
• Ability to set the default action for puppets. DONE in 1.15
• Ability to modify the appearance of save files. DONE in 1.15
  
• Accessibility options such as changing font and text color DONE in 1.19
  
• Reactive stat masking, e.g. only displaying elemental affinities after using that element DONE IN 1.21
• More active visuals, with animations, dynamic health bars, etc. DONE in 1.25
  
• Notifications for actions and items used in the menu DONE in 3.02

As of version 3.03

Major

• Refreshing during battles will destroy health bars and create several issues with the JavaScript. This is due to the nature of Twine and cannot be fixed. Just try not to refresh during battles. Fixed in 1.26.1, amazingly. Refreshing in general is still not recommended.
• The Inventory class does not revive correctly on a save load. Fixed in 0.99
• <<deathcheck>> causes an error when trying to remove some effects. I suspect the issue is Protector; will investigate. Appears to be fixed as of 1.25
• Equipment will produce strange effects if the onEquip and onRemove functions are changed between save game versions. Fixed in 1.08
• Top-of-round code will run additional times if an enemy uses an instant action as their first action. Fixed in 1.26

Cosmetic

• When an applied effect has its duration extended, a blank line is generated. Fixed in 1.10.3
• A line break isn't generated for the death message when an enemy is defeated by DoT. Not sure if this was ever fixed, but now irrelevant with the DoT UI revamp
• Effects with blank removal messages still force the player to click through the end-of-round passage. Fixed in 1.08.5
• Party sizes greater than 3 create weird effects with the command display. Fixed in 1.09
• The unequip button only travels to the edge of the equipment description box, not the larger actor box as it should. This is due to some HTML finnickyness I dread interfering with. Fixed in 1.07
• Actions with long descriptions will run off the page when actions are compressed, making them unreadable. A better popup method is needed. Fixed in 1.25
• Shake animations sometimes don't trigger when the action affects both an enemy and a puppet.
• Characters appear dead before the killing blow is struck during animations. Fixed in 2.03
• Action/item use notifications visibly switch back to the default styling before fadeout.
• The battle grid "flickers" as it's being updated when moving characters around.

Minor

• The enemy action loop doesn't quite work as intended; if there's an else clause (as there should be), the probabilities are thrown off because a failed action will automatically be changed to the default. Is this really a problem though...? Maybe it's best if it does work that way.