Lesson Goal

In Lessons 1–3 you:

• Chose a revenue model.
• Mapped it into your core game loop.
• Designed offers and price points that feel fair.

In this lesson you will bring that design to life by:

• Implementing your first in-game store entry point.
• Wiring a simple IAP flow (or mock IAP in early prototypes).
• Emitting analytics events so you can measure what happens.

You will not build your final production economy here.
You will build a small, testable vertical slice of your monetization.

Step 1 – Choose One Store Entry Point from Your Loop

Open the loop diagram and monetization spec from Lesson 2–3.

Pick one of the entry points you already circled, for example:

• “Results screen after a run”.
• “Hub/town between missions”.
• “Store button on main menu”.

Write down:

• Where the player can open the store.
• What default tab they land on (for example, Starter Pack, Cosmetics, Currency).
• Which offers from Lesson 3 will be visible in this first version.

Keep the scope tight: 1–3 offers on one screen is enough.

Step 2 – Build a Simple Store UI Skeleton

Inside your engine (Unity/Godot/Unreal), create:

• A store screen with:
  • A clear title (for example, “Shop” or “Support the Game”).
  • One section per offer you want to test.
  • A “Close” or “Back” button.
• A button or entry point in your loop that opens this screen.

Implementation examples:

• Unity:
  • Use a Canvas with a Panel for the store.
  • Hide/show the panel via a StoreController script.
• Godot:
  • Use a Control scene for the store.
  • Add it to the tree and toggle visible.
• Unreal:
  • Use a Widget Blueprint for the store.
  • Add/remove it from the viewport via your HUD or Player Controller.

For each offer:

• Show:
  • Name (for example, “Starter Pack”).
  • Price (match your ladder from Lesson 3).
  • Short value promise.
• Add a buy button that calls a single handler function (for example, OnBuyStarterPack).

Step 3 – Wire a Safe IAP Flow (Or a Mock Flow)

You have two modes:

• Production integration with real stores.
• Mock/testing integration for early design work.

Production Integration (High-Level)

Depending on engine and platform, use:

• Unity: Unity IAP / Unity Gaming Services IAP or platform-specific APIs.
• Godot: Third-party plugins or platform SDKs.
• Unreal: Online Subsystem + platform commerce APIs.

At a high level, every IAP flow has:

1. Initiate purchase from your game (offer ID, product ID).
2. Process result (success, cancelled, failed).
3. Grant entitlements (currencies, items, cosmetics).
4. Record analytics.

Keep all product IDs together in one config or enum, not scattered through code.

Mock Flow for Design & Testing

If you are still early or targeting PC builds first, start with a mock:

if player clicks "Buy Starter Pack":
    show confirmation dialog
    if confirmed:
        grant items immediately
        record a "simulated_purchase" event for analytics

You can later replace the “grant items” and “simulated” event with real IAP callbacks.

Step 4 – Connect Offers to Your Economy and Inventory

For each offer you chose:

1. Define the exact contents in code or data:
   • Currencies, items, cosmetics, boosts.
2. Implement a grant function:

grant_starter_pack(player):
    add 1,000 soft currency
    add 1 cosmetic skin
    add 1 boost item

3. Call that function only when:
   • The store or mock layer confirms a successful purchase.

Make sure:

• All grants go through a single code path per offer (easier to audit later).
• You never grant items for failed or cancelled transactions.

Step 5 – Add Basic Analytics Events

Even for test builds, emit events when:

• The store is opened.
• An offer is viewed (optional).
• A purchase is initiated.
• A purchase is completed (or fails).

Example event fields:

• player_id (or anonymous session ID).
• offer_id (matches your internal offer list from Lesson 3).
• price_tier (low/mid/high).
• currency (USD, EUR, etc. when known).
• entry_point (for example, “results_screen”, “main_menu”).

You can send these to:

• Unity Analytics, GameAnalytics, Firebase, or your own backend.
• A simple log system in early prototypes if you do not have analytics yet.

The important part is consistency: the fields should match what you plan to analyze in later lessons.

Step 6 – Test the Flow End-to-End

Create a short checklist and run through it on a real build (not just the editor if possible):

• [ ] I can open the store from the chosen entry point.
• [ ] All visible offers show correct names and prices.
• [ ] Clicking an offer:
  • [ ] Shows the right confirmation or native purchase UI.
  • [ ] Grants the correct contents on success.
  • [ ] Does not grant anything on cancel/failure.
• [ ] Analytics events fire with the expected fields.

Test:

• A fresh user profile (no previous purchases).
• A profile that has already bought one of your offers (entitlement should not break).

Common Mistakes to Avoid

• Hiding the store in menus that players almost never see.
• Letting test or debug purchases grant more items than the real offers.
• Forgetting to handle network failures or store unavailability gracefully.
• Shipping a build where analytics events are inconsistent or missing key fields.
• Making your first store version too complex (dozens of offers, tabs, currencies).

Your first implementation should feel boringly correct: a few offers, a clear flow, and data you can trust.

Quick Checklist

Before you move on, make sure you have:

• [ ] One store entry point in your loop implemented in your UI.
• [ ] A simple store screen with 1–3 offers wired to buttons.
• [ ] A mock or real IAP flow that grants the right entitlements on success.
• [ ] Basic analytics events for store open, purchase start, and purchase completion.
• [ ] A short doc or comment block listing offer IDs and what they grant.

In the next lesson you will focus on analytics and live iteration: turning your early store data into decisions about which offers to keep, tweak, or remove entirely.