Greetings, at this point in the saga of the Hopewood project the development of the game is well under way in pursuit for the alpha build. However before we start I want to do a quick update on the team formation. Samuel Dowding has moved to the admin team working on the unifying all the applications and getting the interface for the main menu and leaflet information. However Me and Sam are still working together assisting each other on both of the projects allowing synergy for the game and main app.
Now onto the production of the game. My main objective is to create functioning prototype of the game by the 14th of February aka the most important day of the year. So the first thing I got working on was the floor tiles and procedural generation.
Pictured above is the tile blueprint asset. its a basic floor tile modelled by Annie, the tile has three lanes for the character to switch between during gameplay. Four arrow components were used in this asset the main one which can be seen in the photo is used as a reference point for where the next tile is being spawned from, then there's three other arrow components in each lane which is used as a target point for where the player will snap too when switching between lanes, the lane arrows are also used as a spawning point for where the obstacles and points will be spawned from. Essentially these arrows are used for the spawning of the procedural generation and to give parameters for the player navigation. Then there's a box collision which is used to trigger the spawning of the next tile and the generation system.
Pictured above is the bluebrint of the tile, it has two main actions, firstly is the "Spawn Obsticles" which is triggured via the event beginplay which is directly attached to a custom function titled "Spawn Obsticles" which we will go through momenterally. The second action is the "Tile spawn and Despawn" this is triggred when the player character makes contact with the collision box of the asset, this then triggures a custom fuction that spawns the tile. This then uses the large arrow pictured above and then places the tile there, which then activates the obsticale spawner thus creating a loop for the procedual generation of the game.
This is the obsticle spawner fuction, this allows a random object from an obsticle or point collectable to be placed on a lane, this is done by using branch nodes and InRange checks. How this system works is that it gets a random float number in the range of 0.0 to 1. it then checks if it matches the ratio I set it to and if its within the range it will spawn the object linked to that ratio if not it then goes stright to the next branch and then the cycle is repeated until it ether spawns somthing or leaves the lane clear and after that the cycle repeats on the next lane and so forth. This allows me to fine tune the ratio in which an object will spawn allowing me or anyone in the team to balance the gameplay to make it more fair for the player. Although this system works really well I am still doing fine tuning on its ratios to prevent unbeatable tiles within the gameplay enviroment.
This is how the full obsticle spawner function works with what was mentioned above repeated with each set focusing on one lane with Lane 0 being the left lane while Lane 2 is the right lane.
This is a simple point system made via using an interger varible which gets increaesd each time the player makes contact with an Opel collectable, this increases the varibles number by 10 before it destorys the instence of the opel in the enviroment. However when the player colides with the collision box of the tile the point varible increases by 1. This creates a simple scoring system for the game in which a player is given points for progressing through the endless path while Opels gives the player even more points resulting in an added layer for the gameplay.
Pictured above is some of the other elements of the character blueprint. Firstly is the Debug test for the death sequence which is just a simple [C] keypress event which then goes through the custom death function which will be covered later on. Then theres a section for creating the U.I of the game which is done via the Beginplay event and then getting the HUD widget and adding it to the games viewport. lastly is the first part of the player movement. This section is using the starting blueprint for the thirdperson character but altered to keep the player moving forwards.
This is the second part of the character movement in which it uses an interger variable for the lanes as well as a new lane varible for marking the players next lane, this is also used to prevent the player from falling off the sides of the tile. This then plays a timeline of the player moving to the next lane using the arrow components mentioned earlier on as the point the character will be moving from on the tile.
For the games loss condition to function I created a a simple clolision event that happens when the player makes contact with any obticles of the game, its a simple cast to third person character which then activates the "Death" function. which is also where the high score data is stored, this is discussed right below.
Now onto one section I thought would be hard was the lose condition and saving the highscore data, thankfully it was easy to learn and understand. For a simple gameover screen I made the ThirdPersonCharacter Blueprint ragdoll and disabled the character to be able to move to prevent the game from going on. It then displays a hud widget of the game mover screen allowing the player to ether restart or exit the game. after the "Lose Condition" bit of coding is done it goes straight into the "High Score" save data section; this works by checking if there's already a save of the players score, if there's none it then registers the players score as the high score and creates the save data. If there is already a save data it compares the integer variables of the players score to the pre-existing save of the high score if the players score is higher then the saved data's score it overwrites it with the players score and updates the save data but if there isn't higher then nothing happens. Although rather basic in contrast to other forms of saved data this is all that we need for this project and so far has worked with no errors.
Now onto the last bit of the blueprinting in this chapter and its the gesture controls of the touch screen. This is the only thing I couldn't get to work properly and unfortunately couldn't figure out, this is my main objective to try and fix before the prototype deadline. How this system meant to work is that when a finger is pressed on the touch screen it would check if its X/Y coronates and calculate its position and then it would proceed to the movement code. for instance if I touched the screen to the left the character would move to the left. However this didn't work and kept making the player move to the right or jump. This bug needs to be fixed for this game to be able to run on Android devices.
Now I've covered all the progress that I have done so far my next step in the production of this project is to try and fix the touch screen interface and start getting any completed assets into the game build and prep it up for the inital deadline.