Above shows a quick clip of my up-to-date prototype in action. The movement is now much closer to how I envisioned it, I simply need to carry out playtesting while continuing to iterate (during the next project), and I can perfect it and possibly even look to develop the full concept. This easily meets the goals I set myself for this project submission, so I am pleased with the progress I have made up to this point.
There is only one issue left in the prototype, which unfortunately I don’t believe I can fix for submission, but I will continue trying and can at least fix it inbetween now and April. When using the mouse, the camera often ‘judders’ which can be really frustrating, and reduces the fluidity of the movement. I believe this could be to do with the various mouse-based interactions conflicting with each other, but it will take more research and most likely some guidance to fix it. Other than this, the prototype is in a good state to submit.
Since last working on my prototype I have started a fresh with a slightly different and much simpler script (with the help of George). This should help editing and troubleshooting easier, as there is much less complex script to cause errors or confusion. I can build up more features and in-depth movement later on, such as in BA3b. For now, though, I am still experimenting with different methods and figuring out how everything should function.
As shown above, the current prototype:
The character successfully tilts on up and down movement, which I had some problems with initially where the actor was rotating but the camera wasn’t Various attempts at fixing this are shown in the gallery above, but I eventually managed to fix this by simply attaching the Rotation to the Camera as a second target, as well as being attached to the FlippyMesh (For some reason it didnt work when attached to the SpringArm, only the Camera).
However, this also causes the camera to rotate on MoveForward as well. This is a problem I still need to fix, as I only want it to happen on MoveUp (on Moveforward, the Mesh should rotate but not the Camera).
My next step to try and fix this will be to try copying the logic and hooking each function up separately, making one catered to rotating both components while the other only rotates the Mesh — this should fix my issue.
Next steps (goals before submission):
I used starter content and followed tutorials to experiment with a 2D Side scroller. I did this to improve my knowledge of more varied blueprints as well as start playing with a basic collectible script which I could later use the logic of for my 3D prototype.
Coins spawning every 2 seconds
Showing the use of text strings to return when the player has touched the coin – this helped me figure out the logic of how to determine when the coin had been triggered, which could then be developed to add the coin to the player’s total count, and destroying it.
Overall, doing small tests like this is helping me expand my knowledge in a varied way. This will help me know how to apply my knowledge better and start to figure out how to create things more independently.
My focus today was to iterate on my movement controller based on my evaluation in my previous post. Firstly, I wanted to make the Pitch of the Actor rotate based on vertical movement. So, when Weedy swims downwards his nose will point forward and vice versa, to increase the feeling of realistic swimming movement. Otherwise, it appears as if he is just hovering up and down. I found the solution to this very simple.
In the Movement Sequence Blueprint, I have highlighted the edits I made to achieve this. The script already did a similar action for MoveRight and Roll and I used this to figure out how to do the same for MoveUp and Pitch.My basic understanding of this is:
Although this was successful and it functions in the way I wanted, I do feel like I need a better understanding of exactly why. I have a rough idea of how the nodes work, as outlined above, but I’m not entirely confident in it. I think the main focus for me right now should be to continue learning Blueprints and improve my knowledge much more, so I can more confidently make changes and understand how to create the desired functionality for my prototype.
The above Gif shows the above in action. When I move Weedy vertically, his body tilts in the right direction, giving more realism and life to the movement.
What I have noticed, though, is that in the above graph, the nodes to tilt the Pawn in the direction of Forward movement are disconnected. This is something I need to look into and may have happened accidentally when editing the BP. This is another reason why I need to improve my BP knowledge, so I can quickly understand and fix details like this.
Otherwise though, I am pleased with the progress and will simply keep working on various details of the script in order to refine both my understanding and the functionality of the prototype.
Another area that needs improvement is how the script handles collisions. There is an area of the graph which deals with what happens when the actor collides above a certain velocity, in order to release particles and carry out other behaviour. Right now, the collision can be a little extreme and I feel this makes sense in terms of a spaceship or plane, but not an animal swimming through water. When Weedy collides with the wall, I would like to achieve a much softer impact.
Currently, when moving vertically, the camera remains looking at the back of the Pawn. Instead, I would like to test out how it feels if the camera rotates towards the direction that Weedy is facing when he moves vertically up and down (LMB/RMB). I feel like this may be helpful for the player if they can see where they are going when rising up or down through tunnels within a level. I did some research into this and begun playing around with the script. I did make some minor progress but struggled to achieve much. I found a helpful answer that broke down the necessary steps to achieve something like this (below), so I can use this as a starting point, but as I have said before – I need a better understanding of Blueprints first, so I think it’s wise I take a few steps back before attempting too much at once.
I think a good idea might be to see if I can attend some extra UE4 Drop-in sessions while also going back and trying some more BP tutorials before I progress.