gdquest-demos / godot-open-rpg

Learn to create turn-based combat with this Open Source RPG demo ⚔

Godot 4 Open RPG

OpenRPG is a a demo showing how to create a 2D traditional RPG in Godot 4. It's currently a work-in-progress. If you want to help

➡ Follow us on Twitter and YouTube for free game creation tutorials, tips, and news! Get one of our Godot game creation courses to support our work on Free Software.

Project Goal

The goal of this project is to provide the gamedev community with a demo that shows one solid way to create and structure the code for a 2D RPG in Godot 4. You can reuse the code in your own projects, and also learn from the project's codebase.

As we're teachers, our focus is on providing a learning resource that is both practical and educational. We're not trying to build a framework.

We're putting heavy emphasis on code that:

• Is updated to take advantage of what GDScript 4 has to offer.
• Is accessible to users with solid code foundations. It should be a good starting point and reference for those diving into an RPG project.
• Follows our GDScript guidelines.

Our Mission

Together, we're creating a codebase and tools to show you some good Godot practices to create:

• Turn-based games.
• A combat system.
• An inventory system.
• Character progression.
• Maps with transitions, dialogues, grid-based movement, and more.
• User interface with multiple menus.

And more! Do you want to contribute and improve your programming skills with Godot? Check out the open issues, suggest improvements and report bugs by opening new ones, and be sure to check the contributing guidelines below.

Contributing Guidelines

All contributors are welcome 🙂. To ensure a smooth and a productive experience for everyone working together, we came up with some guidelines we all follow here.

Check our Contributors Guide for more information 😄

godot-open-rpg's Issues

Map: Prevent Player from moving on the map during battle

Currently, during battle, the actor can freely move around the map. This allows the player to initiate multiple battles at the same time and causes a disconnect since the player appears to have randomly teleported while in battle.

Add a Magic or Skill CombatAction

Currently the characters can only attack, because they only have this action available. This task is about adding support for using Magic in Combat, or from a menu. See #15 for the data part of this task

Add combat music

Add a stream player node to the Game scene, that we can use to play background music. It should trigger playing the combat theme (assets/audio/bgm) when an encounter starts (using the encounter signal).

Integrate the concept art into the combat system

1. Convert the project from 720p to 1080p
2. Rename player battlers to Robi, Godette (and corresponding battlerAnim scenes)
3. Add Robi, Godette and Porcupine sprites
4. Replace platforms from under characters with shadows
5. Adjust UI position (life and mana bars)
6. Add background and foreground art

Move party/monster detection out of the node_tree and global groups

Make it possible to create a list of party members

Map: followers don't follow the player

UI: Design battle end screen

Following on the work being done on the radial menu, the battle rewards screen needs some work as well

Clarify and improve the readme

• clarify note about the project's current scope and goal
• banner picture
• project icon
• screenshot

Implementing Actions

This is an issue to design and implement different actions, such as Healing, Magic, Item, Special (?).

We could do as it is now for the Attack. Nodes that implements actions.

How should we handle level design?

With milestone 0.2 almost done, the next area to work on is the map.

Godot's tile map editing tools are still lacking, so I suggest that we use the Tiled map editor with the imported from vnen.

Now there's all the design work left to do to decide on the map creation pipeline. Do we try to constrain the number of layers a map should use come on which objects on properties should we use in Tiled?

If anyone has good experience with that, your feedback would you welcome. If not I'll try to find time to work on a prototype map.

Replace the Covenant Code of Conduct with the GNU Kind Communications Guidelines

The last commit to the README.md saw the inclusion of the Covenant Code of Conduct (henceforth referred to a CCoC). I suggest switching a modified version of the GNU Kind Communications Guidelines (henceforth referred to as GKCG).

The CCoC not only adds unnecessary burden to the maintainers by requiring them to investigate any "unacceptable behavior", both directly related to the project and also on social media, but also forces upon them the "responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful."

