Action RPG Framework

by Forum_account
Action RPG Framework
A framework for developing action RPGs.

This version adds the /Quest datum and the on-screen quest tracker. There are procs to manage the quest-related input with an NPC, you just have to call this:


And the library will automatically check if the player has the quest, check their status on the quest, and take the appropriate action. If the player doesn't have the quest, the NPC will offer it to them. If the player has the quest but it isn't completed, it'll show a specified message (specified by your /Quest datum). If the quest is complete it'll complete the quest and show a specified message. If the player has already completed the quest it'll show a different specified message.

The actions that must be taken to complete a quest are totally up to you. Maybe the player has to kill a really tough enemy. Maybe they have to find a hidden tomb. Maybe they have to collect some items.

Overlay Generation

I added the icon-generation folder which has some code to generate overlays for the player icon that comes with the library. You can easily change what color or pattern is applied to armor and generate extra overlays.

Condition Saving

Any condition applied to the player is saved when they log out. If you're poisoned (taking 4 damage each second) and it has ticked once when you log out, it'll tick three more times when you log in again and begin to play that character. Cooldowns still aren't saved but you can use Conditions to create things that behave like cooldowns.

Music & Game Menu

I added the proc and used it to play music in the sample game. I also added the game options menu under the game menu. This menu contains screen size, sound volume, and music volume options.

Here's the full list of changes:
  • Fixed the alignment of item captions in the loot window when the item name wrapped to a second line. Also increased the width of the loot window by a tile to make it less likely that item names will wrap.
  • Condition objects are now saved and loaded. Their durations are only being checked and diminished when the character owning them is active. If you give the player a condition that lasts for 10 minutes, it'll only expire after 10 minutes of playing time on that character.
  • Updated the combat object in the sample game to not check for critical hits when the attacker is null.
  • Added client options for screen size, sound volume, and music volume. These values are also stored in the client's savefile.
  • Added the interface to set the client options in the "Game Options" menu.
  • Made the escape key only open the game menu if it didn't perform any other action (ex: untargeting the mob you're currently targeting).
  • Set the anchor property of the chat input control so the window resizes properly now.
  • Added the icon-generation folder which contains code and icons used to generate overlays. This lets you easily generate new armor or helmet overlays with different colors or patterns.
  • Added the proc which is used to play music to the player. The songs are automatically updated when the client's volume setting is changed.
  • Added music to the sample game.
  • Added the "slowed" condition to the sample game. The blue oozes attacks slow your movement speed by 50% for one second.
  • Added the base_speed var to the sample game. This is a value that doesn't change so even if you modify the player's move_speed var, you always know what their base movement speed was.
  • Shifted the condition icons up and over 8 pixels so they're in the center of their icon states now. The ConditionsBar HUD element was shifted down and left 8 pixels so the icons still appear in the same position on the screen.
  • Fixed a bug with the Condition.stack_size var. Previously it'd allow one more condition than you had told it to allow.
  • Replaced the mob.saved_loc var with the mob.saved_x/y/z vars. Saving a reference to your turf could cause unwanted things to be saved. Instead we use the saved coordinates to get a reference to your saved loc at runtime.
  • Added the Quest datum and the mob procs to manage accepting quests, updating the progress on quests, abandoning them, and completing them.
  • The Quest datum automatically has procs that are called when you kill an enemy, get an item, lose an item, or get killed. This makes it easy to capture these events to update the quest's status accordingly.
  • Added the mob.quest_dialog() proc which takes a /Quest type and displays the appropriate prompts given the player's current progress on that quest. The second argument is the dialog type, which can be QUEST_START, QUEST_END, or QUEST_START | QUEST_END. This lets you make NPCs act as only the quest's starting point, only the end point, or both.
  • Added two quests to the sample game. See demo\npcs,dm for more details.
  • Added the on-screen quest tracker which shows the name of each quest and its status.
  • Pressing the Q key will set focus to the quest tracker. The player can use the arrow keys to select a quest and press the delete key to abandon a quest (there is a confirmation prompt before it's abandoned).
  • Made the mob.prompt() proc create a dialog with no buttons if you pass null as a button name. Omitting all button names makes it default to having just an "Ok" button, but calling prompt("text...", null) makes it not show any buttons.
  • Added support for specifying a width and height for prompt windows. The first parameter to prompt() is still the message. Any parameter after the first that's a number is assumed to be the width or height of the window. For example, prompt("", "Ok", "Cancel", 4, 4) makes a 4x4 prompt. The default size is 6x4.
  • Added the global Options object. This is like the Constants object except it contains values that aren't needed at compile-time. This makes it easier to change options in your project because you can simply do: Options/space_opens_inventory = 0 to change that option and it overrides the value specified in the library.
  • Added the "space_opens_inventory" option to the Options object. This is used to determine if the space bar should open the inventory screen when there's nothing else for you to interact with (it's 1 by default).
  • Changed the mob.wander() proc to check for some conditions that would cause infinite loops.
  • Added shadows below mobs in the sample game.
  • Removed the "Chat Menu" button from the interface. It'll be accessed through the game menu (the one that appears when you press escape) though it's still not implemented yet.
