Part 1: Teaching Kids to Invest — Why We Chose a Game

The Problem Nobody Solved

In April 2022, Japan made a landmark decision: financial education became a mandatory part of the high school curriculum. For the first time, Japanese students would formally learn about investing, compound interest, and asset management.

There was just one problem. Most Japanese adults do not understand investing themselves. Surveys consistently show that over 70% of Japanese households keep their savings in bank deposits earning essentially zero interest. How do you teach children something their parents never learned?

I had been thinking about this question since 2015 — years before the government mandate. As a business school graduate turned engineer, I saw the gap between financial literacy and the tools available to teach it. Textbooks were dry. Apps were built for adults. Nothing spoke to a seven-year-old.

What if the answer was a game?


The Sugoroku Concept (2015-2017)

In Japan, sugoroku is a beloved board game format — similar to Western games like Monopoly, but with a long cultural history dating back centuries. The concept is simple: roll dice, move forward, encounter events on each space.

I realized sugoroku was the perfect vehicle for teaching investment concepts:

  • Dice rolls mirror market uncertainty — you cannot control what happens next
  • Board spaces can represent real economic events from Japanese history
  • Buy/sell decisions teach the fundamental mechanics of investing
  • Portfolio tracking introduces the concept of diversification naturally

The initial design was ambitious. Players would start with 1,000,000 yen in virtual cash, traverse a board spanning decades of Japanese economic history (1980-2020), and make investment decisions as real historical events unfolded around them. Along the way, they would encounter the bubble economy, the lost decade, the Lehman shock, and the COVID crash — learning through experience rather than lectures.

I spent the 2015-2017 period designing the rules, creating character icons, and mapping out which historical events would appear on which spaces. The board had 40 spaces covering nine different event types:

Space TypeFrequencyPurpose
News30%Historical events that shift the economy
Dividend15%Passive income from held stocks
Crash10%Market-wide downturns
Boom10%Market-wide rallies
Bankruptcy5%Individual stock goes to zero
IPO10%New stocks become available
Bonus10%Windfall income events
Tax5%Mandatory expenses
Chance5%Random micro-events

The design looked solid on paper. But paper is not software.


The 2024 HTML5 Prototype Sprint

Fast forward to 2024. I finally had the time and skills to build a digital version. What followed was a rapid iteration through four distinct prototypes, each teaching me something critical about what this game needed.

Prototype 1: Kamishibai (Canvas + Buttons)

The first attempt was the simplest possible thing: a Canvas-based slideshow (kamishibai-style) with button navigation. The idea was to test whether the storytelling flow worked — could players follow a narrative while making investment decisions?

// The very first prototype — Canvas text + button navigation
document.addEventListener('DOMContentLoaded', function() {
    const canvas = document.getElementById('gameCanvas');
    const ctx = canvas.getContext('2d');
    let currentPage = 1;

    function drawPage() {
        ctx.clearRect(0, 0, canvas.width, canvas.height);
        buttonManager.clearButtons();

        switch(currentPage) {
            case 2:
                drawText("Once upon a time...", 100, 200);
                buttonManager.addButton("Next", 350, 400, 100, 50)
                    .action = () => { currentPage = 3; drawPage(); };
                break;
            // ...more pages
        }
        buttonManager.drawButtons(ctx);
    }
    drawPage();
});

This prototype confirmed the basic flow but exposed a fundamental limitation: vanilla Canvas with hand-rolled button management was painfully brittle. Every UI element required manual hit-testing, manual rendering, and manual state management. For a game with dozens of interactive panels, this approach would not scale.

Prototype 2: Counter Game

The second attempt stripped away the narrative entirely and focused purely on the numbers. A simple counter game where players could buy and sell assets and watch their portfolio value change. This validated the core investment mechanic but lacked any engagement — it felt like a spreadsheet, not a game.

Prototype 3: News Site (Scene Management)

The third prototype was the most architecturally interesting. Inspired by Phaser.js scene management, I built a class-based system for managing game screens:

class Scene {
    constructor(name) {
        this.name = name;
    }
    draw(ctx) {
        ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
        ctx.fillStyle = 'black';
        ctx.font = '24px Arial';
        ctx.fillText(`This is the ${this.name}`, 50, 50);
    }
}

class Game {
    constructor(canvas) {
        this.canvas = canvas;
        this.ctx = canvas.getContext('2d');
        this.scenes = {
            menu: new Scene('Menu'),
            game: new Scene('Game'),
            end: new Scene('End Screen')
        };
        this.currentScene = 'menu';
    }

    switchScene(sceneName) {
        if (this.scenes[sceneName]) {
            this.currentScene = sceneName;
            this.scenes[sceneName].draw(this.ctx);
        }
    }
}

This was progress — proper scene management meant I could separate the menu, game board, trading panel, and results screen cleanly. But I was essentially re-inventing a game framework from scratch. Every feature (animations, tweens, input handling, asset loading) would need to be built by hand.

Prototype 4: Simple HTML (Semantic UI Modals)

The fourth attempt swung to the opposite extreme — pure HTML with Semantic UI modals for all game interactions. No Canvas at all. This made the UI development faster but the game felt lifeless. There were no animations, no visual feedback when stocks moved, no sense of progression across the board.


What the Prototypes Taught Me

Four prototypes, four dead ends — but not four failures. Each one narrowed the solution space:

  1. Kamishibai proved that narrative-driven gameplay worked for the target audience
  2. Counter Game proved that the investment mechanics were sound
  3. News Site proved that scene-based architecture was the right pattern
  4. Simple HTML proved that the game needed proper animations and visual polish
The final MarketQuest — from prototypes to production

The conclusion was clear: I needed a real game engine for rendering and animation (Phaser 3), combined with a modern web framework for the surrounding UI (Next.js), and the game logic itself needed to be framework-agnostic so it could be tested and reused independently.

That architecture — a clean separation between game-core logic, Phaser rendering, and Next.js UI — became the foundation of the production system.


Why This Matters

Teaching children about investing is not just a technical challenge. It is a design challenge rooted in empathy. A seven-year-old cannot read a stock chart. They do not know what GDP means. But they understand rolling dice, they understand that some events are good and some are bad, and they understand the thrill of watching their score go up.

The sugoroku format bridges that gap. By wrapping real economic history in game mechanics, players absorb concepts like diversification, risk tolerance, and market cycles without ever reading a textbook.

In Part 2, I will dive deep into how I built the data foundation that makes this possible — a Python pipeline that transforms 70 years of Japanese economic history into game-ready event data with realistic stock price simulations.


Next: Part 2: Recreating Economic Cycles with Real Japanese News

Share this article

Related Posts