Download

Bimodal RPG (aka JRPG) Implementation Questions

I’m looking to recreate the bimodal style role playing game typically of the Japanese variety. When I say bimodal, I mean that there are typically two distinct modes of play where one mode offers an environment for exploration and the other traps the player into battle between enemies with a party of characters selected from the exploration plane. The exploration plane feeds into the battle plane in that items found in treasure chests or bought from shops can be used when fighting various enemies. In order to engage enemies, there is the concept of an “encounter” where some pseudo-random system or other condition (like collision with enemy on exploration plane) is met for the player characters to meet the enemies on the battle plane. The basic trappings of the exploration plane are the “World Map”, the “Town”, and the “Dungeon”. The World Map is a macro level hub that allows players to explore the world and traverse to Town and Dungeon nodes. The World Map usually offers some trivial battle encounters where there can be met by players. Towns are exploration nodes that can be reduced to essentially exploration areas without battle, although certain conditions can trigger battles. The dungeon is a exploration node where encounters occur in the greatest frequency with a non-trivial structure to encourage full traversal.

Unlike Western counterparts, where exploration and combat occur on the same plane, the separate nature of the modes requires quite a bit of persistence between the modes. Items found in the exploration plane must be persist in instances of each exploration level. Those same items can be used as consumables or equipped as weapons and armor by the player’s characters in specific character loadouts through the use of a menu system that allows the player to customize their characters, like in most RPGs. Number of consumables and character loadouts must also persist from exploration to battle in that weapons equipped by in the exploration menu must be shown in battle. Consumable items must match the item tallies from exploration. Any items used in battle can no longer be used on the exploration plane. During battle, the player’s input tends to be polled, rather than pushed by the player, when certain conditions are met, usually that the player’s turn is ready. When turn is ready, the player can choose an action from a menu and the mapped action will occur. Certain calculations are made behinds the scenes to determine the effectiveness of the action. Both player and enemies then taking turns until either the player wins or loses.

I’ve seen quite a few UE4 projects that are molded in the Western fashion where there’s an action game style combat system with statistical abstractions in the background. I think such systems may actually be easier to implement than the JRPG bimodal style systems. I wanted to run by a few of my thoughts after reviewing some of the UE features on how to implement a Japanese style RPG.

Conceptually, moving in the exploration plane and exploring different areas, town, dungeons, is essentially loading up a different level. That seems fairly straightforward. Changing between the exploration and battle plane is potentially similar in that there could be levels dedicated to housing the battle system. What I’m not too sure about is how to pass information between the levels. A quick look seems to indicate that the Game Instance object would be suitable for inter-level persistence, but I’d like to know if there are any better patterns to use.

I have certain thoughts about implementing the battle system by using the experimental AI features, but I still need to think on it some more.

I’m actually wanting to do the same thing. Replying so I can find later.

You’re not alone. I had the same idea but totally at the beginning of the whole project. Have you had any progress so far?

As I understand it, the easiest way to track all of the data is to add variables into the GameMode, as that would remain consistent between level loading. Alternatively, you could/should use a Savegame state, as it will need to record all of this data for when you save. Adding a temporary Savegame into the GameMode would keep you from having to have two copies of the data in memory during saving, and you can simply pass the GameMode’s Savegame data directly into or from the Savegame slot, reducing the locations that would need to read/write the data when something happens.

That’s what I would do, at least.

Or you could do this…
32d7db2a031742a8f963384bb7937aafdd29607b.png

This could offer some insight: http://q-gears.sourceforge.net/gears.pdf It’s pretty old now, but about a decade ago some intrepid modders tried their hand at reverse engineering FF7 and documented a lot of their findings on how the game worked.

I started a bit of exploration into the project and tried extending the GameInstance blueprint to help with some simple persistence, which works somewhat. I tried passing Character objects, but for some reason, when passed between levels, the reference would always be null. I created a struct to house things such as stats (hp, attack power) and certain Character component pieces (skeletal mesh, capsule half height). Character Component objects probably don’t need to be kept necessarily if the exploration mesh and the battle mesh are different, but for my purposes and due to the relative power of today’s computers, it seemed more elegant to simply keep the exploration and battle mesh the same.

https://youtube.com/watch?v=MnjdN_piMa8

I’ve started up a journal for a Reddit project called Project R. The first journal entry can be seen above. Additionally, I’ve started up a Github repo for the project hereif you want to take a look at the progress I have so far. It’s not much, but may help some people look at something, or avoid some mistakes I’ve made. I plan to make another update to the project to hopefully clean up some messy blueprints and code.

It’s a fairly straightforward thing to do… once you need to start an encounter stick all the relevant info into GameState and load up a CombatMode level. That CombatMode level will have 2 separate “components”, the logic component which will be the level you load up, and the environment component which will be a logic-less visual only level that you will stream in based on a parameter in the GameState.

I was able to finally add some simple battle logic for basic attacks. The player character is driven off an AIController that reads an queued command from the menu. The controller then runs through some logic to read the queued command and reset after the command succeeds. Added some simple floating text and support for multiple enemy encounters.

https://youtube.com/watch?v=G7Nv4TTda8E

Alphanumber, are you still working on this project?

I don`t think its even necessary to have the battle phase at a different level. You can have a hidden battle area below the main level, and during a short fade, just relocate your character to there and back when battles occur.