Feature implementation: v 0.3.0 - Player Progression about godot-open-rpg

[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!

[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.

[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.

[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]

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.