C-Robots, The Next Generation

  1. What's All This C-Robots Stuff?

    2. C-Robots is a game written by Tom Poindexter in 1985. It is a game where you, the player, write a program in C to control a robot in a big battile simulation. Up to four robots can fight against each other in a big square field with walls. Each robot can have a different program controlling it.

    The game is really fun, and went on to inspire a slough of imitations/followers. If you'd like to find out more about this kind of game, you can look at my UPA game web page . It has descriptions of all the games I know about, as well and links to other pages and zip files so that you can try the games yourself.

  2. What's the point?

    3. Well, that's a good question. There are lots of programming games out there, and they all have something to offer (well, opinions might be divided about that). What's missing in the Marketplace ? To answer this, I'd like to delineate the positives and negatives that I see of the various games that are currently available in the UPA genre of games.

    I guess I should first explain where my criteria come from in judging the UPA games that are currently available. Basically, I'm coming at this from my own experience, as well as that of a few other people. I base my decisions about what's a virtue and what's a detriment on my own confused opinions. If you disagree with any of them, I'd love to hear your input via email . I've had discussions with some people on this subject, but I'm always happy to hear everyone's opinion.

    Note: In the following table each game apart from C-Robots is listed with only the differences that it has from C-Robots, since C-Robots seems to be the progenitor of all of these games

    Game Advantages Disadvantages
    C-Robots
    • Uses a programming language (C) familiar to almost all programmers.
    • Has a simple, easy-to-learn API .
    • Has a very straightforward display .
    • Has a very straightworfard execution interface .
    • Will run at an acceptable speed on anything down to an 8086.
    • Portable between DOS, Win32 and UNIX, with adaptable screen-size on curses-compatible systems (e.g. UNIX).
    • The distributed executable will run on approximately 95% of computers in the world (any computer running DOS, Win9x, WinNT or Linux, and many UNIX flavors and even some Macs ). Since it doesn't directly access the hardware of the computer, it is also able to run on <100% compatibles from the early PC era.
    • The implementation of C that it uses is incomplete, making the use of arrays, pointers, strings, for-loops, postscript increment/decrement operators, and other features of the language, impossible to use.
    • The display is so crude that it is impossible to discern small details. The text-based visualization is unable to show features such as robot facing, small changes in location, and other minutiae.
    • The display is, well, kind of boring.
    • It is impossible to program directly in the interpreter's assembly language.
    • The only debugging feature (assembly-code readout and single-step assembly tracing with no display of the actual robots) is so obtuse as to be nearly unuseable.
    • The source code is not freely availabe
    • The distributed executable is for MS-DOS. This executable format is less than optimal or it is impossible to run for about 90% of the computers in the world.
    • There are no sound effects.
    P-Robots
    • Uses a relativly popular language (Pascal), mostly employed these days in educational settings.
    • Uses a more colorful display than C-Robots.
    • Allows team-play, with inter-robot communications and a host of other ally-related functions.
    • Has an optional IDE .
    • Has built-in geometric functions: distance and angle_to (it's debatable, though, from a game-design standpoint, whether these are good or bad features).
    • Robots have more defensive options: shields and cloaking devices (again, I'm not sure if these are good or bad features).
    • There is an option to use fuel, a feature meant to level the playing field, to make "smart" robots have more of a chance against "brute force" robots.
    • Allows different configurations for different robots, giving each robot a chance to have equipment suited to its particular strategy.
    • Comes with a tournament batch executor.
    • Pascal is, compared to C, rarely known among programmers. Most of the people who do know it don't use it regularly, having learned it early in their programming career only to abandon it for C, C++, or Java.
    • The interface is still rather crude, despite being in color rather than just black and white. Most of the complaints about C-Robot's interface still apply.
    • The game itsself has many options. These for the most part exclude robots from being generically written. They must be written for the specific options in play for the given executions of the game (obstacles, configurations, teams, etc.). While it is possible to write generic robots, the time lost in CPU cycles would be a disadvantage for any robot that actually did this.
    • Team play is difficult to coordinate. It's hard enough to concentrate on creating one robot. To think about programming two is almost mind-boggling, and, personally, the novelty wears off quickly. This could be aleviated, perhaps, with teams of programmers working on teams of robots, one programmer per team. Just try finding four Pascal programmers, though, to face off with each other, let alone having an actual tournament between many teams.
    • Only works on a PC. It was written in Turbo Pascal, which is very incompatible with other versions of Pascal.
    PC-Robots
    • The player can use any programming language he likes, as long as he can call x86 interupts from that language and can create an executable of his program. The game uses wizard-level DOS tricks to make all the robot programs run at the same time to compete against each other.
    • Has a more-detailed display, using the 640x480x16 VGA graphics mode.
    • Display looks hacked together. Not much attention was paid to making it look good -- a shame, since that graphics mode has a usually under-appreciated potential for looking gooood.
    • Only runs on a PC. The tricks used to make it work make porting impossible without completely rewriting the program using entirely different tricks apropriate to the platform being used.
    • The display gives very little information about the status of the robots during gameplay.
    Robocom
    • Uses a different game concept than any of the other games in this roundup. It seems to be sort of a half-way point between Corewar and the regular robot-oriented game. Most of the robot metaphor was abandoned, and the game becomes quite a bit more abstract. It's kind of refreshing.
    • Has some graphics. Not the highest quality or anything, but with the change to the non-robot theme, graphics seem to lose their import in my mind.
    • Has a rudimentary windowed interface. Refreshing after dealing with all those stark command-line programs.
    • Has very little documentation. I wasn't able to figure out what to do with the game upon cursory inspection . Even after looking at documentation and some of the sample programs, I was amazed at how confusing it was.
    • Uses a pseudo-assembly language for the control programs.
    • The user interface could use a lot of work in terms of clarity and useability.
    Intellibots
    • Has more-interesting graphics than most or all of the other games mentioned here.
    • Has a windowed user interface.
    • Has some sound effects.
    • The user interface is kind of weird and hard to figure out.
    • Uses a pseudo-assembly language for the control programs.
    • Despite having better graphics than other games, the graphics are still quite low quality. Jerky animation and buggy blitting are pervasive.
    Robot Battle
    RARS
    AT-Robots
    A-Robots
    Warbots
    RealTimeBattle
    Rova
    Binary Armageddon
    C++ Robots

  3. What Else Is There in Life, Anyway?

    4. So what's missing? What could be added to the programs currently available? The most conspiculously missing feature is a nice display/interface. None of these programs have impressive graphics or sound, two features which people have come to expect in modern gomputer games. Why should that expectation be any less for UPA games?

    What I find in going back to play any of these old games is that they are just kind of boring now. I'm jaded, I guess. I want to see flashy graphics and hear cool sound effects. This type of game has so much potential for nifty special effects, and it almost amazes me that no one has created one that takes advantage of the capabilities of a modern PC.

    The problem, as I see it, is that people who create this kind of game are almost universally geeks and nerds . When someone decides to make a UPA game, they plan a cool programming challenge, both for developer and player. They minimize the necessity of an interesting display.

    I think it's high time someone got beyond this attitude. This is the same attitude that until recently made Linux totally unaproachable by non-geeks, since it lacked UI elements so necessary for popular acceptance. What nerd wants to write a WYSIWYG word processor, when he can create a kernel module?

  4. The Solution

    5. My solution is to create a new program. I plan to combine all the best features of the existing UPA games, throw in some new enhancements, and roll them up into a new game. I will, with one or two other people execute this over two-and-a-half months, during Winter term, 2000.

If you would like to see the progress on this project, I have a web page devoted to tracking the development .

Fingerprint generated by visprint
This page is part of the Jone/Stone Information Repository
Last updated on September 26th, 1999
This page and its contents are copyright ©1999 by David Johnston