Subject: Re: (2958) (2959) A little less obtuse (re: 2955)
>
> MacGyver writes:
> The problem with the idea is market. How much more are you
> willing to pay for this software? In addtion, which computer should
> this software be intended for? IBM? Mac? Apple? NeXT? How many RPGer are
> willing to pay for this? Based on the various game companies, not enough
> to justify the effort. And for a specialized computer, that would
> push the R&D cost even higher, and market lower. From what I'm told.
As I see it, the increase in development cost of a simulator
on multiple systems is neglegible compared with the initial
development cost if the writers use almost any high level language,
although C is probably best for this (no flames please -- it's just
that almost anything will compile single-threading K&R). What this
implies is that if you ignore GUIs and make a text-only application
it should look the same, feel the same and in fact be the same
program when ported to Unix, Mac OS, MS-DOS, Intuition, OS/2, the
Commodore 64 or whatever you please with a minimum of effort.
If graphics get involved it is a different story because the
different capabilities and expectations of the underlying hardware
get mixed in. However, I was thinking in terms of a program for
which graphics wouldn't matter; one that would handle bookkeeping
and not be SSI's on-line Monster Manual.
I simply don't see number of platforms as a drawback -- for
what you have in mind it wouln't be.
> Paul Dale writes:
> Would a gaming house show much interest in a combined RPG/computer game?
> I suspect not, they would be able to produce the RPG and then flog the
> computer assistance off to the public as a game-aid. Unless the computer
> was supplied with the game I cannot see it being very workable (what
> computer to support?). If the game included enough bookkeeping to warrant
> computer assistance as standard, it would be very close to unplayable without
> the machine aid. Personally, I like to know what the system is using to
> resolve things (lets you play the odds better :-) A computer introduces
> a 'black box' into the works that removes this knowledge.
Hm. I think that it's possible to do this the way you
would prefer it. First, it's possible to support multiple operating
systems for a program that is designed to be reuse as much code as
possible. The programs that have problems with being ported are
those that are trying to do it all instantly -- programs written in
80x86 assembly and those for graphical interfaces. (No wonder
they're having so much trouble with WordPerfect for Windows!) To
reiterate, programs written in a high-level language and making few
or no assumptions about the underlying hardware would be the best.
After all, unless combat involves floating-point matrix manipulation
you shouldn't be able to tell the difference.
Second is that certain combat systems are workable with two
people but simply unplayable with mass combat. There is a thread on
newsgroup rec.games.design involving the benefits of simple combat
systems vs. the implausibility of them. The more complex systems
(I'll call them duelling) seem to involve multiple related strikes
as a result of the 'real' combat initiative (where people 'press
their attack', etc.) They may be fun to play but would really bog
down a standard game. Enter a computer. The computer can be
programmed to not only do the table lookups/calculations when told
to, but it could also be set up to make realistic decisions for NPCs
in such combat if the GM wishes to have it do so.
I think that there are some small game companies out there
that would write something like that and sell it as a package. With
RPGs currently the cost of simple computer games a game bundled with
bookkeeping software should be marketable in the high end. If they
treat it as 'value added' instead of 'gimmick' it should do well in
the gamers' market. And if size is a problem, the die-hard
roleplayer could pick up the HP 55LX pocket PC...
- --
Segal's Law: | Jack Dietz
A man with one watch always knows what time it is. | ([email removed])
A man with two watches is never sure. | Earthquake Drill