How to Design an In-Game Currency and Shop in hyperPad

An in-game shop is a state-management system. The Project must remember currency, check a price, approve or reject a purchase, update ownership, and show clear feedback. Build that logic with one item before creating a full catalogue.

This article is a documentation-backed design blueprint. The complete purchase and persistence workflow still requires current-app reproduction before it should be presented as a copy-exact tutorial.

Define the rules first

Use soft currency earned inside the game for the first prototype. Do not imply that it represents real money or an App Store purchase.

1. Build the earning loop

Create one collectable and one currency label in a Scene. A collision or touch event can trigger the reward.

Use Set Attribute and Get Attribute to manage the value. Connect visible or audible feedback so the player knows the reward was accepted.

Test that:

• one collectable adds the intended amount;
• the same collectable cannot add currency again;
• the label matches the stored value;
• restart follows the rule you defined.

2. Build one shop item

Create an item card with a name, Graphic, price, purchase button, and ownership state. Keep the item effect simple, such as changing the player Graphic or enabling a cosmetic accessory.

When the player presses Buy, the logic should:

1. read the currency;
2. read the ownership state;
3. compare the balance with the price;
4. reject an insufficient balance;
5. subtract the price after approval;
6. set ownership to true;
7. update the button and feedback.

The Behavior Interface Overview explains how event and data connections work.

3. Separate purchase from equip

Buying an item and selecting it are different actions. Ownership answers whether the player can use the item. Equipped state answers which owned item is active.

After purchase, change the button from Buy to Equip. When equipped, update the selected-item Attribute and apply the result to the player Object.

This separation makes it easier to add more items later.

4. Handle rejection clearly

Test two rejected states:

• the player does not have enough currency;
• the player already owns the item.

Do not subtract currency or change ownership. Show a concise label, sound, or visual response explaining what happened.

5. Decide what persists

A prototype can reset everything when the Project restarts. A larger game may need currency and ownership to persist between sessions.

Document the intended behavior before adding storage. Test current persistence and save-file features in the installed hyperPad version rather than relying on an older screenshot or legacy help page.

Your verification matrix should include:

• close and reopen the Project;
• switch Scenes;
• restart a round;
• buy, equip, and unequip;
• attempt the purchase with exact currency;
• attempt it with insufficient currency;
• reset saved progress.

6. Avoid double purchases

Disable or guard the Buy action after ownership changes. Rapid taps should not subtract the price more than once.

Run the purchase several times with a fresh state and inspect the final balance and ownership value.

7. Add the shop to the game loop

The shop should support the game, not interrupt it without purpose. Decide when the player enters it, how they return, and whether gameplay pauses.

Use clear UI and keep the active currency visible when the player is making a purchase decision.

8. Measure the design honestly

For a local prototype, observe whether players understand how currency is earned, what an item costs, whether it is owned, and how to equip it.

If analytics are configured for an exported game, keep shop visits, purchase attempts, completed purchases, and real-money revenue as separate measures. A soft-currency purchase is not revenue.

Current verification status

The state model and named Behaviors are documentation-grounded. A copy-exact current-app build, persistence test, and authentic screenshots are still required before this page can claim that every step was reproduced.

Use the blueprint to build one item and record the result of every state transition. Expand the catalogue only after earning, buying, equipping, saving, and resetting behave consistently.