CBOT

CBOT is the programming language built into Colobot, a real-time strategy game released by the Swiss studio EPSITEC SA in 2001 in which you do not command your robots - you program them. It is closely modeled on C++ and Java in structure and syntax, and it is a real language rather than a gesture at one: it has static types, classes, single inheritance, access modifiers, reference semantics, exceptions, arrays, file I/O and a mechanism for synchronizing methods across concurrently running programs.

What makes CBOT unusual is not any individual feature. It is the framing. A CBOT program is not a script that gets called; it is the mind of a machine standing in front of you. You write move(20); turn(90); and a grabber drives twenty meters across a red alien plain and pivots. You write a while loop with a radar() call in it and the same grabber starts hunting for titanium ore on its own. The feedback loop between a language construct and a visible physical consequence is about as tight as programming education has ever managed.

History and Origins

Colobot - the name contracts colonize with bots - was created by EPSITEC SA, a Swiss developer previously known for the Blupi series, and released in 2001 in English, French, German and Polish editions. Daniel Roux is credited alongside EPSITEC in the copyright headers that still sit at the top of every source file in the language’s implementation.

The premise is post-apocalyptic: Earth is doomed, and you are dispatched to find and prepare a new home. Across nine locations - Earth, the Moon and seven fictional planets - you build derricks, converters and research centers, and you defend them from indigenous life that objects to your presence. The strategy layer is competent but conventional. The programming layer is the reason anyone remembers the game.

EPSITEC clearly understood which half was valuable, because the language quickly outgrew the game. Between roughly 2003 and 2005 the studio released four CeeBot titles built on the same interpreter, each dropping the strategy game and keeping the curriculum: CeeBot-A as an expansion of Colobot’s exercises and challenges, CeeBot-Teen simplified for a younger audience, CeeBot3 as a program-to-paint course, and CeeBot4 as a college-level programming course.

The 2012 source release

Colobot’s second life came from Poland, where the game had an unusually devoted following. In early 2012 - Wikipedia dates the release to March, while archived source packages date the handover to PPC to February 19 - after a sustained effort by fans organized as PPC (Polish Portal of Colobot), EPSITEC agreed to release the source code under the GNU General Public License v3. The group - later rebranded as the International Colobot Community and TerranovaTeam - began work on Colobot: Gold Edition, replacing the original Windows-only DirectX-era engine with a portable one while leaving the language and the missions alone.

The Gold Edition has been developed in the open ever since. It remains formally in alpha - the current release is alpha 0.2.2, published December 23, 2024 - and the project site describes it as an enhanced version rather than a remake. According to the project’s own download page, builds are offered for 64-bit Windows, 64-bit Linux as an AppImage, and macOS.

Design Philosophy

Teach the real thing, not a simplification

The most consequential decision in CBOT’s design is what its authors declined to do. A game aimed at beginners could reasonably have offered a block language, or a flat list of commands, or a BASIC dialect. CBOT instead gives you Java’s type system, C’s syntax, and an object model with class, extends, super, this, private and protected - and expects a fifteen-year-old to cope.

The bet is that the difficulty is front-loaded and worth it: what a player learns transfers directly to C++, Java or C#, because it essentially is those languages with a smaller standard library. The Polish education ministry’s reported recommendation of the game as an aid for teaching algorithms and object-oriented programming is a reasonable verdict on whether the bet paid off.

The object model is literal

In most introductory OOP courses, “object” is an analogy you ask students to accept on faith. In CBOT, an object is a robot, and it is standing right there. The built-in object type is a genuine record of physical state:

1
2
3
4
5
6
7
8
9

int    object.category      // what kind of thing it is
point  object.position      // where it is (x, y, z)
float  object.orientation   // which way it faces, 0..360
float  object.energyLevel   // 0..1
float  object.shieldLevel   // 0..1
float  object.altitude      // height above ground
object object.energyCell    // the power cell it carries
object object.load          // what it is holding
bool   object.dead

To find out how much charge a bot has left, you cannot read energyLevel from the bot - the energy is in the cell, not the chassis - so you write energyCell.energyLevel. That is a modeling lesson delivered by the physics of the game world rather than by a lecture.

Every bot is a thread

Each robot in a mission runs its own CBOT program, and they run at the same time. This makes concurrency an ordinary, early experience rather than an advanced topic, and CBOT provides real tools for it: cross-bot function sharing via public, message passing via send() and receive() through an information exchange post, and mutual exclusion via synchronized.

Key Features

Types

The user-facing type vocabulary is deliberately small:

Internally the interpreter carries a wider enumeration - byte, short, char, long, double and boolean all appear in the C++ source - which the implementation’s own comments describe as modeled on Java’s types.

point has a constructor-style declaration and supports value comparison:

1
2
3
4
5
6
7
8

point a(10, 20, 30);
point b;
b.x = 10; b.y = 20; b.z = 30;
if ( a == b )  // true
{
}

point c(4, 7);  // z defaults to 0

The extern main function

Every CBOT program has exactly one entry point, marked with extern, and its name is what appears in the bot’s program list in the game UI:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

extern void object::Square()
{
    for ( int i = 0 ; i < 4 ; i++ )
    {
        Line(10);
    }
}

void object::Line(float dist)
{
    move(dist);
    turn(90);
}

