Start here — the professional bar

What the module contains at this checkpoint: Docs + course map; mindset and bar only

Why this lecture exists

This is a professional Odoo development lesson. The Monopoly game is the vehicle so you
already know the domain. The real product is your ability to design models, views, wizards,
security, tests, and shippable modules — the same skills required on client ERP work.

Thesis of the course

Course thesis

Companies must stop letting unproven developers learn on production ERP systems.
Monopoly Tycoon is the complexity bar: if you can design, secure, test, and ship
this game engine on Odoo, you are ready for professional work.

Brands: OdooClass.com · FirstClassGameStudios.com

What you are building overall

What you will build

A backend-first Monopoly engine on Odoo:

1. Board and spaces as data
2. Players, money, ownership
3. Game state machine + wizards (roll, buy, end turn)
4. Rules engine with tests
5. API surface for OWL / Godot / Unity clients later

You will play full games from Odoo form views without OWL.

Learning objectives

• Explain what this checkpoint adds to the Monopoly engine in plain English
• Connect the idea to a real Odoo framework concept (ORM, views, wizards, security, or tests)
• Complete the lab on a dev database using the progressive module for lecture/L00-start-here
• Leave with a mental model you can reuse on a business project (not only a game)

Architecture focus

At lecture/L00-start-here the student module should reflect: Docs + course map; mindset and bar only.

Treat the git branch / portal zip as a lab attachment. The lecture body teaches
why and how — not meta “name the branch” busywork.

Teaching arc (spoken + written)

1. Inspiration / stakes — why professionals practice on a complex sandbox, not production.
2. Concept — the Odoo framework idea for this lecture.
3. Design — how we model it in the Monopoly engine.
4. Code walkthrough — what changed in this checkpoint (use git diff only as a lab tool).
5. Lab — install/upgrade, verify UI or tests, complete exercises.
6. Bridge — how this maps to real business apps (Sales orders, inventory, etc.).

Demo / lab steps

1. Work only on a development database — never a live company ERP.
2. Obtain code for lecture/L00-start-here (portal zip or git checkout when available).
3. Place addons/monopoly_tycoon on the addons path; Update Apps List; install/upgrade.
4. Confirm the app state matches: Docs + course map; mindset and bar only.
5. Complete the guided exercises in the masterclass transcript below.
6. Write a 3-bullet note: concept → code location → business analog.

Acceptance checks

• [ ] You can teach the concept of this lecture without looking at notes
• [ ] Your installed module matches the checkpoint description
• [ ] You did not practice irreversible changes on production company data
• [ ] You can name one real business scenario that uses the same pattern

Progressive code lab notes

Deep masterclass body (AAA source)

The following is the full teaching transcript for this topic (from the pre-rebuild
masterclass corpus, remapped into the progressive curriculum). Expand with diagrams and
slides via masterclass_builder / video_builder — do not ship scaffold-only HTML.

01 · Welcome to Odoo Monopoly Tycoon — Masterclass Transcript

Masterclass Transcript — Welcome to Odoo Monopoly Tycoon

Odoo Monopoly Tycoon · Lecture 01 · ~18 min
An orientation to the whole course: what Odoo is, why we teach it by building a game, and exactly what you need on your machine before we write a single line of code. Assumes you can read a simple Python function and nothing more.

Welcome. I'm really glad you're here, because this course does something a little unusual, and I think by the end of these eighteen minutes you'll see why it works so well.

Here's my promise to you for the whole course, and I'll start honoring it right now: every time I use a word you might not know, I'll define it in the same breath. No jargon left sitting on the table. If I say "ORM" or "recordset" or "many-to-one," I owe you a plain-English definition, and I'll pay that debt every time. That's the deal.

So let me tell you what today is. Today is not code. Today is the map. By the end of this lecture you'll be able to answer five concrete questions: What actually is Odoo, underneath all the marketing? Why are we going to learn it by building a Monopoly game instead of, say, a boring to-do list? What exactly are we building over the next six sections? What do you need installed on your computer before Lecture Two? And what habits will make this course stick versus slide right off you? Five questions. Let's earn all five.

What Odoo actually is

Let me strip away the buzzwords. Odoo is an open-source business application framework. Let me unpack that phrase word by word, because each word matters.

"Open-source" means the code is free and public — you can read it, run it, and modify it without paying a license. We're going to use the free Community edition for this whole course.

"Business application" means it's built to run the operations of a company — selling things, tracking inventory, sending invoices.

And "framework" — this is the important one — means it's not just a finished product you use. It's a foundation you build on top of. Most people meet Odoo as a suite of ready-made apps: Sales, Inventory, Accounting, HR, eCommerce. They click around in those apps like any other software. But underneath every one of those apps sits a single, consistent development toolkit. And that toolkit — that framework — is what you're going to learn to program.

