Feature implementation: v 0.3.0 - Player Progression

[SearedSquawker]

Key:

Developer (Dev): The Godot designer using the open rpg project as a development tool to make RPGs
Player: The in-game player character
Character: An in-game unit (can be a player character, npc, or monster)
User: The person that will be playing the game created by the developer

Planned Features

Stat Creation

• There will be no required stats for characters unless specified by the developer.
• Each stat will be implemented by the dev with some example stats provided
• Stat creation includes a name associated with a value
• Stats have a setting determining if the stat is required on all characters
  • Useful for making default stats expected on all characters

Character Sheet Creation

• Character creation includes a name with various stats and progression systems for each
• There will be two types of stats a dev can add to a sheet:
  • Progression stats
    • Progression stats will be updated with a chosen progression system upon the increase of a selected stat.
      • Most commonly the selected stat will be the characters level
  • Associated stats
    • Associated stats are linked to other stats with calculations between each stat selected
      • CharacterStat4 = (CharacterStat1 + CharacterStat2) * Constant / CharacterStat3
      • Associated stats can also be linked to other character’s stats.
  • Starting stat values can be either a set value or a random value within a range.
  • Progression methods are selected by the dev per stat on a character
    • This allows certain stats to function differently than others (e.g. Pokemon with basic stats, IVs, and EVs)
    • When selecting a formula controlled progression system, if the formula requires additional variable inputs they will be provided by the dev here
    • When selecting a point-buy controlled progression system, the dev will also select a point buy category to group the stat within.
      • (might be diving in too deep here…) points awarded with the point buy system could be based off a stat with a formula as well (e.g. ToME where every 10 levels you get an extra point to spend)
  • Character stat sheets will be able to save templates of the stats and settings to be used for other characters
    • Sample sheets will be provided to make a basic RPG template for beginners
    • A default template can be changed by the developer to load a new character with the template already applied.

Stat Progression Methods

• Implement two types of character progression: formula controlled and point-buy
• Formula controlled should allow the designer to customize how stats progress each level
• Point-buy allows the developer to determine how many points are given per level for the player to distribute as they please amongst stats listed in the same point buy category.
  • Implementation of a user interface for the point-buy system should be planned in a future update

Stat Progression Mapping with Curves

• Allow dev to create progression charts with curve inputs
  • Curve’s X value will be based on a value provided by the dev,
    • Most common stat expected is the character’s level
• Developers can alternatively use an equation with variables that can be linked during character creation
  • Graphs will not be available for this as unknown variables will make it impossible to graph, they could be provided after variables are known on the character sheet, but that would require polynomial interpolation which is outside the scope of this… for now.

Godot Tool support to create characters

• All items above should be implemented with Godot tools to allow ease of use for developers when creating characters
  • Might be a stretch goal, have not messed with Godot tools too much yet.

Implementation

Character Sheet Creation

• Custom Resources are a must here to make templating easier.
• A character will be a class with:
  • A list of Stat classes(see below)
  • A list of point buy category pairs of string (name of category) and int (amount of points awarded to this category on level up)
  • Reference to Progression Stat (e.g. Level)
  • List of image classes; classes will contain
    • ImageTexture to display image
    • Vector2 to position image
  • List of label classes; classes will contain
    • String for label display
    • Font
    • Float for text size
    • Vector2 to position image
• A class for each stat will consist of:
  • A dictionary for storing stat names with a class of float and bool
  • Bool for selection of Progression stat or Associated
  • Bool for selection of formula or point buy progression
  • Reference to formula selection
  • (Read more on formula storage further down)
  • String for the category selection
  • String for formula of the associated stat
  • List of stat references needed for the above formula
• Formula parser will need to be made to decipher developer made formulas
  • Recommend the following algorithm to parse formulas: https://en.wikipedia.org/wiki/Shunting_yard_algorithm
    • O(n) should be fast enough, but will need to stress test to see if formulas will need to be encoded to a more computation friendly format for the editor
  • Letters a - t should be reserved to represent stats the formula uses

Stat Progression Methods

