Cooperative Innovations Ultimate Unreal Tool
•Download as PPTX, PDF•
0 likes•15 views
The Ultimate Unreal Tool presentation from Brian Marshall, Cooperative Innovations, at the Leeds Unreal User Group, Friday 3rd March, 2023
Recommended
More Related Content
Similar to Cooperative Innovations Ultimate Unreal Tool
Similar to Cooperative Innovations Ultimate Unreal Tool (20)
More from Game Republic
More from Game Republic (14)
Recently uploaded
Recently uploaded (20)
Cooperative Innovations Ultimate Unreal Tool
- 1. The Ultimate Unreal Tool I T P R O B A B LY I S N ’ T W H AT Y O U T H I N K … www.CoopInnovations.co.uk
- 2. Bingo…?
- 3. You
- 4. Simple, practical recommendations For time, going to cover some C++ and some Blueprint.
- 5. UCLASS() class COOPVR_API UCoopVr_BPLib : public UBlueprintFunctionLibrary { GENERATED_UCLASS_BODY() // Helper to get GFramenumber. UFUNCTION(BlueprintCallable, BlueprintPure, Category = "CoopVr") static int32 GetGFrameNumber() { return GFrameNumber; } // Log out in any build - release included UFUNCTION(BlueprintCallable, Category = "CoopVr") static void CoopLog(const FString& Message); }; A small amount of C++ for large benefits…
- 6. UCLASS() class COOPVR_API UCoopVr_BPLib : public UBlueprintFunctionLibrary { GENERATED_UCLASS_BODY() // Helper to get GFramenumber. UFUNCTION(BlueprintCallable, BlueprintPure, Category = "CoopVr") static int32 GetGFrameNumber() { return GFrameNumber; } // Log out in any build - release included UFUNCTION(BlueprintCallable, Category = "CoopVr") static void CoopLog(const FString& Message); }; Always comment everything exposed to Blueprint
- 7. UCLASS() class COOPVR_API UCoopVr_BPLib : public UBlueprintFunctionLibrary { GENERATED_UCLASS_BODY() // Helper to get GFramenumber. UFUNCTION(BlueprintCallable, BlueprintPure, Category = "CoopVr") static int32 GetGFrameNumber() { return GFrameNumber; } // Log out in any build - release included UFUNCTION(BlueprintCallable, Category = "CoopVr") static void CoopLog(const FString& Message); }; The Blueprint view…
- 8. UCLASS() class COOPVR_API UCoopVr_BPLib : public UBlueprintFunctionLibrary { GENERATED_UCLASS_BODY() // Helper to get GFramenumber. UFUNCTION(BlueprintCallable, BlueprintPure, Category = "CoopVr") static int32 GetGFrameNumber() { return GFrameNumber; } // Log out in any build - release included UFUNCTION(BlueprintCallable, Category = "CoopVr") static void CoopLog(const FString& Message); }; Why expose these two functions?
- 9. UCLASS() class COOPVR_API UCoopVr_BPLib : public UBlueprintFunctionLibrary { GENERATED_UCLASS_BODY() // Helper to get GFramenumber. UFUNCTION(BlueprintCallable, BlueprintPure, Category = "CoopVr") static int32 GetGFrameNumber() { return GFrameNumber; } What about GetGFrameNumber? [2023.02.27-08.53.42:724][178]LogToursCharacter: Verbose: Server_SetAvatarData BP_ToursVrCharacter_C_0 -> [2023.02.27-08.53.42:894][184]CoopPlayfabAccountLog: OnGetPlayerStatisticsSuccess: Statistics retrieved.
- 11. The Delay node limitation… They do not retrigger….
- 12. … you can reduce the risk with a little C++
- 13. Next common case is do something next time…
- 14. So tying things back to earlier…
- 15. Gameplay framework and what happens when…
- 16. Gameplay framework and what happens when…
- 17. Gameplay framework and what happens when… 1
- 18. Gameplay framework and what happens when… 2
- 19. Gameplay framework and what happens when… 3
- 20. Delay nodes are often a band-aid When you feel the need for one…. Communicate! Comment, log… For your future self and the team
- 21. Argh! It is lagging! G O O D C O M M U N I C AT I O N R E Q U I R E S E V E RY O N E …
- 22. “The whole game lagged…” “The avatar animation lagged, then restarted…” “A snowball that was missing hit me…” “That snowball I threw should have hit lagged…” “The fireworks started and everything lagged...” “I was waiting in the lobby for ages…” “When we world hopped, it was laggy”
- 23. Try to speak producer…
- 24. What does speaking producer mean? Trying to communicate in a way that works for the team as much as you can. That often means the why of something rather than the how.
- 25. Erm, what?
- 26. Unreal Editor is the Ultimate Tool because.. • It is the shared starting where people work together. • It gives a starting vocabulary for everyone to build from. • But YOU all are the important part. People make games and make the tools. • Communication is key. • Communication is hard and something everyone has to keep working on. Always. • Small, simple changes can add up to a big difference. • Try to work keeping in mind others around the team and how they see your work. • Things do not need to be perfect. But communicate, so the team knows if something is good enough. • Try out other areas. A little awareness of other disciplines goes a long way. • Try to speak producer. • Try not to be a gatekeeper.
- 27. Any Questions? www.CoopInnovations.co.uk Brian@CoopInnovations.co.uk @BrianMarshall@mastodon.gamedev.pla ce @BrianInVR @CoopInnovations We are on the lookout for: C++ programmers… and Blueprint Technical Designers
Editor's Notes
- I was tempted to make a bingo card… What we consider the ultimate tool isn’t on the slide. There is one feature on the slide that is key to the ultimate tool… but it isn’t the tool.
- You. More specifically all the human beings that form your team. Unreal doesn’t make games or experiences. People do. What Unreal does is provide a starting framework for people to work together. Unreal, it’s editor and features can only go so far though. After that it is down to the people to create and maintain a shared understanding… which is what empowers everyone’s creativity
- Here is a very small amount of C++. It is a blueprint function library with just two functions. Those two functions allow me to show how C++ programmers can be helpful to blueprinters… which then allows the blueprinters to be more helpful to the programmers.
- There are 2 functions exposed to blueprint here. GetGFrameNumber and CoopLog. The C++ comment above each UFUNCTION is picked up by Unreal Header Tool to make the tooltip.
- Here are some screen snips from Unreal editor overlaid. Note how CoopLog finds two functions, with different categories. It is easy to create nested catageories, but focus on always having that initial comment. There is a phrase the perfect is the enemy of the good. You don’t need perfect comments or names as long as you have something Having something means the blueprinters on the team have something that can ask about. So long as there is some shared information that gives a foothold for conversations… where for example you can figure out better descriptions or names.
- So I’ll tackle the second one first. CoopLog Unreal has Print Text node built in. In can print to the screen, or to the log (or both.). It includes colour and time options. It includes support lots of text formatting…. But it doesn’t include an option to log out in a release build. So CoopLog fills that gap. For a very small amount of C++ work, it allows anyone to log out in a release build from anywhere in Blueprint
- GFrameNumber is a core engine concept. It is a global counter that increases for every complete frame. Frames exist for the game thread… but also the render thread. It is used a lot C++ side for debugging issues between the game and other threads (mostly renderthread). In editor, Unreal does not display GFrameNumber. But in the text log file, it is show after the date/time, 3 digits wrapping at 999. A handful of lines of C++ code exposes it so Blueprint can log it out.
- We’ve seen a couple of easy things for C++ to expose over to blueprint. Now we’re going to look from the blueprint side using a common problem – delay nodes. Delay nodes appear very handy. But the built in Unreal version has one limitation that can catch you out… plus two common use cases where they’re not always ideal.
- If execution tries to start a delay while that delay node is already counting down… it just resets. The first call won’t continue execution past the delay node at all. Instead, you get one call after the delay time from the second call has run.
- It is easy to add a version that logs out a warning if triggered again while it is counting down. I’ll not show the code, if you’re interested contact me later. Note how the delay node in the picture has a good comment. It’s good because it says why it is there, rather than just what. It’s not so good as it is a normal Unreal delay node… it’s a bug in Curatours.
- Delay of 0.0 is commonly used, with the intent being next time this blueprint is run. The comment on the Coop Delay Frames is likely too small to read. It’s just clarifying the difference between frame and tick. Again the comment on the delay node saying WHY it is delaying, rather than saying “delay”.
- Here I’m using both CoopLog and Get GFrameNumber that you saw earlier. After the delay runs it will log out that is has run, plus the frame number. That log will also be in shipping builds. So while first authoring the feature, it may be enough information for the person writing the blueprint to debug any issues. If they need help from a programmer though, there are two things that help out here. The Format in the format text node is explicit. That means copying it from a log into “Find in blueprints” is likely to find this spot. Then when they arrive… there is the clear why comment on the delay node. So it is about giving each other the best information you can to work together. Final quick note. This also shows some limitations…. CoopLog doesn’t handle formatting itself, which means more complex blueprints. You need to unhook the execution when done with it. No verbosity
- So the last common case is dealing with the Unreal Gameplay Framework. The Gameplay frame in Unreal does not guarantee what order things happen in. So in BeginPlay for a Pawn for example, sometimes the PlayerState will be available, sometimes not. Casts are quite expensive, so while keeping references can cause it’s own issues it is often a good idea. But… you may need to retry in the future to allow for example, network replication to have come through. It isn’t just networked cases where things will be ready out of order. Pixel streaming for instance. This example isn’t perfect. It does work well enough and is using a Delay Node to retry, so is a decent real example. A few possible improvements would be…. Comment the delay node as to why 0.2 seconds was picked. If the case fails, CoopLog an error instead. Going to the delay is just going to keep looping.
- Here is an alternative that is often better. Using timers. Now this is real blueprint, so it is somewhat messy. I wanted to just find real, shipped examples for everything. Lets unpick it a little.
- It logs out, then retries. The log is explicit enough that Find in Blueprints will find it. It also is clear that it is retrying, rather than everything being broken.
- When it passes it logs out. The log will show if it retries and how many times. Then it will show it is ready, which can be seen in the log relative to other events. The time for the timer could be tuned by checking the logs to balance between retries and everything being ready.
- The retry has used Set Timer by Event, which is about as compact as using a Delay node. You can get a time handle from that, which lets you track what is going on. Here, Timeout Set Avatar and Role is a longer running timer. 10 seconds as it happens. Internally, Unreal uses the LatentActionManager to make the Blueprint Delay node. Creating your own Delay / Retry effect using timers is very similar, but gives you more control in Blueprint if you need it.
- So back to the meme. Delay nodes are often band aids. Put in and tweaked until things seem to work. On that machine. For that build. In that configuration, but maybe not when shipped. …and engine version. Timers can offer some more control, which becomes more helpful as things grow more complex. But the important part is the communication. Both to yourself and to the team. You’ve seen how programmers can document and expose some things to blueprint easily. You’ve seen how using those small extra capabilities can improve the communication, so a Blueprinter may find it easier to fix bugs in shipping builds. .. And if/when a programmer may help, the logs are more likely to have the information to help them get started, find where things happen in the blueprint etc. The examples are all from successfully shipped projects. Imperfections and all.
- Bonus, skip if low on time, audience are asleep or have pitchforks ready. A phenomenon in video games where the game slows down. Lag is the term for when a perceived delay occurs between a player’s input and the reaction in-game. But ‘lag’ tends to be used as a cover-all term for a plethora of issues, like low frame rate, slow internet speeds or network problems.
- What matters is communicating the issue so that there is shared understanding. It can be useful to setup a glossary for a project. That tends to help more for things that are specific concepts for a project. When anyone on the team reports something, try take the time to figure out it is. It may be obviously one thing to you, but that doesn’t mean everyone will understand a problem as that. You can and will be wrong too, assuming it is something else. If you search the internet for definitions of lag or lagging… a lot are network related, but you’ll also see framerate and other things. Perhaps the best definition for lagging is along the lines something felt off. Which is really valuable information. Things like recording video can help… being able to watch back what the other person experienced can help. Last point. This is not about building a perfect set of terms. Human beings are pattern matchers by nature. So once something has happened and been identified – “ah, the character rubber banded as the network was busy syncing after the world hop” Next time something similar happens, you may find things ignored assuming it must be the same thing. “ah, that must be the network is busy after the world hop”. The takeaway is that you will never have perfect communication and glossary across the team and that is okay. Try to foster listening to each other so that you catch all these cases where something felt off… rather than complaining because something wasn’t reported as exactly what you think it is….
- There isn’t an exact definition for a producer. Or a programmer, or a blueprint designer. By speaking producer I simply mean trying to describe things in a way that is going to be understood across the whole team. “I’m adjusting the low and high tightness thresholds for velocity on the CoopNetTrans component on the snowball, though really CoopProjectileComponent would have been better” “Adjusting the snowball so it doesn’t wibble as much in flight, like we saw in the test yesterday” Communication is hard. Naming things is hard. That example hopefully shows which is going to make more sense around the team. But it is still a bit much for a task title. Try to have both these open, accessible descriptions with the technical specifics still captured, but there more for when people need them.
- A lot of you may recognise this image. It is from Fallout 3: Broken Steel. The train was animated using a NPC wearing it as a hat. That simply meant that existing systems were able to create the train. A creative solution, using what was available. This kind of solution can often be perfectly fine. But it is the kind of thing that might cause performance issues if used on a larger scale. So it is a good example. Enough things were exposed to allow a creative solution. That is great. … just communicate it out, just in case there are other implications. That may mean another solution is needed later on, but it’ll be fine to prototype. You want to foster that will to experiment and allow happy accidents as Bob Ross put it… But you want to be a little careful to avoid dumping things on others. Everyone is in the project as a team… until people decide otherwise…
- Any questions…?
- Any questions?