[Starmap2-devteam] Fw: [rpg-tools] Re: Makeover for an old tool

[Trace K. <Tra...@ne...>]

----- Original Message -----=20
From: Chris Tutty=20
To: rpg...@ya...=20
Sent: Saturday, October 13, 2001 4:20 PM
Subject: Re: [rpg-tools] Re: Makeover for an old tool


Assuming that this conversation will eventually move to the SourceForge=20
project but while we're here...

From: <ey...@ya...>
> - Environment.  I'm speaking outside of my expertise here, but I'm
> going to assume that it's hard to make separate programs interact
> within the windows environment, mainly because I've never really seen
> it happen outside of Microsoft apps.  Yet I already have argued that
> Starmap's strength is its open, sum-of-the-parts approach.
>=20
It's not too bad.  I've built a number of systems that have to interact.
In general these are wrappers for command-line research tools.  You
can still use the old text file read/write techniques that used to work=20
under DOS, although I have had problems with this in a network-based
shared-file setting.

A technique that requires more programming skill, but which is very
powerful is to build your components as OCX's.  Your interface can
then be built using any RAD tool.  Of course I don't think this ports
too well, although the design requirements for OCX implementation
produce code which is modular and has a clearly defined interface
so it should be easy to re-package using whatever modular system
is appropriate for Mac and unix.

> - Centralization.  One reason why all starmapping programs are hard to
> work with is that only one person can work on the universe at a time,
> and transferring data files is a pain.
>=20
The degree of this problem depends on the purpose the tool is being
designed for.  If it's to build a campaign universe then this doesn't=20
seem to be a problem.  If you want to publish that universe for others
to use then the data size is an issue, if you want to allow co-operative
development then you need a tool designed for multiple authors and
that's not a trivial exercise.

> - Platform.  I happen to use Linux for my desktop, and I know many
> people who use Macs.  While there are compatibility layers for Windows
> apps, they are usually a pain.  Dual-boots even more so.
>=20
Agreed.  I've been looking at alternatives for a couple of programs
I want to write and it's a difficult question. =20

I think the most valuable shared project we could embark on is to=20
define a development environment that will produce cross-platform
applications.  If we can find a set of tools that support this then=20
every project that want's to make it's application widely available
has a running start.

> - Complexity.  Starmap used flat ascii files to store its data, and
> while this was easy to edit, it resulted in a /very/ unwieldly
> directory structure.  Also, Starmap's data files were relatively
> simple-- essentially coordinates and a few other vital statistics.=20
>=20
At a certain level of complexity a database become useful.  This
has portability issues, but tools like MySQL are widely available=20
and should serve as a lowest common denominator.

> So what is my solution?  I think that the ideal Starmap would, at its
> heart, be an SQL database with a Perl/CGI or PHP web interface and
> perhaps even a multi-platform client.  The benefits?
>=20
Hmm.  This doesn't seem suited to real-time 3D exploration of the
data, but I agree with the principles.

Chris Tutty


      Yahoo! Groups Sponsor=20
            ADVERTISEMENT
          =20
    =20
    =20

To unsubscribe from this group, send an email to:
rpg...@eg...



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.=20