We are doomed..

On 2008-01-09, Radomir 'The Sheep' Dopieralski <news.DeleteThis@sheep.art.pl> wrote:
> This is an interesting topic I would like to discuss in some more
> detail. Obviously, the code/binaries don't change over time without
> some human intervention -- alas, few projects are actually self-contained
> and the surrounding environment changes all the time. Give it some time
> and the things you rely on can be no longer true.
[snip ways to prevent software rot]

One approach is to make your own environment. Design a virtual machine
to run the game and provide the necessary IO facilities and make the
actual game a platform-independent bytecode for the machine. Open source
the VM, so it can be easily ported. Infocom did this with their
interactive fiction way back in 1979. The binaries of the old Infocom
games still work flawlessly on just about any system provided you've got
an interpreter (there are plenty and they have been ported to just about
anything). Sierra and Lucasarts made similar virtual machines to power
their adventure games. Thanks to this, their games are also playable on
smartphones and other weird platforms nowadays. I'm not aware of other
types of games taking this kind of approach.

Of course for an obscure project the software rot threat is now in the
interpreter becoming obsolete, but it's going to be open source and
hopefully much easier to port to a new platform than an entire game
programmed in a platform-dependent way. And if the VM architecture
catches up so that more games use it, there's more of a chance that
it'll be ported.

Java is an existing virtual machine environment, but it's kind of
bloated for roguelikes. Maybe a roguelike VM could be built on top of
LLVM? It provides a platform-independent intermediate bytecode and
facilities for compiling the bytecode to native code or running it with
a JIT optimizing interpreter on various platforms. So maybe the
roguelike developer could publish the game binary as JIT bytecode and
only use a standard, opensource library for system IO to ensure that the
game stays reasonably portable even if the project has been abandoned
and the source codes aren't available.

--
Risto Saarelma
 >> Stay informed about: We are doomed.. 

On Thu, 10 Jan 2008 14:13:23 +0000, Gerry Quinn wrote:

> In article <pan.2008.01.09.21.16.04.577772 RemoveThis @sbcglobal.net>, paul-
> donnelly RemoveThis @sbcglobal.net says...
>
>> It would be nice if there were some other standard that didn't kill
>> your resources like DOS emulation does, but I can't see that catching
>> on. Without the massive library of programs that DOS has, it wouldn't
>> have the momentum to catch on or the stability to remain compatible. If
>> you really want a stable platform for your game, DOS is your target.
>>
>> If you just want to make sure that a sufficiently interested party
>> could get your game up and running, you can get by by writing it to be
>> easily ported, and in a language that isn't going anywhere. But if it's
>> supposed to just work, as is, for decades to come, DOS is your target.
>
> I'd suggest 32-bit Windows.

Not everyone runs Windows even now, much less in the future. I have more
Windows apps that have quit running in newer versions of Windows than DOS
apps that won't run in DOSbox. DOSbox, on the other hand, runs on Windows,
OS X, BSD, and Linux. More, if you don't mind using a slightly older
version. And you can install FreeDOS in a VM too, if you like.

If you're looking to make your game playable for most people for years to
come with no extra effort on your part and no work specific to your game
done by anyone else, 32-bit Windows won't even get you out the gate.
Windows may not remain 100% compatible, and even if it, by some miracle,
did, the number of people using alternative OSes is likely to increase
from its already non-nil quantity. Contrast that with DOSbox: its raison
d'être is to become ever more compatible with an unchanging target. The
same goes for FreeDos.

DOS is the only environment that is currently well-supported, likely to be
well supported for many years to come, and completely free from
"improvements" that will break your game (not counting bugs, which will
presumably affect other games and be fixed).
 >> Stay informed about: We are doomed.. 