This forces the maintainers to become the "thought" police for all contributors which is as ridiculous as it is unmaintainable and allows for the development of "witch hunts" where people go out of their way to find "unacceptable behavior" to have code rejected.

This is not a theoretical problem and examples can be seen here.

The GKCG, on the other hand, provides similar requirements for interactions, but doesn't encourage witch hunts or create an unneeded burden on the maintainers of the project. This will provide a more welcoming environment to contributors who do not have to fear that a tweet from 5 years ago will get code removed and contributions banned from the project.

Modifications will have to be made to fit this project. All references of GNU and related software will need to be changed, for example, but the rest of the guidelines for interacting should remain in place.

Map: integrate the conversation system

Also create an NPC that takes one cell and that the player can interact with. The job is mostly to port your work on the grid-based & conversation demo to Godot 3.1, integrating it in here.

Add mana bar

With the implementation of skills - see #16 - battlers will now have mana to spend on skills. Thus, the mana should also be shown in the UI, below the life bar.

Map: Crash if you move into a party member

To fix this, grid movement will need some changes. party members represented on the map should not spawn collision boxes, and should not be treated as regular actors.

Concept art and base assets for the first battleground

When battle ends return to map

For this, #17 needs to be completed and depending on the outcome of the battle return to the map if at least one of the party member is alive or the Gameover screen if everyone is dead (#29 )

Code Guide

It's possible my skill set is just too low for projects of this size, but I'm already having a hard time following what the code is doing as we slowly ramped up.

Would it be possible, or even desirable, to have some sort of guide that explains how the code interconnects?

If so, I think starting it early would be good so it doesn't get overwhelming later.

This might be a good use case for the wiki.

Remove Grid being responsible for handling events

Currently the Grid.gd is responsible for handling encounters and objects interactions, this shouldn't be its responsibility, it should only handle if a pawn can or can't move to a given cell.

---

What I think what we could do is:

• It checks if a given cell is empty or not
• If empty it return the position
• Otherwise it emits a signal passing the object blocking the movement

In the LocalMap we handle these events by telling if there is any encounter, an object to be loot, an NPC interaction, a Dialogue to start.

So this whole block of code on Grid.gd will become something like:

  var cell_target_type = get_cellv(cell_target)
  if not cell_target_type == CELL_TYPES.EMPTY:
    var cell_pawn = get_cell_pawn(cell_target)
    emit_signal("cell_occupied", cell_pawn)
    return
  return update_pawn_position(pawn, cell_start, cell_target)

Then on LocalMap we handle the event based on the Pawn.type, in a method which the Grid.cell_occupied signal is connect to

Map: Following the player

Code a pawn/character that can follow the player. As it's grid-based motion, it just needs to reproduce the player's movement sequence with a one, two, three steps delay (e.g. if there's 4 party members - it's like the game snake).

This pawn shouldn't collide with the player. Also look at the Battler and BattlerAnim/BattlerSkin(?) scenes: I want us to always have the animated character skins separate from the controllers themselves so that we can swap them anytime, and later work in parallel with artists.

I'm not sure how to best track the player's motion. I would use a signal, e.g. moved(direction : Vector2), and store the last X moves in an array/stack/heap, erasing them as you go. Feel free to suggest something better!

You can use a YSort node to sort all the characters on the map. Don't worry about conflicts if both pawns end up on the same cell for now.

Drops from monsters

Allow the user to configure the possible dropped items from monsters and their rates.

Experience and levelling up

Add the ability for the characters to gain experience when killing monsters, to level up when they reached a certain amount of experience, and to increase some stats when they level up.

Battler: use stats to inflict and take damage

UI/Health: Make battlers take damage and have the lifebar update properly

I think the lifebar displays the amount of damage taken instead of the battler's health

Start building the art style for combat

Set the base art style for the characters, the background, and the UI elements for the Battleground
As that's the focus for v0.2 and the initial goal for this game project. We'll build up the map part with v0.3

I decided to start with character design. Next up is the battle background

• #42 Monsters design
• #43 Battle background art

Design and prototype monster AI