• List of Progressions will have be a class containing the following
  • string for the progressions name
  • GodotCurve for a curve
  • string for the formula
  • Int for amount of variables based on stats
• Progressions can be checked if they are a curve based on if the GodotCurve is null or not
• Developer interface should have variables added as letters a - t in order, this will allow parsing to be easier when selecting stats to use in the implementation
• When encoding the function it should ensure the amount of variables used match the amount of stats used
  • If three stats are being used in the function they should only use a, b, and c.

Future Plans

• User interface with stats to implement point buy system completely
• Character GUI
  • During character creation, devs can add images and labels to customize the user’s view of the character.
  • Devs will also be able to create a dev view of the character in order to see stats that will normally be hidden from the user in the final product.
• Character skills and abilities should be closely coupled with this model, if not an extension of it.

Discussion and Feedback

I would love to hear any feedback on the proposed model before I begin the implementation.

[food-please]

Hey, thanks for putting this together! Thank you for the detailed write-up, it's clear that you've put quite a bit of thought into this. This is a good place to start from and it's encouraging to see interest in the project.

My initial concern is that this sounds very complex at the character stat level. I wanted to provide a few thoughts that may help refine the scope of the issue. Please keep in mind that these are generic project-level concepts. The GDQuest team, on the other hand, has substantial experience that helps guide a project like this.

• If you haven't yet, please check out GDQuest's JRPG combat demo. Up until now I've been envisioning re-implementing this for Godot 4, but other ideas are great too! At the very least this may serve as a good starting point.
• It may not appear so at first glance (I keep thinking good grief, the controller/gamepiece scheme could be simplified), but we want to be as specific as possible and as simple as possible.
  • The idea isn't so much that a developer could build a game using our "engine"; rather the Open(J)RPG project could be easily extended. I constantly need to come back to this with my own work.
  • For example, a dev wants another stat. I think we would prefer to simply add another property complete with setters and getters to the custom resource rather than implementing new (sub)classes, figuring out how to reference it, etc.
• We want to be explicit with stats, I think. What I mean is, stats are usually specific to the game. If we decide to use "attack" everywhere, but another dev wants to use "physical strength", references to attack should fail at the compiler level in the engine rather than at runtime because we're looking up stat name strings.

With the above in mind, I think it would be good to have a specific goal in mind. It would keep the project simpler and I would guess that it would be more fun to work on. Think early Final Fantasies, Dragon Quests, Chrono Trigger. Stats don't need to be complicated: perhaps just HP, MP/Action Points, Attack, Defense, etc. If you would like, feel free to sell us on a combat design and draft up what stats we would need for that.

There will be no required stats for characters unless specified by the developer.

I think that the opposite is true. We actually do need to know what stats we want in-game, since we are developing a sample game rather than an engine. We'll also want to specify how we want them to be modified, and what we want them to do. These can, of course, be tweaked later but the numbers and the "rolls" are the core of the RPG.

Developers can alternatively use an equation with variables that can be linked during character creation

I expect that this will be the way to go, though I may be wrong. At the end of the day, stats are just numbers and calculating damage or an associated stat is nothing more than an equation away.

Custom Resources are a must

Sounds good to me!

Stat Creation

"Stat Creation" may be as simple as default values in a custom resource.

Stat Progression Methods...
Godot tool support...
Character Sheet Creation...

If I understand correctly, we'll want these somewhat separated from the stat system itself. For example, we can have a generic character creation UI system or a point-buy UI system, etc. and all of these operate on the same custom resource.

There will be two types of stats a dev can add...
Implement two types of character progression: formula controlled and point-buy
Developers can alternatively use an equation with variables that can be linked during character creation

For this project, we'll want to pick one option (probably, though not necessarily, the simplest) and stick with it. I think that it would be a good idea to begin with the stats themselves, before touching on anything larger. The mentioned project includes base stats, calculated stats accounting for modifiers, temporary modifiers (such as status effects), etc. What stats do you think should be in-game and what should they do?

Thanks again!

[SearedSquawker]

