Blueprint tutorial
Blueprint Functions: Write Once, Reuse Everywhere
Turn repeated Blueprint logic into functions, pass data with input and output pins, and call those functions from other Blueprints to keep systems tidy.
1. Spot repeated logic before it spreads
Open a Blueprint where you already repeat small bits of logic, such as formatting interaction text or checking whether the player can use an object. A common beginner mistake is copying the same node chain into three places because it is fast in the moment. That works for one evening and then becomes expensive to maintain. Instead, select that repeated logic and think of the outcome in one sentence, like Return the prompt text for this pickup or Calculate the final heal amount. If you can describe the job clearly, it probably wants to be a function. Functions turn messy graphs into named tools, which is essential once your prototype grows past a single room.
2. Build a custom function with explicit inputs and outputs
Create a function called FormatPickupPrompt inside a pickup Blueprint. Add an input pin called ItemName of type String and an output pin called PromptText of type String. Inside the function, use simple string assembly so the output becomes something like Press E to pick up Lantern. Every function should answer one clean question or perform one narrow calculation. The input pins tell the function what it needs, and the output pins tell the caller what comes back. This makes the graph self-documenting. When you read the call site later, you can understand the intent from the function name and pins without re-reading the internal nodes every time.
3. Replace duplicate graphs with function calls
Go back to the Event Graph and call FormatPickupPrompt wherever that text is needed. Feed in different item names and route the returned PromptText into your widget update or a Print String while testing. This is where the payoff appears: if you want to change the wording later, you edit the function once and every caller inherits the improvement. For indie teams, that is a real speed gain. Small projects still change constantly, and centralized logic lowers the cost of iteration. A function call also makes the Event Graph smaller, which keeps your high-level gameplay flow readable instead of burying it under formatting or math details.
4. Call functions across Blueprints on purpose
To cross Blueprint boundaries, get a reference to the other actor first. For a beginner-friendly example, let the player overlap a pickup actor and cast the overlapped actor to BP_Pickup. Once the cast succeeds, call FormatPickupPrompt on that pickup reference and show the returned text on screen. The important lesson is not the cast itself. It is the sequence: get a reference, confirm the type, then call the function you need. This keeps ownership clear. The pickup Blueprint knows how to describe itself, and the player Blueprint only asks for that information. That separation is cleaner than teaching the player graph how every item type should build its own prompt.
5. Use functions to keep systems expandable
After this first pass, you can keep extracting reusable jobs: GetDoorStatusText, CalculateDamageAfterArmor, or CanAffordUpgrade. Not every node chain should become a function, but any logic you expect to reuse, rename, or test is a good candidate. Think of functions as the difference between a prototype you can survive and one you have to rewrite. When your Blueprints read like short sentences made of function calls, debugging and collaboration both get easier. For your starter pack, the main win is simple: write the rule once, expose the data you need with input and output pins, and call it from anywhere that has a valid reference. That is the foundation of reusable Blueprint architecture.