hi,
Sorry about the totally unrelated subject, I'll try to control myself
more in the future!
Somewhere in a galaxy far, far away, Jack Dietz says:
> 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
>...
I'll add a quick comment here since I used to program Macs for a living.
Writing a text only application isn't really good enough for machines which
are based strongly around a GUI. Users (the people who really count) get
used to the picture interface and get very upset when they lose this. A
text only program is very unlikely to sell for a Mac (programmer's utilities
are an exception to this, but everybody knows programmers are different).
I suspect, that the other window based systems would require more than a
bare text interface to sell. There is a massive amount of effort required
to add windowing and menus to a text based program in an effective manner,
it is nearly always better to re-write the program pretty much from
scratch and get things right. There have been several companies that
produced a naive conversion of an existing program and got bitten (there
are some exceptions: infocom, three-sixty. The product they produced
was of top quality anyway).
[ Gee, my quick comments are getting longer and longer the closer my thesis
deadline approaches. ]
> I simply don't see number of platforms as a drawback -- for
>what you have in mind it wouln't be.
You have also got to support all these different platforms. My ship design
program is an example of a simple, reasonably well written program. It compiled
without problems on several versions of Unix, and on the Mac. It died on
the Amiga (did you ever get it working richard?, are you even reading this ;-)
> 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...
It is a HP95 isn't it? (assuming that you mean the IBM compatable handheld).
My personaly preference is for the HP48SX, but then I own one :-)
Is the sales quantity going to offset to software development costs?
Writing RPG-aid software is a nasty buisness (ask just about anybody who
has tried to computerise an existing part of any system), and you are
likely to require a non-trivial hardware platform to do anything useful
(which would bring it out of the gimmick classification). All this is
going to increase the cost of the package. I am not saying that it isn't
possible, just that I cannot see anything like this working in the near
future (unless one of us starts writing lots of code quickly ;-) I would
be unhesitant to claim that it would be a VERY high risk venture.
Of course, you could include the die rolling computer to save having to
roll 2000d6 during large scale combat. That rates as a useless gimmick
in my book.
Any chance of a TDR or CAT sub-group on portable computerised game assistant
packages?
[ No really it was a sarcastic comment, ....... I really didn't mean it,
......... no please don't shoo[BANG] ....... Thud. ]
Pauli da insane
Paul Dale | Internet/CSnet: [email removed]
Dept of Computer Science| Bitnet: [email removed]
Uni of Queensland | JANET: [email removed]
Australia, 4072 | EAN: [email removed]
| UUCP: [email removed]
f4e6g4Qh4++ | JUNET: [email removed]