An Erlang implementation of the Cheap Ass board game Starbase Jeff
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.

An implementation of the Cheap Ass Game: Starbase Jeff

This is a project of love, and I claim no copyright over the original game or its bits.


  • A few basic record and macro definitions
  • Create a new, sorted deck of cards
  • Really simple testing harness
  • Randomized deck
  • Game and session record constructors
  • Started text-based interface for getting player count
  • Markdown version of this README
  • Text display hand
  • Board structure and table set


  • Nearly everything
  • Game loop
  • Constructors for other records
  • Text interface to playing a game
  • Text display game state
  • Text display player state
  • A way to use a file as input to the text interface for testing
  • Design turn structure
  • Execute a turn
  • Legal card placement test
  • Legal sabotage test
  • Payment route indication
  • Payment route selection
  • Overall game play structure and timeline
  • Game end, clean-up and start next game
  • Non text-based interface
  • Simple AI (random card, random placement)
  • Smart AI
  • AIs with different playstyles
  • Advanced Jeff capsule rules
  • Player database and dbi
  • Proper Erlang documentation for modules, methods, data types, etc

Getting Started with the Erlang Shell

    ok = sbjeff_test:unit_test().

    % create some objects in the shell
    Deck = sbjeff_cards:shuffled_deck().
    Player = sbjeff_player:new("Player_Name").
    % attempt to play a game

Development Process

  • When creating a new module:
    1. add the new module name to the modules list in ebin/
    2. create a matching _test module in the test folder with a unit_test method that returns ok if successful
    3. add another module line to the sbjeff_test:unit_test method
    4. make sure ok = sbjeff_test:unit_test(). before pushing to master
  • When adding new methods to a current module:
    1. Add at least one simple test to that module's _test:unit_test() method
  • When fixing bugs:
    1. If possible, cover the bug with a new unit_test
  • Where possible, use tagged data objects as returns to methods that will be used outside of that module
  • Keep documentation up to date