Welcome, Guest
You have to register before you can post on our site.



Search Forums

(Advanced Search)

Forum Statistics
» Members: 103
» Latest member: aqasud
» Forum threads: 8
» Forum posts: 9

Full Statistics

Online Users
There are currently 2 online users.
» 0 Member(s) | 2 Guest(s)

Latest Threads
Navigation and Questing
Forum: Development Notes
Last Post: Aesthemic
11-16-2017, 03:08 AM
» Replies: 0
» Views: 77
Experience and Leveling
Forum: Development Notes
Last Post: Aesthemic
11-10-2017, 03:16 PM
» Replies: 0
» Views: 47
Thoughts on Damage Formul...
Forum: Development Notes
Last Post: Aesthemic
11-10-2017, 03:09 PM
» Replies: 1
» Views: 73
Repair Functions
Forum: Development Notes
Last Post: Aesthemic
11-09-2017, 08:57 PM
» Replies: 0
» Views: 42
Existing Issues
Forum: Bug Reports
Last Post: Aesthemic
11-09-2017, 07:24 PM
» Replies: 0
» Views: 73
Thoughts on Turn Order Sy...
Forum: Development Notes
Last Post: Aesthemic
11-08-2017, 08:27 PM
» Replies: 0
» Views: 45
Basic Command Guide
Forum: User Guides
Last Post: Aesthemic
11-08-2017, 06:15 PM
» Replies: 0
» Views: 59
Forum Launch
Forum: Announcements
Last Post: Aesthemic
11-08-2017, 05:07 PM
» Replies: 0
» Views: 92

  Navigation and Questing
Posted by: Aesthemic - 11-16-2017, 03:08 AM - Forum: Development Notes - No Replies

One of the most important aspects of the bot will be implementing a location and questing system. Unlike previous projects, the idea is for the player to travel through a world as they make progress in the game. The available quests and the types of enemies available when exploring is based on the area where the player is located.

Quests will be flag-based, meaning that accepting a quest will trigger a flag that will indicate that you're in that quest. The flag can change over time as progress is made, ultimately setting a final value when the quest is complete after rewards have been provided to the player.

From a technical standpoint, the idea is to define the location the player is in, where they are able to go to from the location they are in, and what the requirements are for each area as well as information about whether that area is a town, a special quest area, or if they are in an explorable area.

Locations and Quests, while technically being separate systems, are tied together as accepting a quest and turning it in must be done at a specific location.

I'm still working on how the code will be written and the formatting for this information. The concept is to have different stores, NPCs, and other things to do at each location and for players to have to explore the world to be able to find different equipment and other things for sale, though there is of course acquiring items and progression from random drops as well.

Each location will have a location file which contains all of the information about what is available at that location. This will also keep track of locations around them and the requirements to travel to the location indicated by the location file. For example, a certain area might require a level of 10 to be able to reach or require the completion of a total of three quests to be able to reach it.

Print this item

  Experience and Leveling
Posted by: Aesthemic - 11-10-2017, 03:16 PM - Forum: Development Notes - No Replies

Previously I have relied on a formula to determine the amount of experience to reach a specific level. This time around, I have hard set the experience required to reach a specific level to prevent some of the same issues I had before with how experience was being handled. Provided below is a glimpse at the values for reference; in-game players will be able to see how much experience they have and how much experience they need to reach the next level. It will entirely be possible to level multiple times from one battle, especially early on, but that would require you to defeat an enemy that is tougher than you're meant to be facing at your level which can happen.

Link to Spreadsheet: https://docs.google.com/spreadsheets/d/1...sp=sharing

I determined the experience curve based on how I am planning on determining experience gained from an encounter and trying to figure out how many encounters on average I wanted someone to win for them to reach the next level. There was also a conscious effort to prevent the experience totals from getting too crazy. Even at higher levels, experience gains aren't going to be crazy high.

Maximum level is currently planned to be 255 to allow people to continually improve their character, though it will become more time consuming to level a character on each subsequent level, therefore it is quite likely most players will never max out their character's level. The idea is to appeal to players that want to eventually become an incredibly powerful character; I think the hardest content will be designed with characters around level 120.