Here's the mental model I want you to hold. Think of Odoo like a set of LEGO bricks that already snap together a certain way. Sales, Inventory, Accounting — those are pre-built LEGO models someone already assembled. But you have the same bricks. You can build your own model with them. That's what we're doing.

Now, three pieces of technology do almost all the work, and you'll touch each one constantly, so let me name them.

[on screen: show the three-layer technology table — Data/logic, Interface, Storage]

The first layer is data and logic, and you write it in Python using something called the Odoo ORM. Second layer, the interface — the screens people click — and you write those in XML, a tag-based markup language, describing forms and lists and buttons. Third layer is storage, the actual database, which is PostgreSQL, a free industrial-strength database. And here's the beautiful part: for that third layer, you write nothing. Odoo generates the database for you.

That word ORM is the single most important idea in this entire course, so slow down with me here. ORM stands for Object-Relational Mapper. Let me define it by what it does. You describe your data as ordinary Python classes — just classes, with some attributes. And the ORM "maps" those Python objects onto relational database tables. It automatically creates the tables, the columns, and all four basic operations you'd ever want on data — create, read, update, delete, which developers call CRUD. It even hands you a basic user interface for free.

[pause]

Let me say that again because it's the thing that surprises almost everyone coming from other programming: you almost never write SQL. SQL is the traditional language for talking to databases directly. In Odoo, you describe your data in Python and the framework writes the database code for you. Learn the ORM well and you've learned about seventy percent of Odoo development. Everything else is variations on a theme. So if you remember one phrase from today, make it this one: the ORM turns Python classes into database tables so you don't have to.

Why we learn Odoo through a game

Now, here's the question I get every time: "A Monopoly game? Isn't that a toy? Shouldn't I be building real business software?"

Let me make you feel the answer. Imagine I taught you Odoo by building an inventory system. To follow along, you'd have to learn two hard things at once: the Odoo framework, and the rules of warehouse management — safety stock, lead times, replenishment. The domain fights you while you're trying to learn the tool.

Now imagine Monopoly. You already know the rules. You've known them since you were eight. So all of your brainpower goes to the framework, and none of it gets burned learning the domain. That's the trick. We picked something you already understand so the only new thing is Odoo itself.

But here's what makes it more than a trick — and this is the insight worth writing down. Monopoly happens to exercise nearly every core concept in professional Odoo development. Let me show you the one-to-one mapping.

[on screen: show the "Why learn through a game" concepts — relationships, computed values, state, interaction]

Relationships. A game has many players. A player owns many properties. A property belongs to one color group. That right there is the exact modeling you do in any real app: an order has many lines; a line points to one product. Same shapes.

Computed values and constraints. A player's net worth is cash plus property value — that's a computed field, a value Odoo calculates automatically instead of storing directly. A player can't have negative cash — that's a constraint, a rule the database refuses to break. These are the bread and butter of real business logic.

State transitions. A turn moves through rolling, then moving, then resolving, then ending. Business apps live on this. A sales order goes draft, then confirmed, then done. Same pattern.

User interaction. Rolling dice, buying a property, paying rent — those are button clicks that run Python methods. Structurally identical to clicking "Confirm Order" in the Sales app.

Let me drive one of these all the way home. "Pay rent" in Monopoly and "Register a payment" in Accounting are the same operation. Watch: deduct an amount from one balance, add it to another balance, record that a transaction happened, and refuse the whole thing if there aren't enough funds. That's rent. That's also an invoice payment. When you can build the game, you can build the invoice. The game is not the point — it's the disguise. Underneath, you're learning real Odoo.

What you're going to build

So let's get concrete about the destination. You're going to build a custom module. Let me define that: a module is a self-contained folder of Python and XML files that Odoo installs exactly like one of its official apps. Yours will start as an empty folder and grow into a playable game.

By the last section, a user will be able to start a game, add players, take turns, buy and mortgage property, collect rent, and declare a winner. To get there, you'll grow four main models. Remember, a model is one of those Python classes that becomes a database table.

[on screen: show the four-model data model table — game, player, property, turn]

monopoly.game represents one playthrough, and it has many players. monopoly.player is a person in the game — it belongs to one game and owns many properties. monopoly.property is a board square you can own — it belongs to a color group and is optionally owned by a player. And monopoly.turn is a single dice roll and its outcome, belonging to a player and a game.

Now I want to show you the very first model you'll write, because I want the destination to feel reachable, not abstract. This is the seed of the entire game.