The object:: qualifier is not decoration - these are methods on the built-in object class, which is why move() and turn() act on this bot without being passed a receiver, and why you may write this.orientation inside them.

Classes and inheritance

Classes in CBOT are always public - “they can be used by all bots in a mission” - and support fields with initializers, methods, single inheritance via extends, method overriding, super, and private/protected/public members that default to public:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

public class Parent
{
    void foo() { message("foo"); }
}

public class Child extends Parent
{
    void bar() { message("bar"); }
}

extern void object::Test()
{
    Child child();
    child.foo();  // "foo"
    child.bar();  // "bar"
}

Only public and protected members are inherited; private members remain reachable only indirectly, through inherited methods. Constructors and destructors are not inherited but may be overridden.

Reference semantics

Classes and arrays are handled by reference, exactly as in Java, and the documentation teaches the distinction with a suitcase-and-carrier metaphor: an instance is the suitcase, a variable is a carrier, several carriers can hold the same suitcase, and a null reference is a carrier with nothing to carry.

1
2
3
4
5

MyClass item1();   // new instance, referenced by item1
MyClass item2;     // null reference
item2 = item1;     // both now reference the same instance
item1.a = 12;
message(item2.a);  // displays 12

The trailing () matters and catches everyone once: without it you have declared a reference, not created an object.

Arrays

Arrays are N-dimensional, each dimension capped at 9999 elements, and they grow on demand. Declaring one creates only a null reference; the elements come into existence when you first write to them.

1
2
3
4

int    [] a;      // an array of int
int    a[12];     // bounded to 12 elements
float  xy[][];    // two-dimensional
int    numbers[] = { 10, 20, 30 };

The documentation is candid about a sharp edge: writing past a declared bound is not caught at compile time even when the error is obvious, and stops the program at runtime instead.

synchronized, and shared code between bots

public on a function makes it callable from other bots in the same mission - with the memorable consequence that if the bot hosting a public function is destroyed, every bot calling it halts with an error. Shared code has a physical location that can be blown up.

synchronized on a class method guarantees it is never executed by more than one bot at a time, and the documentation motivates it with a textbook race:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

class blocking
{
    static int nb = 33;
    synchronized int inc()
    {
        int val = nb;
        wait(2);      // wait 2 seconds
        nb = nb + 1;
        return val;
    }
}

Without synchronized, two bots entering inc() together both read 33. With it, the second bot is held at the door until the first returns and reliably sees 34. The lock is held across the entire set of synchronized methods on the class, not just the one being executed - a genuine mutual-exclusion primitive, taught with two robots visibly waiting on each other.

Categories as first-class constants

Every kind of thing in the game has a named constant: TitaniumOre, Derrick, Converter, PowerCell, BotFactory, AlienNest, NuclearPlant. They are highlighted in the editor when spelled correctly, which makes the editor itself a spell-checker for the game world.

The standard library

CBOT’s library is where the language stops resembling Java. Alongside conventional facilities - strlen, strmid, strfind, strval, sqrt, pow, atan2, rand, floor, round, sizeof, and open/close/readln/writeln/eof on the file type - sit the instructions that make a robot do things:

The presence of wait(5) as an ordinary blocking call is a quiet piece of engineering: the interpreter suspends and resumes program state across game frames, which means the execution state of every running program is something the engine can pause, save and restore.

Evolution

CBOT is notable for how little it has changed. The language shipped in 2001 essentially complete, and neither the CeeBot repackagings nor fourteen years of open-source maintenance have added significant new constructs. What has changed is everything around it:

The interpreter’s modernization inside the Gold Edition tree is the real work of the last decade: pulling CBot into its own namespace, reducing its interface to one public header that the rest of the game includes, and building out a unit test suite. The result is that the language can now be read, and in principle reused, independently of the game it was written for.

Current Relevance

CBOT is dormant. It is maintained, not developed. Nobody is proposing new syntax, there is no package ecosystem, and the only way to run a CBOT program is to install Colobot or one of the CeeBot titles. The most recent release of its host, alpha 0.2.2, dates from December 2024.

That said, it is very much alive as a thing you can actually use today. The Gold Edition is free, GPL-licensed, builds on all three major desktop platforms, and the language documentation - the same in-game help files that shipped in 2001, now maintained as plain text in the colobot-data repository - is complete and unusually well written. As an introduction to typed object-oriented programming for a teenager, it holds up better than most things designed since.

Why It Matters

CBOT’s significance is not linguistic. Nothing in it is novel; it is a careful subset of Java with C syntax and a robot API. Its significance is in what it demonstrated about where a language lives.

Three things are worth taking from it:

1. It refused to condescend. Given a beginner audience, CBOT shipped static types, inheritance, access modifiers, reference semantics and mutual-exclusion primitives - and was then, by most accounts, recommended by a national education ministry as an aid for teaching exactly those things. The simplification most educational languages perform turns out not to have been necessary.
2. It made abstractions physical. An object with a position and an energyLevel and a move() method is not a metaphor when it is a robot driving across a screen. Concurrency is not a diagram when two grabbers deadlock in front of you over the same piece of ore.
3. It outlived its game. A commercial product from 2001 that would otherwise be a dead Windows executable is instead a maintained, portable, GPL-licensed program with an approachable interpreter you can read - because a group of Polish fans spent years asking, and a Swiss studio eventually said yes. That is a rare and worth-remembering outcome for software of that vintage.