Combo Attacks not being Combos

During this week I worked primarily on camera rotation, a camera management system, and player attacking.  Most of it went smoothly and I was able to complete most stuff within a reasonable time period, except reworking the player attack.  Before, the player’s attack was based on a simple bool that was set when player pushed a button, and reset and when the player released the button.  However, this was method was only meant for testing, and this week I planned to make the attack based off of time.  To begin this reworking, I added a time variable to the weapon component which would be manipulated when the attack button is pressed.  This simple change and implementation wasn’t time-consuming, but implementing a combo attack to trigger if the player made three consecutive attacks within a short span of time took more time than I planned.

Moving on, my first step to tackle this problem was to add a counter to the weapon component to be incremented when the player attacked and reset if the player stops attacking or if the combo is triggered.  Next, I rewrote a portion of the code to make the counter be incremented whenever the attack button is pressed, followed by a check to increment time variable if the counter is not zero.  Then, I wrote several checks based off of the value checking: if time is equal zero do nothing, if time is less than 0.175 seconds attack, or else reset counter.  This enabled the counter to incremented and reset as I desired, making it easier to make the combo work.  Finally, I placed another check inside the attacking statement that would check the value if the value of the counter was three or greater which in turn would trigger the combo.  To test this, I had the program print the value of the counter to the log every time the attack button was pressed, and print out “Combo” to the log if the combo was triggered.  After some testing and fine tuning, the combo worked as intended.

– Logan Acree

Using the Custom Engine

Last week, for the first time since starting the project, I was able to begin working in our engine.  However, before I could begin implementing all of the prototypes for the player and camera, I had to learn how to use it.  Learning how to use the engine, was not a huge issue in itself, but it is completely different from anything I’ve ever used before.  In addition, using Lua along with C was a little weird at first.  Nonetheless I got used to it and was able to implement a prototype for the player and camera.  The biggest issue at hand was making the player model face the direction it was moving without being able to use key input.

I decided to take this problem on bit by bit, instead of all at once, so the first thing I did was make a player component and a player movement system.  The player component contains floats for health, time, and movement Time and a vector three for direction.  The player movement system runs on entities that contain the player component and a transform component.   At this point, I had everything I needed to fix the problem: making the player face the direction they’re moving.  At first I tried rotating the player, but then realized that it would not work because rotation is a quaternion.  However, I had functions to convert between quaternions and vector threes.   Moving on, I set the player’s direction vector to have random values for x and z, next I used a vector three to quaternion function to convert it to a quaternion.  Finally, I set the player’s rotation equal to the new direction quaternion, and now the player faces whichever direction it is moving.

— Logan Acree

Rewriting and Fixing

During this past week, I spent my time fixing and updating numerous mechanics for the player and camera.  One of the first things that I worked on was updating the player from a table to a class in Lua, because this would enable me to keep the player’s variables protected and all of its functions and mechanics in the player file, not in main.  In addition, by passing in all the data needed for the player when creating it with a constructor, I could make an update function specifically for the player.

Moving on, to one of the biggest challenges I faced this week: getting the camera to follow the player without rotating with it and transitioning to a second camera for a cut scene.  At first I had the camera attached to the player as a child, which allowed the camera to follow the player and rotate with it, but it increased the difficulty of manipulating the camera directly.  In addition, I was also having difficulty removing the camera from the player and making it pan around the level to simulate an opening cut scene.  However, after doing some research and playing around with the camera I came to realize I was going about this the wrong way.

The first thing I was doing wrong was only using one camera, when instead I should have been using two of them, and the second problem was having the camera attached the player as a child.  In addition, I came across something in Polycode which became a game changer: Polycode does have a “getPosition()” function, but you can only call “getPosition()” on each individual transform component of an entity. For example:

local x, y, z = entity:getPosition().x, entity:getPosition().y, entity:getPosition().z

After learning this I was able to have the player_camera follow and look at the player without having it attached as a child, and I could do the same thing with the main_camera, but I just had the main camera look at the player and stay stationary.  By now, I had already solved most of my problems, and all that was left to do was setup a cut-scene. This was fairly simple, for all I did was setup a time-based event trigger which toggled the main_camera on and the player_camera off, create a function to make the main_camera move to different locations based on time, then toggle the main_camera off and player_camera on when the cut scene was complete.  In the screenshot above, you can see the player through the main_camera during the cut scene.

– Logan Acree

Prototyping the Player

This week I began scripting and prototyping the player and camera features in LUA using an engine called Polycode until the engine for the game is finished.  Getting the ball rolling for getting working controls was easy enough, however getting them to work exactly as I wanted was a different case.  The biggest problem I came across this week was getting the player and camera to move and rotate independently of each other, while still having the camera follow the player.  This seemed simple enough at first to fix, but then I came to realize that LUA did not have functions for getting an entity’s position and rotation, but only ones for setting them.

To fix my problem and get the camera working the way I wanted, first I had to setup a way of storing the position of the player, which I did so by using a table called “playerPos” which had an x, y, and z variable.  Then in my update, whenever I call “setPosition” on the player, I set the “playerPos” variables to the same values passed in.  This allowed me access to the player’s position which then could then be used to modify the camera’s position which was stored in a similar fashion using the same method.  By now having access to both positions it will now be easier to setup more complex and camera mechanics in the game.  For instance, putting the camera on “rails” for cut-scenes, or having it track an other target besides the player at the same time if a player “locks-on” to them.

– Logan Acree