# A minimal Odoo model — the starting point of the whole game
from odoo import models, fields

class MonopolyGame(models.Model):
 _name = 'monopoly.game'
 _description = 'Monopoly Game Instance'

 name = fields.Char(string='Game Name', required=True)
 player_ids = fields.One2many(
 'monopoly.player', 'game_id', string='Players')

Let me trace this line by line, like a debugger, because every single line is teaching you a convention you'll use forever.

[on screen, line by line:]

Line one, from odoo import models, fields — we're importing two toolkits from Odoo. models gives us the base class our class will inherit from. fields gives us the field types, like text and numbers.

class MonopolyGame(models.Model): — we define a Python class, and by inheriting from models.Model, we tell Odoo "this is a database-backed model, please wire it up." That inheritance is what triggers all the ORM magic.

_name = 'monopoly.game' — this is the model's technical identity. And here's the mechanical detail: Odoo takes that name, monopoly.game, and creates a database table by replacing the dot with an underscore. So the table becomes monopoly_game. You never create that table yourself — the ORM does it the moment you install the module.

_description is just a human-readable label. Odoo nags you if you leave it out, so we include it.

Now the fields. name = fields.Char(...) — Char means a short text field, a single line of characters. required=True means the database will refuse to save a game with no name. That's a constraint, enforced for you.

And the last one — this is the star. player_ids = fields.One2many('monopoly.player', 'game_id', ...). A One2many is a "one-to-many" relationship: one game, many players. It's saying "go find all the monopoly.player records whose game_id field points back at me, and gather them into a collection here."

[pause]

Here's a question worth pausing on: why is that field named player_ids, with that _ids on the end? Because it's an Odoo naming convention, and it carries meaning. A field name ending in _ids — plural, with an s — is always a collection: one-to-many or many-to-many. A field name ending in _id, singular, is always a single link: many-to-one. So player_ids is many players; game_id on the player side is one game. Every Odoo module ever written follows this. Adopt it from day one and your code will read like everyone else's.

Now count the lines. Seven lines of actual code. And from those seven lines, Odoo gives you a working database table, a form to create games, and a list view to browse them — for free. That leverage is the whole reason the framework exists. You write the description; Odoo writes the plumbing.

The road we'll travel

Let me show you the route, because the course is sequenced on purpose and the order matters.

[on screen: show the six-section course roadmap table]

Section 1, where you are now — Introduction and Setup — ends with Odoo installed and running on your machine. Section 2, Module Fundamentals — you create and install your own module, structure, models, and fields. Section 3, Core Game Models — players, properties, and the relationships between them. Section 4, User Interface — the forms, lists, menus, and actions people actually click. Section 5, Game Logic — the methods, computed fields, and automation that roll dice, buy property, and charge rent. And Section 6, Test and Deploy — debugging, unit tests, and shipping a real installable module.

I want to be firm about one thing: don't skip ahead. Section 5's game logic assumes the models from Section 3 and the views from Section 4 already exist. This is like building a house — you can't hang the doors before the walls are up. Each section stands on the one before it.

What you need before Lecture Two

Let's get your machine ready, because the next lecture assumes it is. Good news first: you do not need to be an expert. Here's the honest list.

On skills, you need three small things. First, basic Python — you should recognize a class, a method, a variable, and a list. My litmus test: if def add(a, b): return a + b makes sense to you — a function named add that takes two things and returns their sum — you are ready. You do not need advanced Python. Second, a little comfort with a terminal, the text window where you type commands. You'll run a handful; nothing exotic. Third — and this is a relief — no SQL required. The ORM handles the database, remember?

On software, you need four things.

[on screen: show the required software table — Odoo, Python 3.10+, PostgreSQL 12+, code editor]

Odoo itself, the free Community edition, from source. Python 3.10 or newer, because that's what runs Odoo, and version 18 specifically requires 3.10 or above. PostgreSQL 12 or newer, the database — you install it once and basically forget it exists. And a code editor for writing Python and XML; VS Code or PyCharm both work great, pick whichever you like.

Section 1's later lectures walk through installing each of these step by step. But let me preview the command you'll live with, because I want it to be familiar before you type it.

# Start Odoo, pointed at a config file, on a chosen database
python3 odoo-bin -c odoo.conf -d monopoly_dev

# Then open your browser at:
# http://localhost:8069

Two flags there that you'll use constantly, so let me define them. -c odoo.conf points Odoo at a configuration file — a plain text file that holds your database login and the path to your custom module folder, so you don't retype all that every time. And -d monopoly_dev selects which database to use, here one named monopoly_dev. Then you open a browser to localhost:8069, which just means "this same computer, on Odoo's default port 8069" — a port being the numbered door on your machine that Odoo listens at.

