Memories Code Base

This week we revisited our action code and began to redesign it from the ground up. This was due to our use of Unreal's AI systems and Behavior Trees. These systems are great for real-time AI but when we tried to retrofit its movements and combat into pseudo-actions, we began to see cracks.

The goal is to create a dance so to speak. The player plans out their movements and attacks by adding individual actions. After they place an action, the AI responds with their own counter move. This continues until the player finds a solution they are willing to lock-in and let play out.

After a few days of redesigning the code base, we now have a single parent character that both the player and the enemies share. Inside we developed a core system for adding and removing actions as well as general fixes. Our goal with this new character class is to develop a solid foundation based off of our previous version. Keeping the parts we like and redeveloping the parts that need work.

A few items we will be redesigning include:

1. Action User Interface

Right now, its difficult to understand what is happening or what each action does. In the new version you can see that most of everything is stripped down. This week we will be trying out a few new UI elements and schemes to better inform the player of what is happening.

2. Control Schemes

In the old code base, our actions are added by the movement input direction currently held. This caused issues with players not being 100% sure how far they need to move the control stick or how long they had to hold the keyboard buttons down. Others had difficulty pressing a button to change states, like shifting to crouched or sprinting states, then adding the action.

We plan on revisiting these control schemes to create a more streamlined and simple version. First we want to implement a button press to add actions again to reduce the feeling of inconsistency. Second, we plan on trying out another solution to state changes. One that will reduce the number of buttons players need to know and use during planning. Finally, we plan on adding the mouse cursor back into the game from our initial combat prototype to test out its use.

3. Combat Circles

Although the combat circle implementation does solve a few problems it doesn't fix the issue of close movement around an enemy. In the previous code base, we created a second circle around the enemy which players snap-to when nearby. This is less than ideal, as players must consider two different overlapping circles when performing melee attacks.

Along with this issue is the fact that these circles are a bit too restrictive in their movement distance. Players have no choice in how far they move, they must move the maximum distance no matter what. This can cause awkward approaches to enemies that make the player feel cheated if they have to first move away from their target to get the right distance to attack.

We plan on exploring a circle grid system attached to the player's target as opposed to the player character. This circle follows the enemy target and has several rings that the player can move between. This is more inline with our chess game mentality and it would solve the issues of not being able to circle strafe around enemies. A movement that would reinforce our combat dance and remind players of other similar games that use melee and circle strafing like Zelda or Dark Souls.

The goal is to invoke the feeling of those games but keep the strategic mechanics. Like playing Dark Souls if you could pause time and plan out several actions in a row. This is a good goal for us, as the resulting fight would be tense and action oriented, but the planning would still be strategic and interesting.

Were looking forward to trying out this version of movement and interaction to see what comes of it!