Collection: GD4 TP2 Portfolio

Spare Parts



I worked on the saving and loading for the customization system for our game. I go into a lot of detail on how I implemented this in week 8 of my journal, so I will briefly explain what I did here. 


This is the event graph for the customisationPlayer blueprint, which is a blueprint I made for the customisation scene to handle all the saving and loading. When the scene loads, the load is called, and when the scene ends, the save is called. 


The load is then called again in the bike blueprint, where the values are loaded into the bike to make it behave differently based on how the player has customised their bike. 

3rd Person Camera

I developed the camera switching and 3rd person constraints for our game. I go into a lot of details on the development of this in week 4 in my journal, so I will briefly summarise the result of my work here. 

I added a basic first person "headCam" to the bike, that can be switched to on a button press. This was later developed upon to be our actual main camera, which I show in the camera tab. 


 The flip flop activates on camera and deactivates the other, and this can simply be toggled between. 



The RotateCameraRight input event is an inputaxis event, so the direction of rotation can change by pressing the left or right arrows. A rotator is created from the axis value and fed it into the Z/Yaw node of the rotator, which is fed into an AddWorldRotation function with the camera as its target, which is then linked to a SetWorldLocation function. The location being fed into the function is calculated by getting the world location of the car mesh (the bike itself), subtracting it from the world location of the camera, getting the vector length of this, and multiplying this by the forward vector of the cameras world location in the negative direction, and then this is added to the world location of the bike.



This is my camera constraint implementation. Essentially, the Y component of the camera transform is checked against 2 different angles, and the camera is constrained to these, so it cant rotate past them. If the camera is not breaking these conditions it can rotated as normal, otherwise do nothing, so it wont rotate past those points. 

UE4's WheeledVehicleMovement - Bike

Week 1: Myself and Brian tried to create a working bike built off the WheeledVehicleMovement component that is built into UE4. We recreated the car from the tutorial but were unsuccessful with transferring this to a bike. 

Week 2: I continued this work alone. I took the car and changed its collision boxes so it resembled a bike. (see figure 1)

From here I simply changed the cast to WheeledVehicleMovementComponent4W to a normal WheeledVehicleMovementComponent, and changed the number of wheels being acted on. (see figure 2)

This resulted in the need for some minor changes that needed to be made, and after this I tried varying the many different parameters available to the WheeledVehicleMovementComponent to try and get it to behave more like a bike. (see figure 3)

The outcome of this was not ideal, and to put it simply I couldn't get it to behave anything like a bike. I still feel like it could be done, but given the strides being made with Ronan's hover bike, it was the right decision to drop this approach. 

I tried it again with a rough bike model but this was even less successful. It just breaks on spawn for some reason. All the same things were done as with the car version, so it could be the model itself isn't rigged properly. This was also ultimately a dead end though. (See figure 4) I added rectangular stabilisers in the wheels to stop it from falling over. 


Vehicle Tutorial We Followed

Force Feedback


I added the crash force feedback to our game to find out how it is done so we can add more of it for the Beta release.

Customization Save


Customization Load



General Reflections

It was slightly difficult for me to let go of the 3rd person camera the week after I made huge improvements to it, but I got over it. The user is who the game is for, and if the user says to get rid of it then I have no reason to argue. It's good being able to let go of these things for the betterment of the project. 

I'm really happy with the customization in general and I'm just glad I got to help with it by doing the save and load for it. I learned how to do this previously for the split times so I was comfortable with it. 

I was disappointed that we weren't able to use the vehicle component in Unreal to behave like a bike. I feel like if it had gotten going it would have been great for the ease of changing the behaviour of the bike. However in the long run it was the right decision to cut our losses on it. 

Overall reflections on the game and team is that I'm really happy and proud of how it has turned out. We work really well as a team and communicate well generally overall. 

Git was a difficulty at first since most of us didn't know how to use it. Then afterwards, the binary files like the level especially meant that the repository grew quickly and also meant that no 2 people could work on the same thing at the same time. We got used to this after the first few weeks. It helped a lot that we communicate so often and so well in my opinion. 

I'm really impressed with Shane's work on the crowds and menus. It really adds a lot to the atmosphere to the level and the polish of the game. 

The work on the level took the most time and effort in my opinion. This is part of the reason why I'm glad we worked more loosely at the start, because the level really just needed time and freedom at the start because it's hard to plan how good the level will be, it just needed effort and rigorous testing. 

The other reason why I'm glad we worked loosely is because of the bike. We couldn't have known how the bike would be made until it was made since we were doing it from scratch. Maybe we were unorganised about it in terms of planning it, but it just didn't seem feasible or even possible to us at the time. I'm really happy with how the bike turned out so I think it's justifiable. 

There's definitely been some low points this year that could have been done better. Firstly semester 1 was a disaster in terms of organisation and scheduling, as well as content and basically everything really. I genuinely wanted to drop out because the pressure was ridiculous. The communication from the board members as well as among the board members was lacking considerably. There have been entire modules that I just felt were a distraction and the CA schedule left us with very little to do for half the year then way too much to do in the second half. The team project theme of tourism was a massive creative constraint that left every team disillusioned with the entire process. I think all of these problems could have been avoided with more communication with us the students and more leeway for change and feedback. The board should be as coherent a team as we are expected to be. 

Finally I'd just like to say that I'm really glad to have gotten the opportunity to work with my team. It's been a rough year for all of us and I think we can all agree that we wouldn't have gotten through without each other. I definitely learned a lot and am very grateful for the experience. 

Improved 3rd Person Camera

In week 6, I made more improvements to the 3rd person camera, before the decision was made to remove it. More details on this can be found in week 6 of the journal. 


Figure 1


Figure 2


Figure 3


Figure 4