Blueprint tutorial
Blueprint Variables & Types: Storing Health, Score, and State
Learn how Blueprint variables hold game data, why type choice matters, and how Set/Get nodes turn raw values into readable gameplay logic.
1. Treat variables as your game's memory
Open or create a simple player Blueprint and add four variables: Health as a Float, Score as an Integer, HasKey as a Boolean, and PlayerName as a String. These four cover the main beginner mental model. Floats are useful for values that may need fractions, like health draining over time. Integers are useful for whole-number counts such as score, ammo, or coins. Booleans store yes-or-no state, which is perfect for doors, objectives, and unlocks. Strings hold text that can be shown to the player or logged during debugging. Even in a small indie prototype, choosing the right type early makes the graph easier to read and prevents strange conversions later.
2. Use Set nodes when the world changes
Create a small test flow in the Event Graph. On Begin Play, use Set PlayerName and give it a sample value like Runner_01. Add a custom event called TakeDamage, subtract 20 from Health, then use Set Health to store the result. After that, run the value through Clamp (Float) with a minimum of 0 and maximum of 100 so health never goes negative or past your design cap. Do the same with Score by creating an AddScore custom event that increases the integer and stores it with Set Score. A Set node is not just assigning data. It is the moment your game commits to a new reality, so it should happen in obvious places that match the gameplay event.
3. Use Get nodes when logic needs a fact
Now build decisions from those values. Pull a Get Health node into a Branch that checks whether Health is less than or equal to 0. If true, print a simple Dead message. Pull Get HasKey into another Branch before a door or reward interaction. This is the pattern you will use constantly in Blueprint: Set when an event updates the data, Get when another part of the graph needs to read the current truth. Separating those roles keeps debugging simple. When something behaves incorrectly, ask two questions: was the variable ever set to the expected value, and is the graph reading that same variable in the correct place?
4. Debug values aggressively while you are still small
Add Print String nodes after a few Set operations so the screen shows the latest Health, Score, and PlayerName while testing. Beginners sometimes feel this is temporary scaffolding, but it is a strong production habit. Blueprint systems are visual, yet invisible data still causes most bugs. If your score is not increasing, a Print String after Set Score tells you whether the issue is the math, the event never firing, or the UI reading the wrong value. In solo development especially, fast feedback beats elegant architecture. A variable you can see changing is a variable you can trust enough to build other systems around.
5. Build state first, polish second
The big takeaway is that variables let you describe the current state of the game in plain language. Health says how close the player is to failure. Score says how much progress they have made. HasKey says whether the next interaction is allowed. PlayerName says what text should appear in the interface. Once those values exist, almost every other Blueprint becomes easier to write because the game has memory. Before adding fancy effects, make sure your core state is stored cleanly and updated intentionally. That habit scales from tiny jam projects to larger commercial work, and it is the difference between a prototype that feels random and one that can actually grow into a full system.