Two more flags you'll meet soon: when you first add your module you'll append -i your_module to install it, and after you change your module you'll use -u your_module to update it.

And that leads to the single most common beginner frustration, so let me flag it hard before it bites you.

[on screen: show the "Common Pitfall" restart callout]

Here's the trap. You edit a Python file, you flip to your browser, you hit refresh — and nothing changes. You think you broke something. You didn't. Here's why: Odoo loads your module at startup, not on refresh. So after you change Python, you must restart Odoo. And after you change a model's fields or an XML view, you must restart with -u your_module, so Odoo rebuilds the database schema and reloads the views. Refreshing the browser alone does nothing. Let me say it twice, because it's that common: change Python, restart Odoo; change fields or views, restart with dash-u. Tattoo that on your brain and you'll skip the number-one "why isn't my change showing up" panic.

One last setup habit: on your very first login, turn on Developer Mode. It's under Settings, then Developer Tools, then "Activate the developer mode." It reveals the technical field names, the model names, and the tools to inspect and edit views — things you'll want in nearly every lesson. Turn it on now, leave it on all course.

How to actually make this stick

Let me leave you with the four habits that separate people who finish this course from people who watch it.

One: build alongside the videos, not after. Keep Odoo running in one terminal and your editor open right beside it. The fastest feedback loop in the world is: change code, restart with -u, refresh, observe. Live in that loop.

Two: type every example yourself. Don't copy-paste. The muscle memory of your own fingers writing _name, fields.Char, One2many is what converts watching into knowing. It feels slower. It's dramatically faster in the end.

Three: read the error, then fix the error. Things will break — that's not failure, that's Tuesday. And Odoo's error messages, called tracebacks, name the exact file, line, and model where it went wrong. The message almost always tells you precisely where to look. Debugging is a core skill we'll make explicit in Section 6, not a detour.

Four: don't try to build the perfect game in Section 3. We grow the module incrementally on purpose. Add the player model, get it working, verify it, then add properties. Building everything at once and debugging the whole tangle together is far, far harder than building one small, verified piece at a time. Commit your work to Git after each lesson so if something explodes, you step back one commit instead of guessing.

The whole lecture in seven sentences

Let me compress everything down to what you'd screenshot.

Odoo is an open-source framework where you program mainly two layers — Python models through the ORM, and XML views for screens — while PostgreSQL storage is generated for you. The ORM, the Object-Relational Mapper, turns your Python classes into database tables and gives you create-read-update-delete for free, which is why you almost never write SQL. We learn all of this by building Monopoly because the game exercises every core concept — relationships, computed fields, constraints, state, and button-driven logic — using rules you already know. You'll grow one custom module across six sections into a playable game with games, players, properties, and turns. Field names ending in _ids are collections and ones ending in _id are single links — a convention you adopt from day one. Before Lecture Two, install Python 3.10+, PostgreSQL, and the Odoo source, start Odoo, and enable Developer Mode. And remember the habit that saves you the most pain: restart after Python changes, and restart with -u your_module after model or view changes, or your edits stay invisible.

Discussion questions

1. Think of a real system you know — a library, a gym, a coffee shop. What would its three or four core models be, and which relationships between them are one-to-many versus many-to-one?
2. The lecture claims "pay rent" and "register a payment" are structurally the same operation. Can you name a second pair of actions — one from a game, one from business software — that share the same underlying steps?
3. Why does Odoo generate the database table from _name instead of asking you to write the SQL yourself? What could go wrong if two developers wrote the SQL by hand instead?
4. In the seed model, player_ids uses One2many and points back at a game_id field on the player. In your own words, where does the actual link between a game and a player physically live — on the game side or the player side?
5. You edit a model to add a new field, restart Odoo normally, and the field doesn't appear. Walk through what you forgot and exactly what command fixes it.
6. Which of the four "make it stick" habits do you personally find hardest, and what's one concrete thing you'll do this week to hold yourself to it?

Next lecture: We roll up our sleeves and set up your environment for real — installing Python, PostgreSQL, and the Odoo source, then starting Odoo and logging in for the first time.

Diagrams to produce (factory)

• Concept diagram for this lecture’s architecture focus
• Before/after model relationship sketch when models change
• Turn / money / ownership flow when rules engine lectures apply

Slide deck (factory)

Produce a branded PPTX aligned to the spoken arc (15–30 slides typical for 18–25 min).
Use OdooClass + FCGS design systems as appropriate.

YouTube cut (factory)

8–12 min thesis cut for funnel — never auto-publish to the paid course channel without review.