On Jan 9, 4:29 pm, Paul Donnelly <paul-donne... RemoveThis @sbcglobal.net> wrote:
> On Wed, 09 Jan 2008 17:19:35 +0000, Radomir 'The Sheep' Dopieralski wrote:
>
>
>
>
>
> > At Tue, 8 Jan 2008 16:16:44 -0000,
> >  Gerry Quinn wrote:
>
> >> In article <wAB*rg...@news.chiark.greenend.org.uk>,
> >> damer... RemoveThis @chiark.greenend.org.uk says...
>
> >>> It is? I thought it was gradually rotting away from lack of
> >>> maintenance.
> >> How can that happen?  I thought digital data was permanent.
>
> > This is an interesting topic I would like to discuss in some more
> > detail. Obviously, the code/binaries don't change over time without some
> > human intervention -- alas, few projects are actually self-contained and
> > the surrounding environment changes all the time. Give it some time and
> > the things you rely on can be no longer true.
>
> > So, how come the old DOS games still (mostly) work on modern operating
> > systems (and "operating systems"), but newer ones do not? How to make
> > sure that your project will still work 20 years from now with minimal
> > (ideally, none) maintenance?
>
> They still work because someone thought it was important to maintain
> support for DOS programs. First Microsoft, presumably for business, and
> now the folks behindDOSbox(and DOSemu, and FreeDOS), presumably mostly
> for games. So I guess the answer to the second part is simple. Write for a
> platform that isn't going to change: DOS. You can piggyback on all the DOS
> games people still want to play. Until all the nostalgic DOS aficionados
> die off, it's going to be easy to play DOS games on modern systems.
>
> It would be nice if there were some other standard that didn't kill your
> resources like DOS emulation does, but I can't see that catching on.
> Without the massive library of programs that DOS has, it wouldn't have the
> momentum to catch on or the stability to remain compatible. If you really
> want a stable platform for your game, DOS is your target.
>
> If you just want to make sure that a sufficiently interested party could
> get your game up and running, you can get by by writing it to be easily
> ported, and in a language that isn't going anywhere. But if it's supposed
> to just work, as is, for decades to come, DOS is your target.- Hide quoted text -
>
> - Show quoted text -

errr no. Sourceforge for your code and SDL for portability should be
your target, not DOS.
 >> Stay informed about: We are doomed.. 

On 2008-01-10, Slash <java.koder DeleteThis @gmail.com> wrote:
> On Jan 10, 11:56 am, Risto Saarelma <rsaar... DeleteThis @gmail.com> wrote:
>> Java is an existing virtual machine environment, but it's kind of
>> bloated for roguelikes.
>
> Is it? I wouldn't think so... (having used it for my projects a lot
> already..)
>
> Java (**As a language, not talking about its VM architecture) has been
> reported to be pretty useful for roguelike development, having the OO
> tools to speed up the job (if not used in a misleading way...), and
> having both language and VMs architecture backed up by a single
> organization/standard gives me a lot of trust than using something
> like LLVM (not to dismiss how interesting the project looks)

Bloated meaning that the runtime takes several tens of megabytes, when a
dedicated roguelike VM should fit into 100k. You need to assume that the
user will install the runtime separately from the game. This is mostly
irrelevant as roguelike players can probably be expected to be able to
install the runtime, and with modern computers the size isn't an issue.

The JVM architecture is probably a very solid platform for games as you
say. I'm interested in the LLVM approach more out of the desire to get
things really lean and minimal while keeping the platform-independent
bytecode than any really practical motivation. There isn't much chance
of getting a hobbyist VM architecture to have anything near the support
JVM has.

--
Risto Saarelma
 >> Stay informed about: We are doomed.. 

On Jan 10, 7:51 pm, ronald.phill... DeleteThis @gmail.com wrote:
> errr no. Sourceforge for your code and SDL for portability should be
> your target, not DOS.

