> Excellent! I have mono, but I'm not actually sure how to go about
> compiling anything that doesn't come with a neat Makefile.

There's a MonoDevelop solution included. You can either use MonoDevelop,
or if you use something else, it looks like "mdtool build" does a
complete build from the command line.

For simple stuff, like adding a source file, you might even be able to
edit the project files with a text editor.

> Okay, so from your list, here are the things that I will be trying to
> get done for my project::
>
> - Interrupts
> - Many weapons (just bullets and missiles implemented)
> - Still a couple of special operators and registers
> (history, channel, signal, for example)
> - Headless / command-line interface
>
> I don't particularly need a built-in:
>
> - Editor
> - Debugger
>
> but I'll want to edit robots in a text editor -- does one of the
> formats make this easy? I don't remember.

Not really, they both contain non-textual stuff. But it shouldn't be
hard to implement. You'll find the file formats in LibRoboWarX/FileFormats.

The RobotFile class in there is the in-memory representation of a
robot's data. (Not to confuse with LibRoboWarX/Arena/Robot, which
contains runtime state.)

The other classes simply open a file, create such a RobotFile instance
and fill it.

In fact, this might do it for reading a text file as a test:

================================================================================
using System;
using System.IO;

namespace LibRoboWarX
{
public static class SourceTestLoader
{
public static RobotFile read(String filename)
{
RobotFile result = new RobotFile();
StreamReader f = new StreamReader(filename);

// Induce the robot name from the filename
f.name = Path.GetFileNameWithoutExtension(filename);
// Read the source
f.code = so.ReadToEnd();
// Immediately compile for convenience
f.compile();

// Default hardware is rather minimal, see
LibRoboWarX/Arena/Robot.cs
// Perhaps set some useful values here for testing
f.hardware.hasMissiles = true; // These already work! Woo!

return f;
}
}
}
================================================================================

Come to think of it, a text only format would be nice. Maybe we can get
hardware settings from a comment block near the top of the file? In
YAML? Hmmm... :)

> Given these goals, can you estimate what's needed to get it done? Any
> general pointers as to where I (or whoever) would start?

Let's see.


Interrupts are stubbed out in places. Most notable is the
processInterrupts method in LibRoboWarX/VirtualMachine/Interpreter.cs.
This is called from LibRoboWarX/Arena/Robot.cs, and I believe that's the
correct position where RoboWar used to process interrupts as well.

You'll find that all (interrupt) registers subclass from the abstract
class LibRoboWarX/Arena/Register.cs and implement the
LibRoboWarX/Global/ITemplateRegister interface. (I'm not sure why I made
those separate.) The Register class has methods called fireInterrupt,
checkInterrupt and updateInterruptState.

I suppose checkInterrupt would be called from processInterrupts.

fireInterrupt would be called if checkInterrupt returned positive, but
it might be obsolete if all interrupts do is push to the stack and
change the PC.

updateInterruptState is a mystery even to me. Must've seemed like a good
idea at the time.

One thing I remember is that I didn't take into account the order in
which interrupts are fired yet.


Weapons are hopefully easy to implement. That was one of my original goals!

You'll find the Missile is probably the simplest example. Simply a
Register class that the compiler and virtual machine can use, and a
Projectile class to do your worst.


You can probably scrap the 'remaining operators' from your list. They're
things like: print, debug, snd, beep, icon and mrb(?). Things you
shouldn't care much about, especially for a headless and debuggerless
interface. For reference, they live in
LibRoboWarX/VirtualMachine/Operators.cs. There's some commented original
RoboWar C code in places that are still lacking.

The registers are more interesting. Especially the team communication
stuff like channel and signal. See LibRoboWarX/Arena/StockRegisters.cs
for those. I've included excerpts from the original RoboWar manual as
comments.


A headless interface also should not be difficult to get running
quickly. The bulk of the code in the current GUI frontends really only
touches the GUI. You should be able to figure that out.

I have not given the public interface of LibRoboWarX much thought yet.
But it works for getting a game going.


That's as much as I can ramble about without getting specific questions. ;)

-- Stéphan