The monsters should be able to target their opponents based on flexible criterias:

• They could try to target the character that's weakest to them
• They could heal once when their life goes below a certain threshold

Etc. I am not sure how to best do this so every option available on the monsters not hardcoded in the base class, without creating a complex gambit system or something like that. Feedback and ideas welcome!

Combat: turn order based on the battlers' speed

Add a base class to represent Magic and/or Skills

Create a class that we can use to store all the data related to a special attack a battler can use.

Should this class extend Resource or Reference? We'd use it to store only the data related to a skill (then another Object or Node could use the resource and provide functionality on the Battler, or render it in the UI).
See StartingStats https://github.com/GDquest/godot-turn-based-rpg/blob/master/godot/combat/battlers/jobs/StartingStats.gd

[question] Whats the future of this project?

Whats the future of this project? There are currently no issues which makes me think that there is not much to be done here. If there is anything I could do, I would love to know!

Cannot go back from the select arrow to the CombatAction menu

Add ability to cancel enemy selection and to go back to the command select menu

Battler: add death and removing the battler from the battlefield

Combat: Add victory/loss conditions

Depends on #3: check for victory/loss when a battler dies

Game over screen

Write the initial game concept

Create a repository's Project to keep track of issues' status

Gladly the project is growing at a good pace, in these times we are very likely to start a solution for something being worked on already, or even stepping on eachother's work. We already got some, e.g. #54

I propose to make a simple, automated, project to keep track of issues and PRs that are:

• still to be done i.e. To do
• being worked on i.e. Doing
• solved i.e. Done

Improve actions menu

This is the current look of the actions "menu":

The new menu shall:

• Show the mana cost for actions
• Action's description
• Action's base damage
• Prevent actions from being selected if not enough mana available
• Better UX overall (bigger text, only visible when necessary, etc.)

Create a banner for the readme and a project icon

Animated number or icon (for damage, healing, status... in combat)

In a lot of JRPGs, when a unit is attacked, the damage that was done would appear giving the player an easy to digest number (as opposed to doing mental math on the spot). This is also done for healing, status effects, etc.

I think this would be a good addition.

As a mock-up I made:

Speaking with faildozer on Discord, he suggested adding a canvas layer for these popups and emitting a signal to the canvas layer which I think is a great idea.

Visuals: Add combat start and end transition

Reuse the transition shader from https://github.com/GDquest/make-pro-2d-games-with-godot/

Equipable items

Pieces of equipment for players.

Should they also restrict which jobs can equip them?

Usable items

This issue is about creating a base system for usable items, i.e. healing potions, attack potions, food, etc..

CombatArena: add intro sequence

Party and monsters appearing one after the other

UI: Contextual menu during combat

As shown in example

Add monster groups/a way to compose encounters

We need some way to create groups of monsters to balance the foes the player will face. It's just lists of monsters to start with (e.g. two slimes and a porcupine), with some code to pick a random group among groups that should spawn in a given area on the map.

Currently there's no notion of formations in the game, front or back rows in combat. I think a basic system will be enough for this project.

Player inventory

A menu to display the items that the player currently has with him.

I believe that it shouldn't be complex, just a list should do the trick.

Map: grid-based movement

Add support for grid-based movements when outside of combat

Design the first monsters

• Add some context about monsters and the world the characters live in, in the game concept
• Draw concepts for monsters

UI: Add widget to select a target during combat

I'd like to have a cursor in front of the battler, final fantasy style. Try to use the same anchor point you'll use to move to the battler upon attacking (Battler.position)

Write a goal/outline for 1.0, plan milestone for v0.2

I'll be working on that today, before presenting the project at the Kyoto indies meetup tonight.

Base class for items

A base class for any type of item (usable, equipable, etc..)

Following what we've been doing so far, I believe the data should be separate from functionality aka use resources for them.

Write a changelog for v0.1 and v0.2

Like https://github.com/GDquest/Blender-power-sequencer/blob/master/changelog.md, to keep track of the project's growth