I think that a platform that likely will not change much in a long
time (it hasn't in an equally long time) is curses.

What with PDCurses providing at least 2 implementations for all modern
platforms (SDL is one, and X11 is the others, excepting on Windows,
which has a separate implementation).

Curses bindings exist in plenty of languages, and it's a well-known,
useful platform for all roguelikes. It's difficult to find a platform
that doesn't have some adaptation of curses now.
 >> Stay informed about: We are doomed.. 

On Thu, 10 Jan 2008 18:51:02 -0800, ronald.phillips wrote:

> On Jan 9, 4:29 pm, Paul Donnelly <paul-donne....TakeThisOut@sbcglobal.net> wrote:
>> On Wed, 09 Jan 2008 17:19:35 +0000, Radomir 'The Sheep' Dopieralski wrote:
>>
>>
>>
>>
>>
>> > At Tue, 8 Jan 2008 16:16:44 -0000,
>> >  Gerry Quinn wrote:
>>
>> >> In article <wAB*rg...@news.chiark.greenend.org.uk>,
>> >> damer....TakeThisOut@chiark.greenend.org.uk says...
>>
>> >>> It is? I thought it was gradually rotting away from lack of
>> >>> maintenance.
>> >> How can that happen?  I thought digital data was permanent.
>>
>> > This is an interesting topic I would like to discuss in some more
>> > detail. Obviously, the code/binaries don't change over time without some
>> > human intervention....
>>
>> <blathering about writing for DOS elided>
>>
> errr no. Sourceforge for your code and SDL for portability should be
> your target, not DOS.

And make users mess with recompilation? I think not! Not to mention that
SDL may not behave identically on every platform, the standard library
might not be the same, and so on. Targeting a stable VM seems a lot safer.
 >> Stay informed about: We are doomed.. 

In article <pan.2008.01.10.22.57.41.395924.TakeThisOut@sbcglobal.net>, paul-
donnelly.TakeThisOut@sbcglobal.net says...
> On Thu, 10 Jan 2008 14:13:23 +0000, Gerry Quinn wrote:
> > In article <pan.2008.01.09.21.16.04.577772.TakeThisOut@sbcglobal.net>, paul-
> > donnelly.TakeThisOut@sbcglobal.net says...

> >> If you just want to make sure that a sufficiently interested party
> >> could get your game up and running, you can get by by writing it to be
> >> easily ported, and in a language that isn't going anywhere. But if it's
> >> supposed to just work, as is, for decades to come, DOS is your target.
> >
> > I'd suggest 32-bit Windows.
>
> Not everyone runs Windows even now, much less in the future. I have more
> Windows apps that have quit running in newer versions of Windows than DOS
> apps that won't run in DOSbox. DOSbox, on the other hand, runs on Windows,
> OS X, BSD, and Linux. More, if you don't mind using a slightly older
> version. And you can install FreeDOS in a VM too, if you like.

But lots of people can emulate it. And most of the software that fails
in newer versions of Windows is simply badly written software. Just
write as if you were writing for Win95 and don't do anything fancy, and
your stuff will work fine.

DOS is an irrelevant joke - no serious modern software can be written
on such a primitive system. Just to begin with, how can you do
graphics or sound effects?

- Gerry Quinn
 >> Stay informed about: We are doomed.. 

On Fri, 11 Jan 2008 04:45:47 +0000, Gerry Quinn wrote:

> DOS is an irrelevant joke - no serious modern software can be written
> on such a primitive system. Just to begin with, how can you do
> graphics or sound effects?
>
> - Gerry Quinn

You're right. My ascii game is doomed.
 >> Stay informed about: We are doomed.. 

Saluton!

On Thu, 10 Jan 2008 16:57:42 -0600, Paul Donnelly wrote:
> On Thu, 10 Jan 2008 14:13:23 +0000, Gerry Quinn wrote:
> > In article <pan.2008.01.09.21.16.04.577772.RemoveThis@sbcglobal.net>, paul-
> > donnelly.RemoveThis@sbcglobal.net says...
> DOS is the only environment that is currently well-supported, likely to be
> well supported for many years to come, and completely free from
> "improvements" that will break your game (not counting bugs, which will
> presumably affect other games and be fixed).

Well, if you're going for ancient OSes I suggest AmigaOS.
It's far nicer than DOS and UAE will stay for years to come,
too.

Ad Astra!
JuL

--
jynwyn.RemoveThis@gmx.de / L'état, c'est toi. (Moi)
Jürgen ,,JuL'' Lerch /
 >> Stay informed about: We are doomed.. 

Saluton!

Radomir 'The Sheep' Dopieralski <news.TakeThisOut@sheep.art.pl> wrote:
> Last approach that works pretty well is to be as self-contained as
> possible: don't use external libraries, release your game on a livecd,
> or even better, together with the hardware. You'd still need to provide

Actually, a few years ago there was a text adventure that was
sold with a (even then outdated, so the cost was manageable)
notebook, albeit not for the software rot reason but, IIRC,
accessibility (you just open/switch on the notebook and can
play away).

Ad Astra!
JuL

--
jynwyn.TakeThisOut@gmx.de / Work like you don't need the money. Dance like
Jürgen ,,JuL'' Lerch / nobody's watching. Love like you've never
/ been hurt. - ?
 >> Stay informed about: We are doomed.. 

On 2008-01-11 05:45:47, Gerry Quinn <gerryq.RemoveThis@indigo.ie> wrote:

> In article , paul-
> donnelly.RemoveThis@sbcglobal.net says...
> > On Thu, 10 Jan 2008 14:13:23 +0000, Gerry Quinn wrote:
> > > In article , paul-
> > > donnelly.RemoveThis@sbcglobal.net says...
>
> > >> If you just want to make sure that a sufficiently interested party
> > >> could get your game up and running, you can get by by writing it to be
> > >> easily ported, and in a language that isn't going anywhere. But if it's
> > >> supposed to just work, as is, for decades to come, DOS is your target.
> > >
> > > I'd suggest 32-bit Windows.
> >
> > Not everyone runs Windows even now, much less in the future. I have more
> > Windows apps that have quit running in newer versions of Windows than DOS
> > apps that won't run in DOSbox. DOSbox, on the other hand, runs on Windows,
> > OS X, BSD, and Linux. More, if you don't mind using a slightly older
> > version. And you can install FreeDOS in a VM too, if you like.
>
> But lots of people can emulate it. And most of the software that fails
> in newer versions of Windows is simply badly written software. Just

Mostly true. Vista just KO'ed support for 32-bit Windows help files by default,
and while the support can be installed manually they'll be crippled. So even if
the program works, you'll need a portable documentation format (HTML or text).

Ironically, 16-bit Windows help files are still supported.

> write as if you were writing for Win95 and don't do anything fancy, and
> your stuff will work fine.

I don't think you need be that conservative for Windows programs. The key is to
automate maintaining function call invariants. (E.g., I'm considering UNICODE
curses, which will lock my PDCurses renderer family out of Win95/Win98/WinME.)

> DOS is an irrelevant joke - no serious modern software can be written
> on such a primitive system.

If I knew I could figure out how to wrangle a multicore DOS program (in, say,
Digital Mars C++ or OpenWatcom C++), I'd be shoving my high-end scientific
calculations into DOS. (And booting into DOS to do them.) [Even if I
contrafactually knew about a maintained FORTRAN compiler for DOS, I'm a bit
nervous about FORTRAN. FORTRAN just doesn't provide enough bit-twiddling
support for floating-point numerals for me to be comfortable optimizing BLAS for
it.]

> Just to begin with, how can you do
> graphics or sound effects?

Graphics: Assume SVGA 1.4 standard is available.

Sound: Assume SoundBlaster, as that's what all emulation environments provide.
If running DOS programs in Windows, use VDMSound to emulate SoundBlaster.

The real question is why should one roll a library to cleanly interface with
these, with other cross-platform libraries available.
 >> Stay informed about: We are doomed.. 

On Jan 11, 8:50 am, Gerry Quinn <ger... DeleteThis @indigo.ie> wrote:
> Well fair enough. But if you have ambitons beyond ASCII, DOS is
> irrelevant.
>
> - Gerry Quinn

Many graphical programs were written for DOS. The first two Descents
and the first two Warcrafts both ran in DOS.

--
Gamer_2k4
 >> Stay informed about: We are doomed.. 

Paul Donnelly <paul-donnelly.TakeThisOut@sbcglobal.net> wrote:
>
> DOS is the only environment that is currently well-supported, likely to be
> well supported for many years to come, and completely free from
> "improvements" that will break your game (not counting bugs, which will
> presumably affect other games and be fixed).

Wow. That's like recommending writing on stone tablets because they
are going to be readable until judgment day.

If you want to avoid your (future) users the hassle to recompile there
are several possible ways to achieve this.

Your suggestion is a possibility, but to me as programmer it is too
much pain to program on DOS. It was even horrible when it was in wide
usage.

I would recommend using scripting languages like Perl, Python or Ruby
to circumvent to compilation problem. Although it is not certain, that
these languages will still be around in 20 years or then be compatible
to the current versions.

I think the best compromise between long term compatibility and
non-compiling is to use Java.

We already have some experience how the language designer handle
backward compatibility. Java 1.0 and Java SE 6 are quite different
beasts, but almost every old program still works.

Bye
Patric
 >> Stay informed about: We are doomed..