In message (2983), Robert Plamondon writes:
>I spent several months in a misguided attempt to create a commercial RPG aid.
>The project had two Achilles' heels (Achilles had problems with just one!):
>data entry and special actions.
>The data-entry problem was the worst. Even after assigning default actions
>to everything, the "who-hits-whom" and "who-uses-what-weapon" and "how far
>away is each person from each other person" problems make melee combat a
>complete nightmare. The GM spends all his time pounding away at the keyboard.
Our AD&D group from the early 80's used a TRS-80 to do this. It provided the
basic DICE rolling, expericence caluclations, tracking the health of the
monsters, including regineration. Later versions even handled combat rolls of
the monsters attacking the party. Combat was rather simple though. The
interface was easy to use. For instance to attack critters 9-30, 49, 51 for 25
points of damage was a simple: A9-30,49,51<ret>25<ret>.
There was significant data entry up front to enter the critters, but once the
database was built, it was quick from there. I have implemented similar
functionallity in PC versions without the database. When I want a dozen trolls
I hit the add a monster button and enter 6d8+6 for the hitdice and the program
creates the monsters for me. The amount of time has never been significant.
One the subject of Computer Aids, I would like to share a few things that I
have done with some success. One of the first things I toyed with was the use
of a Lap Top player aid. This program rolled the dice for you and had a key
press that would pop up a text editor with your character information or
whatever in it. This worked well, but I don't own a laptop so I couldn't use
it outside of the limited testing.
I have been working on a Traveller specific game aid. It is graphical VGA only
and written in TurboPascal (to kill portability in a hurry). It takes sector
data (from the Archives and GEnie) and displays a Map of the area 4 parsecs
around your current location. It draws the little hexes and bases just like
the GDW maps. The three main differences are, color coding of the planets. I
use a yellow/brown for a desert world, a red for a bad-air world, green for a
mostly land mass world and blue for a mostly water world. There are no
trade/x-boat routs, and the map is not static, but your system stays in the
middle of the screen.
Once you choose a new world to go to, it calucates cargo and passangers and
displays library data about that system. It can take the UWP and expand it as
well as load a text file per hex to display. I would like for it to generate
encounters as well. The cargo system needs fixed, but that is a GDW problem
and not my software. One of these years, when I get a traveller group here in
Louisville, and I get the time to finish the development, I expect that this
will be a nice program. It has the potential to aid the GM, act as a library
comptuer for the players or run as a stand-alone game.
The real drawback to CARPs (Did I just create a nifty new acronym?) is the
portability of the hardware. I don't know of any one with a 10 seat computer
lab with a multi-user computer at home for this (When I win the lottery . . .)
so interactive games, like those that would use an IRC are out. Secondly, we
tend to vary the location of where we play from week to week so lugging a big
AT case around isn't practical either. It is hard to justify $2500 for a
laptop just to game with. Once these problems are solved, then CARPs can
become useful tools.
Just my 0.02 credits worth
Rob Miracle