Print this item

  Repair Functions
Posted by: Aesthemic - 11-09-2017, 08:57 PM - Forum: Development Notes - No Replies

Upon thinking about how to handle certain processes, there are some cases where a power outage or a disconnection could cause a complication with how the game works. As a result, I am going to develop repair functions which can repair all participants in a specific battle or all characters in the game. This would reset them to a state where they are in town and are not engaged in any activity.

During the development process this will be crucial since a lot of information is temporarily stored in files to control combat and other aspects of the game. If the game were to crash, certain timers would be stopped and not restarted when the bot is launched again. As a result, this could cause issues with trying to resume gameplay requiring manual editing of files unless there is a repair function.

Any time the bot is started, it will run a full repair function which resets all player characters to a default state while wiping all temporary NPC information. This means if the bot is shut down in the middle of a fight, that fight is essentially negated.

Once we near a "complete" launch of the game, I will look into some form of resuming fights if the bot crashes, if the connection between the bot and server is lost, or if there is some sort of other issue.

I'll use this page as personal notes on what I need to take into consideration for repair functions so I don't forget anything. This could even include deleting entire files since the bot can recreate the files if needed.

Potentially required files
timers.data - Tracks all currently running timers. If the bot disconnects from the server, it will unset all of these timers.
battles.data - Tracks all ongoing battles. If the bot disconnects from the server, it will reset all of the characters in these battles to default status and then remove all of the temporary NPC data.
longtimers.data - There will be some processes that take a while to complete such as blacksmithing. I would hate to punish players over the bot becoming disconnected, therefore this file would make sure all of these timers are documented and then resumed when the bot reconnects. If there is a crash, I will make an effort to restore them as much as possible. Not sure the best way to approach this since I don't think there are many long timers.

Print this item

  Thoughts on Damage Formula
Posted by: Aesthemic - 11-09-2017, 08:30 PM - Forum: Development Notes - Replies (1)

In order to make the game interesting I will be using some formulas to determine damage calculation for all types of damage. Without outside interference, the most amount of damage which can be mitigated from an attack is 75%, meaning that an attack should always do damage as long as it hits, unless there are other factors which influence the damage.

For physical damage, a few different elements are used in order to determine how much damage someone takes when they are hit. The attacking character has both an "Attack" value and a "Damage" value for their attack which are based on different factors.

Attack: Weapon Attack + Dexterity + Distance Bonus / Penalty

Damage: Weapon Damage + Strength + Weapon Stat

Every weapon in the game has an attack stat and a damage stat. They also have a damage type, which will be a stat. Different weapons have a different stat which they are influenced by for damage.

Here are three different weapons to use as examples:

Long Sword - Weapon Attack: 15 - Weapon Damage: 12 - Damage Type: Strength
Short Sword - Weapon Attack: 10 - Weapon Damage: 12 - Damage Type: Dexterity
Knife - Weapon Attack: 10 - Weapon Damage: 8 - Damage Type: Agility

Attack is used to determine how much of the damage bypasses your opponent's armor. This is done proportional to your opponent's defense as well as any temporary bonuses they may be receiving. At no defense, the damage will be dealt entirely while having defense equal to or higher than the attack stat will mitigate 75% of the damage being dealt. This is proportionate. If the target's defense is half the attacker's attack stat, they will mitigate 37.5% of the damage.

Ranged weapons differ slightly in that they generally do less damage, but do not suffer a distance penalty.

The distance penalty is based on the row the attacker is in and the row the defender is in. If both are in the front row in combat, then there is a bonus of 15%. If either of them are in the back row. there is no bonus. If both are in the back row, then there is a 15% penalty. This means front-row fighters do more damage, but they also take more damage. Ranged weapons are not subject to this, as neither is magical attacks that are not physical in nature.

Weapons can deal multiple types of damage if they are enchanted, or if the user has used a skill or spell that gives them elemental damage. Elemental damage that is physical in nature is subject to those penalties when taking into consideration damage from resistance.

Magical spells and ranged weapons are always assumed to do the same damage regardless of distance.

