![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image.png\")
<\/figure>\n\n\n\nLooking back at some of the setup for the widget<\/p>\n\n\n\n Setting up the text visibility like this wasn’t necessary since the return node has an output set up for it which I could use a select blueprint with a bool to determine if the text will be visible or hidden.<\/p>\n\n\n\n There’s a lot of tweaks that could be made to improve the feel of the game.<\/p>\n\n\n\n I packaged the game and sent it for written verbal feedback from my peers, first elements of confusion was being able to navigate the background. Second was the UI being disconnected from anything where adding background details to support the gameplay elements would make them stand at as part of gameplay.<\/p>\n\n\n\n He did not like the game keybinds being TG YH which felt out of place which I agree as these were temporary buttons while figuring out the new enhanced inputs system for unreal. I suggested I make the controls WS, up\/down arrow keys for each gauge which would make mechanical sense however he suggested making the keys AD, JL to be more comfortable with natural hand placement. I’d like to try both.<\/p>\n\n\n\n I shared my game prototype with a friend and he immediately starting creating a new design for the UI based on my mock design.<\/p>\n\n\n\n I really liked his new design which gave a lot of grounding for the game visually, I’ve sent a message to the course leader if I will be able to use my friends work as long as I credit him.<\/p>\n\n\n\n He used this tool for getting a planet too which is a nice way to create some planet assets for the game: https:\/\/deep-fold.itch.io\/pixel-planet-gener<\/a><\/p>\n\n\n\n We’ve divided the UI into this hierarchy:<\/p>\n\n\n\n Add own font<\/strong><\/p>\n\n\n\n I’ve decided to try out this UI in the game to see how it feels.<\/p>\n\n\n\n Setting up animated planets looks like a fun task, the site I found can export these planets as a png, gif or spritesheet, which using the spritesheet I can turn it into an animation in unreal as a flipbook. However I ran into the problem where widgets don’t implement flip books, looking for alternate solutions it would seem you can use materials in widgets and materials can create animations using flip books. I followed this tutorial to create the new animation material https:\/\/www.youtube.com\/watch?v=L0dT_dPPVPI and fixed the speed with a solution in the comments that said to take a time node and multiply it by 0.3.<\/p>\n\n\n\n The animation works perfectly, and I can even add parameters for the spritesheet and animation speed for easily changing.<\/p>\n\n\n\n I thought I’d be able to set the material on a widget image and change the parameter from there but I can’t find any documentation for it. To workaround this I can instead create a dozen material instances for all the planets and store them as an array, then draw from one at random. Since I have <\/p>\n\n\n\n One more touch I feel that was missing is fonts, I’ve promptly found one at dafont.com available at https:\/\/www.dafont.com\/rainyhearts.font which fits my game nicely with the UI provided.<\/p>\n\n\n\n Another thing I want to tweak is the rate at which the bars move which ill refer to as the climb rate. I’d like the bars to move faster when they’re further from their goal and I at first thought I could use Easing to do this where I can take two values and adjust based on an exponential and alpha, however when I implemented this I failed to consider that this will change the input from add & subtract to just ease into the goal removing the game element. This blueprint below could hypothetically work for a built in ‘cheat’ has a secret feature but still it was not my intended outcome. It would be worth in future approaching tasks a little more slowly by further breaking down the problem before finding a solution. Considering the reflection, the math I should be increasing the ‘gauge input rate’ float rather than replacing the addition\/subtract equation completely as changing the value of the ‘gauge input rate’ will change how much the bar increases\/decreases per tick. The final blueprint for easing that worked is this.<\/p>\n\n\n\n It doesn’t feel the most efficient but it works incredibly well after a lot of fine tuning of values for my purposes, I get the float range between the gauge fill line and the marker line, normalize to a range to fit the desired input rate,absolute to ensure it’s always positive before using clamp. I’ve tried careful adapting the ‘Normalize to range’ function to find a good zone but it seems like it just needs a limit for the minimum and maximum climb rates. With the custom easing function seamlessly fed into each input, adjusting the gauges feels really fluid now, it doesn’t feel tedious when the marker is set really far away and slowing down briefly when it gets closer to the marker adds a ‘drag’ effect which helps avoid overshooting.<\/p>\n\n\n\n Compared to earlier, the game has come very far in a short time with the introduction of a UI, dynamic background elements and easing the climb.<\/p>\n\n\n\n Few remaining changes I could make in future include a little more difficulty elements that appear overtime such as disabling a monitor, disabling the gauge, potential hazards? I think it’s important thought that I focus on converting this game to C++ as I’ve developed the prototype far more than I anticipated after receiving a UI to use.<\/p>\n\n\n\n Reduce timer gain, redo gauge marker. Re-export for more feedback<\/p>\n","protected":false},"excerpt":{"rendered":" Some time has passed since I last worked on the game due to working on other elements of the brief so I’m due a moment to look at how i’ve set things up.Now that I have a blueprint prototype, first thing I want to do is add a little more visual clarity for a small… Continue reading BSc2a – Hypercasual Prototype Continuation<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-455","post","type-post","status-publish","format-standard","hentry","category-uncategorised","entry"],"_links":{"self":[{"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/posts\/455","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=455"}],"version-history":[{"count":9,"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/posts\/455\/revisions"}],"predecessor-version":[{"id":501,"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/posts\/455\/revisions\/501"}],"wp:attachment":[{"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=455"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=455"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=455"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image-1-1024x202.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image-2.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image-3-1024x582.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/Idea3-edited-1.png\")
<\/figure>\n\n\n\n\n
![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image-4-1024x607.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image-7-1024x451.png\")
<\/figure>\n\n\n\n
For understanding the ease blueprint, I found the documentation page at https:\/\/docs.unrealengine.com\/4.27\/en-US\/BlueprintAPI\/Math\/Interpolation\/Ease\/ but needed a little extra help understanding it so checked with a guide on Youtube to see them in action, https:\/\/www.youtube.com\/watch?v=3zRSoAfTnWE helped me figure out how to apply the ease blueprint and the difference between each element in the function enumerator part.<\/p>\n\n\n\n![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image-8.png\")
<\/figure>\n\n\n\n
I went through a lot of trial and error figuring out what would be the best way to manipulate the climb rate, though it’s less optimised than before it’s achieved my goal in mind with little trouble. Key part of figuring this out has been running print strings to see what the new ‘climb rate’ is for the bar and making further changes based on that like seeing it went into negatives when ‘current’ was higher than ‘goal’ so I had to make it absolute.<\/p>\n\n\n\n![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image-10-1024x399.png\")
<\/figure>\n\n\n\n
I think it would be best to turn this into a function with pass-by-references to use for the other input actions.<\/p>\n\n\n\n![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image-12-1024x161.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/lloydmills.nuacomputerscience.co.uk\/blog\/wp-content\/uploads\/2024\/02\/image-11-1024x552.png\")
<\/figure>\n\n\n\n