I don't have too many ideas for the next version. I'd like to change how the health and mana meters look and offer an option to have numeric health/mana displays too. There are some improvements to quests that I can make too. Other than that, I'm almost completely out of ideas.

What I'll most likely work on next is a more complete game that's made using this library. That should show off what you can make with the library and help me realize where it can be improved.
well, i have some ideas. how about the ability to trade with players. a bank to deposit items into. improved crafting. more skills. player vs player. mob health and mana meter.
Perhaps a title system. Like you receive a title every time you complete a medal. These would be shown under your name as a nifty little object or above you.
You could add in a bounty system, or something along those lines for when players kill other players too much or too quickly. I don't think this has anything like that. I can't suggest much yet, because I haven't had the chance to really look over everything.

I mention that, though, because even though it's a bit simple it may be a good idea to have it in so more people think about it. Seems most games forget to consider that, and new players get rather... Miss-treated, to say the least. The ability to toggle PvP on and off is another simple thing that can be added toward PvP, and things like that may be what Kalster had in mind.

I suspect a lot of games using this will have PvP, so this could be worth it. Ultimately up to you. This is already awesome as is.
another nice addition would be to only use the arrow ability when the usr has arrows in inventory
In response to Icicard
The library handles most of the features that can be done in a standard or generic way. A lot of the remaining features start to get pretty game-specific. If there's a feature that people might want to work in wildly different ways, it's hard to add it to the library in a way that's useful to people. I want the library to cover a lot of topics but it'll never cover 100% of what's in a game. I'm trying to implement the half of the game that's generic so people only have to implement the half that makes their game unique.

Icicard wrote:
Perhaps a title system. Like you receive a title every time you complete a medal. These would be shown under your name as a nifty little object or above you.

I'm not sure if I'd add titles. People can easily add that themselves. I could add support for medals. That way people don't have to worry about the graphical display of how medals. For example, you'd have to do something like this:

kills = 0
list/titles += list


kills += 1
if(kills >= 10)

name = "Killed Ten Mobs"
description = "You killed ten mobs!"
icon_state = "killed-ten-mobs"

m.titles += "_ the Mob Killer"

The framework handles talking to the hub and awarding the medal. You just have to write the code that detects when the medal should be awarded and what happens when they get it. The generic stuff (ex: showing a graphical indication of receiving the medal) is handled for you.

Kalster wrote:
well, i have some ideas. how about the ability to trade with players. a bank to deposit items into. improved crafting. more skills. player vs player. mob health and mana meter.

I'm still not sure how I want trading to work. I'm not sure if I want to get into that. The slightest bug with trading could cause some pretty big problems in your game. I'm sure I'll get to it eventually, just not yet.

I would like to add a bank that's shared across character accounts. Being able to save a shared bank is more difficult and isn't something people could easily add themselves.

another nice addition would be to only use the arrow ability when the usr has arrows in inventory

I'm pretty sure all of the procs exist to easily handle that. I tend to not like games that would require you to have arrows but it's certainly worth showing how you can create an ability that requires an item.

Toddab503 wrote:
You could add in a bounty system, or something along those lines for when players kill other players too much or too quickly.

I'd like to leave PVP entirely up to the game that uses the framework. I could add the ability to enable/disable/toggle PVP since that might require some on-screen indicator and some knowledge of how the library works. The specifics of how you want PVP to work would be up to the game.

The framework has procs that it calls "events". They're just procs that are called when something happens. Many of them don't do anything by default, they just exist so you can override them to make additional things happen when an event occurs. You could use this to check if someone is killing a particular player too much:

bounty = 0
list/player_kills = list()


// keep count of how many times you kill each player
player_kills[m] += 1

// if you've killed them too much, increase the bounty on your head
if(player_kills[m] > 5)
bounty += 100

I mentioned this idea in another post but it's worth mentioning again: The great thing about this framework is that lets people easily share code. For example, if you created a demo in DM that showed how to create crafting skills or PVP bounties, it wouldn't work in most games. People would have to make an effort, sometimes quite a large effort, to make their game work with the demo. It's a nice demo for educational purposes but not for practical purposes. However, if you made a demo that showed how to create those things using the Action RPG Framework, it would easily integrate with any project that also uses the framework since everyone's using the same underlying representation of items, enemies, abilities, cooldowns, etc.
Forum_account, i know that you don't want to include the player vs player in the framework but you were also saying that next update might be a game demo update. in that case, how about a player vs player or metal example in the game demo for us
I can add it to the sample game but there won't be much to it. I'd just give mobs a "pvp" var and override the can_attack() proc to let players attack each other if their pvp flags are enabled. There's a whole lot of other stuff that could go along with PVP (scoreboards, battlegrounds, penalties for killing the same person over and over, etc.) that'll be up to each game to add.
how u override the can_attack() proc
In response to Youngplaier
Youngplaier wrote:
how u override the can_attack() proc

You'd do something like this:

pvp = 0

if(pvp && m.pvp)
return 1

return ..()

You override the can_attack() proc to add new rules to it, then call ..() to enforce all other rules.

Version 8 of the framework will include a pvp var so you don't have to worry about this too much. The new version will probably be posted tomorrow.
ok cool thanks one more question i cant seem to work the huds im tryna find out where there title screen code so i can ad my screen name and background
In the next version I'll add some options to make the title screen more easily customized.