My initial concern is that this sounds very complex at the character stat level. I wanted to provide a few thoughts that may help refine the scope of the issue. Please keep in mind that these are generic project-level concepts. The GDQuest team, on the other hand, has substantial experience that helps guide a project like this.

I definitely was looking at this as a framework for future devs to use to make RPGs rather than an example project. I feel a lot of tutorials on the net show how to make a thing that works for one setting, but not something that can last for multiple games. I do agree that I should save this for an engine and not a example project.

• If you haven't yet, please check out GDQuest's JRPG combat demo. Up until now I've been envisioning re-implementing this for Godot 4, but other ideas are great too! At the very least this may serve as a good starting point.

I have seen the project, but not dived in and watched from end to end, I can do that if we want to emulate it more. I kept thinking of making a general system similar to this: RPG-Databases

• For example, a dev wants another stat. I think we would prefer to simply add another property complete with setters and getters to the custom resource rather than implementing new (sub)classes, figuring out how to reference it, etc.

Currently I am implementing it so that once the custom resource is made the end user would just make a new Stat resource, give it a name and add it to a Character resource. I feel this teaches how powerful resources are for making things really customizable. I also see how it would introduce lessons on project management and is complex/advanced for new users.

I think the best compromise would to make character resources with default stats that can be added if the resource code is changed.

If you would like, feel free to sell us on a combat design and draft up what stats we would need for that.

If we want to stick to simple I feel the GDQuest's JRPG combat demo was the simplest, I would like to add something new like active skill interactions similar to Super Mario RPG/ Mario & Luigi: Superstar Saga.

Stat Progression Methods...
Godot tool support...
Character Sheet Creation...

If I understand correctly, we'll want these somewhat separated from the stat system itself. For example, we can have a generic character creation UI system or a point-buy UI system, etc. and all of these operate on the same custom resource.

That was essentially my idea, so we are on the same page there.

There will be two types of stats a dev can add...
Implement two types of character progression: formula controlled and point-buy
Developers can alternatively use an equation with variables that can be linked during character creation

For this project, we'll want to pick one option (probably, though not necessarily, the simplest) and stick with it. I think that it would be a good idea to begin with the stats themselves, before touching on anything larger. The mentioned project includes base stats, calculated stats accounting for modifiers, temporary modifiers (such as status effects), etc. What stats do you think should be in-game and what should they do?

Personally I know formulas are more complicated, but it provides a deep dive into RPG design and balancing. Planning progression curves is something almost no RPG tutorials talk about and without it, it makes balancing an RPG seem like guess work. I would like to ensure we are imparting techniques that people can use for a long term project that goes beyond a single battle that the current demo shows.

Thank you so much for the response, I would love to chat on discord if you have time to go further into the topics. I recently posted in the GDquest-Projects channel if you need to find me. For now ill think about the combat system and maybe make another issue to reflect that. I have also finished an outline of the code needed for this issue, but still looking at examples and code to format it correctly.

[NathanLovato]

Sorry I couldn't answer earlier, we have been hard at work on our new website.

Before you get too far into this task, I'd like to highlight that this project is meant more as a learning resource. It's not meant to become a framework. We want the code to be relatively specific to one game. The goal is to provide something people can learn from, rather than an add-on or framework that would provide generic functionality and a lot of flexibility.

If you make a generic solution to reuse in all kinds of games, your code will necessarily become abstract and more complex than necessary for one game, thus much harder to dive into and learn from, and you'll trade the educational aspect for the productivity tools and flexibility. If you want to help people learn project management in particular, generic systems really make it difficult and confusing for them, hurting their learning.

Also, there are already a bunch of experienced people working on the reusable framework side of things. For example, there's this amazing add-on, Pandora, for a generic solution for managing data for this kind of game. Even if it's still in development, it's far along and already has features designed for abilities, stats, and more (quests, items, and whatnot). So at least the tooling aspect is looking to get well covered by the community already.

My teammate and I will need more time to pause and think in detail about the implications of each point in your proposal. With a first read through, you have some great suggestions in there. Overall, it just sounds too generic and complex for supporting learning.

We're launching our new website and there's Godot 4.2 today so we're going to be busy (and we're exhausted) for a couple more days, but I'll share this with my teammate to check out.