Elemental damage is subject to the same mitigation limit: 75%. It uses the same formula, replacing defense with resistance for that element.

In essence, attacks should always do damage unless they miss, or there is a special ability being used to increase the mitigation limit such as a rare armor that increases the limit or an ability to makes the target immune to a certain type of damage.

Print this item

  Existing Issues
Posted by: Aesthemic - 11-09-2017, 07:24 PM - Forum: Bug Reports - No Replies

Development Issues

None right now

Textual Issues

None right now.

Upcoming Features

Turn Features On and Off

I need to work on the controls for turning the bot on and off in case the bot ever needs to be disabled for maintenance purposes. This would allow for a mod or admin to stop the bot temporarily, and then resume it once the issues has been resolved without having to take the entire thing offline. The idea would also be able to disable specific features while still having other things work. For example, if there was an issue with a specific question, you would be able to disable that quest until the issue is resolved.

Help Menu

The plan is to have an in-game simplified help menu with links out to resources on the forums. Players would be able to view a menu of options and get basic instructions with a link to the forums for more advanced help.

Random Item Stat Generation

Currently working on a method to store individual stats for individual items that have the ability to have randomly-rolled stats. This will be applied to most weapons and armor in the game while consumables will generally be static. There may also be specific types of weapons and armor that have specific stats that cannot be changed. Will need a way to properly document and enable players to select which particular item they are referencing when equipping, removing, storing, or withdrawing an item as well as when performing a trade.

The idea is to give each item a unique ID, based on a flag set on the item. If the item is a unique item, i.e. the stats are entirely static, then it will have a flag and a specific ID to that item. However, if an item can have different stats, it will be flagged differently and will have a different pool of IDs. When the game generates an item, it will also have to know what flag the item has. As a result, item names will be entirely unique, but the IDs will be used when that specific flag is used so it can differentiate which version of that item you're referencing with those specific stats.

Randomly dropped items or purchased items that can have random stats will be generated at the time of receiving them and will remain like that unless altered by in-game features such as blacksmithing or enchanting.

Inventory System

For the character's inventory, the idea is to have an on-character inventory which has limited space and a storage system which can be accessed in town. In storage, the player will have a nearly endless supply of items, but it will be a bit more difficult to keep track of what they have. I am planning to output their storage via some sort of link that the bot will pass to them to view the entirety of their storage while their inventory is viewed in game. As a result, a player could have hundreds of items in storage, but only a specific number of items they are carrying.

Currently looking to use something like Pastebin to pass the results through an API. Would export the file from mIRC and activate code on the hosting machine to upload the file somewhere and return a URL if at all possible. Not entirely sure how this is going to work, but I believe it might be possible to achieve, otherwise I am not entirely sure how I will achieve this. May need to host the bot on a machine where some files are accessible. Could be at inventory.tbrpg.digitalcyon.com for the time being, with the URL being specific to the player requesting it. It would be a pain to somehow protect this information from others and make storage publicly accessible though, unless I randomize the name of the file.

Turn-Based System

Development on the turn-based system for combat will be started on soon. Will provide more information once the actual code begins to take shape. Combat will involve melee, ranged, magical, and skill-based actions in addition to defending, attempting to flee combat, and changing your fighting position (front row or back row). Characters will also be able to use items (including NPCs).

Print this item

  Thoughts on Turn Order System
Posted by: Aesthemic - 11-08-2017, 08:27 PM - Forum: Development Notes - No Replies

Attempting to write this up with more specific language and a clearer direction of the combat system.

Unlike previous projects I have worked on, the idea of this game is to use a turn-based approach which rewards players for investing in agility. The idea is to use a similar system found in tactics-based games where faster characters typically have a turn more often than those that are slower. The turn system will use their base agility values to determine turn order and turn frequency, but other factors can influence that.

For each turn, the game will let the player with the highest agility take their turn at a cost of the slowest player's agility. To better explain this, provided below is an example of three players being involved in combat.

Agility Values:

A - 42 Agility

B - 85 Agility

C - 106 Agility

