Moroccan Tycoon
Business strategy game
PlayTad
A PlayTad strategy game where business concepts become decisions you can make, consequences you can inspect, and plans you can change.
Real gameplay captured in my local browser and composed for this case study. Atlas Systems and its people belong to an illustrative game session; the balances shown are fictional game values.
01 / The idea
Every decision spends something.
I built Moroccan Tycoon for PlayTad around a question I find interesting: what does a business idea mean once someone has to act on it? Pricing, cash flow, staffing, product scope, and ownership all affect one another. I wanted those relationships to be the game.
For me, understanding a concept well enough to build it means defining what changes, what stays limited, and what the player gives up. A price slider needs customers who react to it. A delivery promise needs people with finite time. A profitable sale needs a separate answer to the question: when does the cash arrive?
My contribution
Game design and development for PlayTad: translating business concepts into simulation rules, player decisions, and a browser interface that explains their consequences.
Built with
- Rust
- Leptos
- WebAssembly
- IndexedDB
- CSS / SVG
02 / The process
How a month plays.
Start small. Choose a direction.
The player begins as an individual with savings, living costs, and no company or shares. Small projects can build capital before founding a business. Food, Logistics, Tourism, and Digital offer different operating conditions. Personal savings and company cash stay separate after formation.
Make a plan. Commit resources.
Set prices and staffing, choose a supplier strategy, shape products, and negotiate with customers. Review screens show the immediate cash commitment and a forecast under current conditions. Time waits for the player: opening a report or comparing a plan does not advance the simulation.
Advance. Inspect. Adjust.
Advancing the month runs operations, pays recurring costs, progresses work, and produces reports and conversations. The player reviews sales, receipts, delivery promises, and team proposals before deciding what to change. Market domination and unicorn scenarios give the journey a goal; Sandbox keeps the same resource constraints without a victory deadline.
03 / Concepts in play
From an idea to a rule.
Six relationships I translated into player decisions. Each example describes an implemented game rule.
Demand, margin, and capacity
Price meets a finite market.
I made companies compete for a limited pool of customers. Relative price, quality, marketing, reach, and competitors affect sales. Staffing and equipment limit what can be produced; products divide that capacity, and signed growth contracts reserve capacity before open-market sales. Lowering a price can attract demand while reducing the amount earned per sale.
In the game
In the captured playthrough, the team sees spare capacity and suggests a customer contract. Buying more equipment would leave more equipment idle. The decision is whether to pay the preparation fee for committed demand, rather than expand without a sales reason.
Profit, receivables, and working capital
Revenue is not money in the bank.
Customer deliveries generate draft invoices. Issuing a correct invoice and waiting through the agreed payment terms are separate steps from making the sale. Payroll and other costs still consume cash. Product contribution also excludes shared salaries and overhead, so a good-looking product figure is only part of the company picture.
In the game
A customer on 60-day terms can leave the company funding work before payment arrives. A wrong quantity or price can trigger a dispute and delay collection further. Matching the eventual bank receipt documents cash already received; it cannot create a second payment.
Audience fit, scope, and quality
A product needs a customer, not every feature.
The product builder links an audience to its priorities. Matching those needs improves fit; extra features add build work, cost, and ongoing inputs. Development pace trades speed against quality, and prototype choices let the player spend time and money on a customer pilot or reliability. Quality then affects recurring support costs.
In the game
Independent retailers prioritise Inventory and Invoicing in the software blueprint. Adding HR and Analytics does not automatically make that product a better fit. The player must also cover the blueprint’s specialist requirements; the capture makes the missing QA role visible beside the scope.
Opportunity cost and resource allocation
A promise spends someone’s time.
Customer requests become accepted roadmap commitments with deadlines and, where negotiated, discounts. A wider release takes more work than a focused customer solution. Named staff share one finite work budget across updates. Development, production, and customer care also compete for attention, so a sale can create an obligation the team cannot comfortably deliver.
In the game
When the same people support two updates, prioritising one weights their time 2:1. It does not double their output. Leaving an accepted update unstaffed produces no progress while its deadline keeps moving closer. The delivery preview uses the same allocator as month-end.
Debt, dilution, and control
Capital has a price beyond the cash.
Borrowing depends on equipment assets and a trading profit history, with repayments becoming a recurring commitment. Raising equity adds company cash by issuing new shares, reducing existing ownership percentages. Direct management requires a strict majority; minority owners work through proposals and votes. Dividends are constrained by earned profit, cash reserves, and debt obligations.
In the game
Issuing shares can finance growth and change who controls the next decision. A loan can improve the bank balance without creating profit to distribute. I connected these rules so financing cannot be treated as a free reward disconnected from the rest of the business.
Internal control and accountability
Delegation still needs evidence.
Accounting work connects invoices, expense classifications, receipts, and period closing. Bank inspection compares the payer, reference, and amount; uncertain evidence can be held for clarification. Department leads perform the same underlying actions as the founder, with named history. Delegating a task changes who does it, while keeping its effects reviewable.
In the game
An ambiguous transfer can be held until supporting proof arrives. Approving it against the wrong invoice creates an exception that can be reopened, rather than silently rewriting the source records. A manager’s finance summary can be checked against the ledger before the owner accepts the review.
04 / The result
The concepts have to work together.
The result is a playable local game where I can follow a decision across departments: scope affects staffing, staffing affects delivery, delivery affects invoicing, and collection affects the next investment. That connection is the work I wanted to demonstrate. The simulation is written in Rust, with integer monetary amounts and commands validated before they are committed. Leptos brings the rules into the browser through WebAssembly, and IndexedDB keeps the journey local.
- A deterministic simulation with a shared, finite economy
- Product development, customer promises, and accountable teams
- Local saves, English and French interfaces, and responsive layouts
Implemented in this build
The systems described above are present in the current code and playable interface, including product roadmaps, customer terms, purchasing documents, accounting, and tax mechanics. Automated simulation checks cover their rules. The screenshots come from a fresh local game session, not a business dashboard or an audience-performance report.
Planned, and still to validate
Supplier-contract bargaining and moving the simulation into a dedicated worker remain planned extensions. Multiplayer and cloud saves are not part of this build. The economy is a deliberately simplified fictional model; cities provide a setting rather than distinct regional markets. Balance and learning outcomes still need human playtesting. I am not presenting its rules as a forecast of a real business or as regulatory guidance.