[NathanLovato]

I hope you'll excuse us for the delay: this year has been extremely busy for us as we researched and developed new technology for educational purposes. Things should settle down in 2024, but this year has been a lot of crunch and November and the beginning of December were no exception.

Preliminary reminders, our goals with this project

As mentioned previously, we would like this project to be more of a demo than a framework. In general, our approach to development and teaching focuses on keeping code specific (and efficient to maintain as a result) over making it abstract and generic.

This is useful for education, as abstraction and generalization makes learning much harder for people, and our mission is focused on education.

If you want to teach abstraction and generalization, in our experience, it is much more accessible to people if you first teach very specific and concrete code, and you abstract from that as you introduce new requirements that create a need for abstraction.

Adapted proposal

Shifting focus to your proposal, a lot of ideas you have are great, and I would very much love to have stats with character progression, the user interface, formulas, just without the abstraction part.

Here's a suggestion for a specific implementation, which would greatly simplify the code compared to the original proposal:

• Stats: All stats and, possibly, their progression curves and related functions can be grouped into a single class that extends Resource. Stats should be specific to this demo: one stat, one member variable. You can read the variable name with code reflection to get the stat's display name, like the Godot editor does with the Inspector dock.
• Character data and creation: This can be another resource with a stats field property and all the other properties you want to give the character.
• Progression system: Feel free to pick the one you like most!

By going specific, you can strongly type the code, make it really explicit and easy to read, and you shouldn't need any strings and indirections to make associations between systems, which greatly reduces the surface area for bugs (strings are especially error-prone).

• Character display: You mentioned a list of properties, including a texture and position. To me, it depends on the intended user interface and experience, so I would focus the work on getting the user interface looking great first and after a couple of iterations, adapt the data to that. Note that if you want flexibility in Godot, the best way to do this is to store a reference to a scene instead of adding lots of properties. Godot 4 also gives you full flexibility by allowing you to create a toggle that allows developers to switch between e.g. a scene slot and a list of default properties for using the default display (display name, texture, etc.).

But in any case, I'd rather have properties tailored to the user interface, so focus first on the design and feel, rather than doing things the other way around. This code only exists to serve the needs of the game experience and user interface. In general, all game code exists to serve the game's design and feel at the end of the day so the design should always be on the front of our minds, and the implementation details are here to serve that.

So for this part, I would recommend leaving the implementation details of that out, iterating over a concrete user interface, and then nailing the implementation details based on the needs of the user interface.

• Formulas: they can be plain functions.

Note for you: GDScript comes with the Expression class that can parse expressions and formulas for you at runtime. So you wouldn't need to implement an algorithm to parse formulas.

But there again, in a production environment, I would always prefer to have strongly typed code over text-based formulas.

---

In short, the above proposal is all about making the code as specific and explicit as possible. The point is to reduce the amount of code a lot and make it easier to read and learn from. The focus is on education over making a framework.

Is this something you would like to contribute? The community would definitely love this, and we would be more than happy to have you help with this RPG demo.

Please let me know if you have any questions or suggestions.

[food-please]

Hi! Just wondering if any progress has been made with regards to player progression. I had been imagining that 0.3.X would probably have the whole combat loop included, and so this would be a valuable piece of the puzzle.

I'm hoping to, by the end of the week, put together an issue that has the milestones that we'll want to hit with the combat update. Progression will definitely be one of those points.

[NathanLovato]

@food-please we didn't hear back on this issue, so I don't imagine there has been work on this yet.

[SearedSquawker]

Hi! Just wondering if any progress has been made with regards to player progression. I had been imagining that 0.3.X would probably have the whole combat loop included, and so this would be a valuable piece of the puzzle.

I'm hoping to, by the end of the week, put together an issue that has the milestones that we'll want to hit with the combat update. Progression will definitely be one of those points.

Unfortunately, @NathanLovato is correct and I have not completed any work on the issue yet. Life and work picked up and I have not been able to put time into side projects. I also don't see it easing up anytime soon, so I am fine with someone else taking the reins.