CodeCombat: A Multiplayer Game for Learning to Write Real Code

What CodeCombat is and who it is for

CodeCombat is described in the README as a multiplayer programming game for learning how to code. Players write actual code, not drag-and-drop blocks, to control characters through levels. The repository represents both a startup product and a community-driven open source project. The code runs on JavaScript on the client side and uses a development proxy architecture that separates the client from the backend. The target audience splits in two: learners who play the game on codecombat.com, and developers who want to contribute to the open source codebase. These two paths have different entry points. Players go directly to the website; contributors need to set up the full development environment described in the Archmage (coder) developer wiki linked from the README, which covers the dev setup guide, documentation, and contribution process in detail.

How the game teaches coding: writing real syntax from the start

The core design choice is that players type real code, not pseudocode. Python and JavaScript are supported, and the README lists Python specifically as a language context for players. Characters move, attack, and collect items based on the code the player submits for each level. This creates a direct feedback loop: broken syntax stops the character. That feedback is different from a tutorial that shows correct code and asks students to fill in blanks. The game's levels are the main learning artifact, but the README notes clearly that the levels on codecombat.com are not open source, as detailed in LICENSE-LEVELS.md. The open source repository contains the game engine, rendering, and platform code; the curriculum lives separately.

Setting up the development environment with Docker

The repository provides a Docker Compose configuration for local development. The proxy service builds from a Dockerfile under development/docker/ and maps port 7777 on the host to port 3000 in the container:

version: '3'
services:
  proxy:
    build:
      context: .
      dockerfile: ./development/docker/Dockerfile
    command: bash -c "npm install && npm run build && npm run proxy"
    volumes:
      - .:/coco
      - /coco/node_modules
    environment:
      DEV_CONTAINER: 1
    ports:
      - 7777:3000

The DEV_CONTAINER environment variable signals the application that it is running in a local container context. For non-Docker development, the Makefile provides the `make dev` target, which runs webpack in watch mode so that client code changes are reflected immediately. The full production build (Bower, Aether, and webpack) requires the NODE_OPTIONS flag set to allow 8192 MB of heap, as shown in the package.json build script.

The open source split: what is free and what is not

The licensing structure has three layers. The application code is MIT licensed, so it can be used and modified freely. The art assets and music are Creative Commons Attribution (CC-BY), which permits reuse with attribution. The levels that form the actual game curriculum on codecombat.com are not open source; this is documented explicitly in LICENSE-LEVELS.md. Contributing code requires signing the CodeCombat contributor license agreement at codecombat.com/cla. The README frames this as easy to complete. This split matters for anyone evaluating the repository as a starting point for a self-hosted educational game: the platform is there, but the content that makes the game educational is proprietary. Building custom levels requires working within the editor tooling, and the content pipeline for those levels is not documented in the README.

The partner API for SSO and progress tracking

The README documents a partner API that covers single sign-on, user management, and progress data. Access requires client credentials, so anyone integrating an existing platform needs to contact the CodeCombat team for credentials. API documentation is at api-docs.codecombat.com and there are SDKs at github.com/codecombat/codecombat-api. For the simplest integration case, the README points to a public endpoint: fetching https://codecombat.com/db/user/your-user-name-or-id returns user progress statistics. The README names Beeminder as a real integration using this endpoint to help users commit to a learning schedule. This lightweight path requires no client credentials and works for read-only progress data, making it accessible without a formal API agreement.

Limitations: build complexity and curriculum constraints

The build system is a constraint for contributors. The project uses Bower alongside npm, a combination that reflects the codebase's age. The webpack build requires the NODE_OPTIONS='--max-old-space-size=8192' flag for a full production build, indicating memory pressure during bundling. There are two separate product lines in the repository: CodeCombat and Ozaria, each with their own webpack configs and Makefile targets (make dev vs. make dev-ozaria, make proxy vs. make proxy-ozaria). A contributor working on one product needs to be aware that some scripts target the other. The repository's continuous integration configuration lives in .circleci/ and .travis.yml, suggesting the CI setup has accumulated multiple pipeline configurations over time. Internationalization tooling is present in the scripts/ directory: copy-i18n-tags.js rewrites locale files to match the en.js structure, and check-long-i18n.js flags translations that are suspiciously longer than the English originals. The Makefile exposes these as make copy-i18n and make check-i18n targets. There is also a ROT13 locale generator for debugging internationalization, which gives a sense of how thorough the i18n infrastructure is. The last push to the repository was on 2026-09-26.

CodeCombat versus Scratch: written code versus visual blocks

Scratch, developed by MIT, is a visual programming environment designed for younger learners. Players in Scratch drag and drop block-shaped instructions rather than typing code. This makes Scratch more accessible at very early ages but means learners do not encounter actual syntax. CodeCombat takes the opposite position: players type real Python or JavaScript from the beginning, and the game stops when the syntax is wrong. This makes CodeCombat more appropriate for learners who are ready to move to a text-based language. A learner who has exhausted what Scratch can teach and wants to start writing actual code has a clear use case for CodeCombat. A learner who has never programmed and finds syntax errors discouraging will likely have an easier time starting with a block-based environment first. The multiplayer aspect, mentioned in the README, means players can compete or collaborate with others rather than working in isolation, which changes the social dynamic of the learning experience compared to solo-drill platforms.

Editorial conclusion

CodeCombat suits a learner who wants to practice writing real code in Python or JavaScript through game mechanics rather than exercises, and who is comfortable with codecombat.com's level structure. Developers who want to contribute to the open source project should read the Archmage developer wiki first, sign the contributor license agreement at codecombat.com/cla, and verify that their environment meets the Node.js memory requirements before running a full webpack build.

Frequently asked questions

Official sources

1. codecombat/codecombat on GitHub
2. Issues
3. License: MIT
4. Project website
5. README