B is faster than A, but C is faster than both B and A.

Each of the players start the round with AP equal to their current agility. This can be previously buffed; their current agility will override their agility. Note that changes to agility during the round do not affect that round, but they do affect upcoming rounds.

The number of turns a character has during the round is determined based on how many times the lowest AP total in the battle goes into their total AP. As a result, A will get 1 action, but B and C will each get 2 actions. Priority of this will start with the highest AP. Once the first participant finishes their action, the value of the lowest AP will be removed from their current agility to give them their new AP. As long as there are participants in the battle that still have enough AP to take an action, the round will continue. Once no one has enough AP, a new round begins.

C goes first since he has the highest AP. He has 106 AP. He makes an action, and then once his action is carried out, his AP is reduced by 42, which is the cost of an action for this round. The character with the highest AP now gets to go next. That would be B with 85 AP. Again, once he acts, we remove 42 from his AP. His new AP is 43. The character with the highest AP now gets to get next. That would be C with 64 AP. Once he is done, he now has 22 AP, which is not enough to go again, therefore he is done for this round. The character with the highest AP goes next. That would be A with 42 AP. Once he acts, he has no more AP at all, and is therefore done for the round. Finally, we get to B with 43 AP. When he acts, he is at 1 AP, and therefore done for the round.

The round is complete. For the next round, the AP values reset back to that player's max agility. If the values have changed, the round will be based on those new values. This includes the cost of the round; if A managed to increase their agility, then the cost for the round would increase, but if they were slowed down, then the cost would be decreased.

If at any point a participant is unable to continue the battle for any reason, they are removed from the turn order. Once the round is done, then future rounds will not take their agility into consideration.

For this battle, the turn order for a round is: C - B - C - A - B.

C and B have similar speeds, but C will get his actions before B.

With a system like this, it rewards players for investing in their agility. There will also be items, skills, and spells that will be able to affect in-battle agility to determine turn order and frequency. For example, a player could have boots equipped that gives then 10% increased AP. Skills that use Agility get no benefit from the boost, but it does speed them up and potentially give them another action during a round.

Note: When a round is over and APs reset, any AP left over from the previous round does NOT carry over, unless the character has a specific ability allowing them to carry it over.

Print this item

  Basic Command Guide
Posted by: Aesthemic - 11-08-2017, 06:15 PM - Forum: User Guides - No Replies

Registration Commands


This command is used to register on the bot. Right now, registration is capped at one character, but eventually this command will be used to create a second or third character as well.


This command will return a list of the classes currently available in the game.

!classinfo <class>

This command provides some basic information about a specific class. Replace '<class>' with the name of the class.

!choose <class>

This is the final part of the registration process. Once you choose your class, your character is created and you're ready to start playing the game.

Print this item

  Forum Launch
Posted by: Aesthemic - 11-08-2017, 05:07 PM - Forum: Announcements - No Replies

I have recently decided to launch the forum for the TBRPG project as a way to share information on the project and get feedback from anyone testing or working on it. While I don't expect the forums to be widely used, they will serve as a way to communicate information in a way that is easier to access than conveying it through IRC.

Bug Reports

While I am using Mantis to handle development issues, I am going to have bug reports posted on the forums. This will ensure that I can insert the issues into the bug tracker in a way where its easy to reference. Once an issue has been submitted, I will check it to confirm the issue and then either resolve it then and there if the fix requires less than five minutes, or place it into the bug tracker. When a bug is confirmed and resolved, I will close the topic. Additional similar issues would need to be posted in their own thread.


To prevent some of the issues we had with displaying information with previous projects, I have opted to provide information about the game either via these forums or through some sort of Wiki. This would enable me to share information about the project and about any games made from the project in an easy format. I'll spend some time messing around with Wiki software to see if there is a great way for me to add items, enemies, and etc. in a standard format.


For people testing the project or any games that are a result of the project, I want there to be a means to provide feedback. This could be on ideas for new content within the game, changes to existing content to improve upon it, or ideas for new features or changes to the actual engine. These would be things that are not bugs, but would be ideas for improving upon what has already been created.

Print this item