We are doomed..

On Jan 9, 9:19 am, Rachel Elizabeth Dillon <rac....TakeThisOut@akrasiac.org>
wrote:
>
> All roguelikes are buggy, or at least all that I've tried.

I dunno... I wouldn't really call Nethack "buggy". Had bugs, yes.
But "buggy" implies you are tripping on them rather than being "OMG, a
bug!"
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 >> Stay informed about: We are doomed.. 

In article <fm0nrg$26k1$1@news.vol.cz>, konijn.TakeThisOut@gmail.com says...
> On 2008-01-08 17:16:44, Gerry Quinn <gerryq.TakeThisOut@indigo.ie> wrote:
>
> > In article ,
> > damerell.TakeThisOut@chiark.greenend.org.uk says...
> > > Quoting copx :
> > > >ADOM is already the most popular roguelike,
> > >
> > > It is? I thought it was gradually rotting away from lack of maintenance.
> >
> > How can that happen? I thought digital data was permanent.
>
> Data != Software.
> You can tell in *bands which codebase they come from the way they behave on the
> newer OS'es like Vista/Mac OSX 10.5. Give it another 10 years and you will need
> to install retro-software to play Adom if nothing happens for it.

How come MSDOS Rogue runs fine in Windows Vista (except the character
runs too fast when Scroll Lock is on)?

That's a problem with Adom's current code if it's the case.

> > I think the guy's attitude is right. Finish a project, and go onto the
> > next. I find bizarre the attitude some people have that a roguelike is
> > 'alive' before it is finished, then 'dead' from the moment it's done.
>
> Probably you have a different definition of 'finished' and 'done'

I think they are synonymous.

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

In article <slrnfo792r.te1.rachel.RemoveThis@autumnfox.akrasiac.org>,
rachel.RemoveThis@akrasiac.org says...
> On 2008-01-08, Gerry Quinn <gerryq.RemoveThis@indigo.ie> wrote:
> > In article <wAB*rgV3r@news.chiark.greenend.org.uk>,
> > damerell.RemoveThis@chiark.greenend.org.uk says...
> >> Quoting copx <copx.RemoveThis@gazeta.pl>:
> >> >ADOM is already the most popular roguelike,
> >>
> >> It is? I thought it was gradually rotting away from lack of maintenance.
> >
> > How can that happen? I thought digital data was permanent.
>
> Communities aren't permanent, though; active developer involvement and
> active player involvement are often linked. ADOM seems to have staying
> power but I do know people who have chosen to pick up another game
> instead because it seems like a quiescent project, myself included.

I'd say the opposite - if the game is still under development, I see
little point in trying it in an incomplete state. Finish the thing and
I'll try it out; life is too short to play half-done games.

Ironically, this seems to be the #1 complaint about recent commercial
games - that they are released in an incomplete state and need patches.
I can't see how it could be an advantage for roguelikes!

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

On 2008-01-09, Gerry Quinn <gerryq DeleteThis @indigo.ie> wrote:
> In article <slrnfo792r.te1.rachel DeleteThis @autumnfox.akrasiac.org>,
> rachel DeleteThis @akrasiac.org says...
>> On 2008-01-08, Gerry Quinn <gerryq DeleteThis @indigo.ie> wrote:
>> > In article <wAB*rgV3r@news.chiark.greenend.org.uk>,
>> > damerell DeleteThis @chiark.greenend.org.uk says...
>> >> Quoting copx <copx DeleteThis @gazeta.pl>:
>> >> >ADOM is already the most popular roguelike,
>> >>
>> >> It is? I thought it was gradually rotting away from lack of maintenance.
>> >
>> > How can that happen? I thought digital data was permanent.
>>
>> Communities aren't permanent, though; active developer involvement and
>> active player involvement are often linked. ADOM seems to have staying
>> power but I do know people who have chosen to pick up another game
>> instead because it seems like a quiescent project, myself included.
>
> I'd say the opposite - if the game is still under development, I see
> little point in trying it in an incomplete state. Finish the thing and
> I'll try it out; life is too short to play half-done games.

Well, I'm interested in participating with the improvement of games,
so some of my motivations might be different here. I find that another
way to be involved in the community; other people do the same for NH and
Crawl, and it looks like it for ADOM too from lurking on the newsgroup.

> Ironically, this seems to be the #1 complaint about recent commercial
> games - that they are released in an incomplete state and need patches.
> I can't see how it could be an advantage for roguelikes!

All roguelikes are buggy, or at least all that I've tried. Active
development means the bugs might be fixed shortly after being reported
rather than "maybe someday." If there were a roguelike that I enjoyed
playing that had no bugs, I would certainly prioritize it over most
other games

On one level I agree with you; I'm generally not interested in playing
alpha-release quality games, as they aren't as fun as something more
polished. I'm not arguing for releasing a bad product; I'm arguing for
using feedback to produce an even better product. Roguelike developers
(for the most part) don't have an in-house group of testers to find
bugs, imbalances, and other issues; the player base ends up doing a
good chunk of that work.

(Lately Crawl has actually had this, to some extent; a kind soul put up
a publically-accessible server with the most recent build of the game
in progress, and excited players can try out the latest changes before
they've been balanced or even declared bug-free. Personally I prefer the
released version, but some players are very excited and play a number
of games on the bleeding edge; this server, I think, is why Stone Soup
0.3 has had only three patch releases so far.)

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

At Tue, 8 Jan 2008 16:16:44 -0000,
Gerry Quinn wrote:

> In article <wAB*rgV3r@news.chiark.greenend.org.uk>,
> damerell DeleteThis @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?

One way of doing it is to become the Most Important Business Application
Around, so that it's you who set the rules and everyone else need to make
their hardware and software work with yours, not the other way around.
I'd be very interested in a good recipe for attaining such a status.

Another way is to find a project that already has such a status, and base
your project on the same resources. This ensures that you only need to
upgrade as often as they, at worst.

Yet another way is to pick some standards that look the most resonable and
reliable (wide adoption helps too), and follow them while writing your
application, instead of just inventing your own ways. You have a pretty
good chance that at least parts of these standards will be in power after
some time. The standards don't have to be written down -- it migh be a
"widely accepted way of doing this particular thing". There is a problem
in identifying those from your particular point of view, I'm interested in
hearing any heuristics that have worked for any of you.

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
adapters for the power plugs or batteries if the standards ever change,
but that's quite a long time.

--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
 >> Stay informed about: We are doomed.. 

On Wed, 09 Jan 2008 17:19:35 GMT, Radomir 'The Sheep' Dopieralski
wrote:

> One way of doing it is to become the Most Important Business
> Application Around, so that it's you who set the rules and everyone
> else need to make their hardware and software work with yours, not
> the other way around. I'd be very interested in a good recipe for
> attaining such a status.

Step 1: Buy Microsoft.

--
The name "Siana" is supposedly the Welsh form of "Jane", but take
it from me, the name really means "man-eating shark with dimples".
 >> Stay informed about: We are doomed.. 

On Jan 9, 8:07 pm, "copx" <c....DeleteThis@gazeta.pl> wrote:
> "Jeff Lait" <torespondisfut....DeleteThis@hotmail.com> schrieb im Newsbeitragnews:f51b4885-d0c5-4326-af0b-fa03a7ccc119@i29g2000prf.googlegroups.com...
>
> > I must, at this point, give props to copx who acknowledges this
> > distinction and is able to *choose* to end a project rather than just
> > mysteriously stop working on the project.
>
> I always announce the current state of my programs because as a user I
> became very frustrated about the fact that most hobby developers never
> bother to. The WWW is filled with hobby game websites which contain news
> items like "I have just finished yadda, yadda, I am now working on yadda,
> yadda, A new release is just around the corner" .. and then you scroll down
> and notice a statement like this on the bottom of the site "last updated
> 1/1/2001" ..

Maintaining the list of actively developing roguelikes means I get to
watch it slowly grow from 3 months to 3 years :>

> Your post is a nice example of the confusion caused. Warp Rogue is not dead
> at all. In fact, a new version will be released soon (I am only waiting for
> Sherm to fix the Mac port).

I was not referring to your thankfully premature announcements re:
Warp Rogue, but your much earlier killing of Star Hammer. A decision
I questioned at the time, but considering the result is Warp Rogue, I
must now approve.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 >> Stay informed about: We are doomed.. 

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*rgV3r@news.chiark.greenend.org.uk>,
>> damerell DeleteThis @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 behind DOSbox (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.
 >> Stay informed about: We are doomed.. 

"Jeff Lait" <torespondisfutile.RemoveThis@hotmail.com> schrieb im Newsbeitrag
news:f51b4885-d0c5-4326-af0b-fa03a7ccc119@i29g2000prf.googlegroups.com...
> I must, at this point, give props to copx who acknowledges this
> distinction and is able to *choose* to end a project rather than just
> mysteriously stop working on the project.

I always announce the current state of my programs because as a user I
became very frustrated about the fact that most hobby developers never
bother to. The WWW is filled with hobby game websites which contain news
items like "I have just finished yadda, yadda, I am now working on yadda,
yadda, A new release is just around the corner" .. and then you scroll down
and notice a statement like this on the bottom of the site "last updated
1/1/2001" ..

A quick roguelike example:
http://langband.sourceforge.net/

"Currently Langband is in development, and the current version is v0.1.6.
The project is in active development, but needs assistance."

"Last updated May 2003". The last CVS commit happend 3 years ago. "Active
development" indeed.

Of course, always announcing the current state of development does have
disadvantages. I have declared Warp Rogue dead at least three times so far

Your post is a nice example of the confusion caused. Warp Rogue is not dead
at all. In fact, a new version will be released soon (I am only waiting for
Sherm to fix the Mac port).
 >> Stay informed about: We are doomed.. 

Gerry Quinn <gerryq DeleteThis @indigo.ie> wrote in
news:MPG.21eede18c712a4c298beb6@news1.eircom.net:
> In article <slrnfo792r.te1.rachel DeleteThis @autumnfox.akrasiac.org>,
> rachel DeleteThis @akrasiac.org says...

>> Communities aren't permanent, though; active developer involvement
>> and active player involvement are often linked. ADOM seems to have
>> staying power but I do know people who have chosen to pick up another
>> game instead because it seems like a quiescent project, myself
>> included.
>
> I'd say the opposite - if the game is still under development, I see
> little point in trying it in an incomplete state. Finish the thing
> and I'll try it out; life is too short to play half-done games.
>
> Ironically, this seems to be the #1 complaint about recent commercial
> games - that they are released in an incomplete state and need
> patches. I can't see how it could be an advantage for roguelikes!

Most Roguelikes are free. That's a major difference.

With commercial games, just as it became with some commercial PC
software years ago, you are effectively paying to become a beta
tester. (In a few cases, you might even end up an alpha tester.)

With free software, you are getting something for nothing. If it
isn't complete, then you've only really lost some time. If the
developer quits, well, it was hopefully fun while it lasted. With
commercial software, you are paying "complete" prices for an
incomplete product with only the promise that it might become
complete at some indeterminate point in the future, unless the
developer walks away or just switches to a new major revision number
and requires you to buy the product again if you want it.


It does also depend on the type of game. Some games are replayable
enough that updates are fine. Others are much less so. Something
like a story-heavy RPG would really suffer, or just any game that
wasn't entertaining enough to replay it. Something like a Roguelike
or an FPS or similar though might be fine.
 >> Stay informed about: We are doomed.. 

On Jan 10, 11:56 am, Risto Saarelma <rsaar... RemoveThis @gmail.com> wrote:
> I'm not aware of other
> types of games taking this kind of approach.

scott adams - interp + byte code
level 9 - interp + byte code
magnetic scrolls - interp + byte code
(mag scrolls's vm was... 68k cpu!! pretty cool.
they wrote a 68k cpu emulator on the c64... thats impressive!)

Tonnes of "Adventure" companies had interps and bytecode.


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

On Jan 10, 11:56 am, Risto Saarelma <rsaar....DeleteThis@gmail.com> wrote:
> On 2008-01-09, Radomir 'The Sheep' Dopieralski <n....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
>
> 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.

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)

I think I'd rather keep using Java... it has enough support to
guarantee VMs will be produced for enough of the next years... also
JADE, Elderlore, Legerdemain and some other of the "next-gen"
roguelike projects are using it.

SNIP
>
> --
> Risto Saarelma

--
Slash
http://slashie.net
 >> Stay informed about: We are doomed.. 

Radomir 'The Sheep' Dopieralski <news DeleteThis @sheep.art.pl> writes:
[...]
> How to make sure that your project will still work 20 years from now
> with minimal (ideally, none) maintenance?

Minimal maintenance from the author or minimal maintenance from
anybody at all? Make your project do something *useful*, make it open
source, and you won't have to maintain it for its entire useful
lifetime, there'll always be someone to step up and make it work on
the platform du jour, long after you've left the project behind and
moved on to other things.

Bit rot primarily afflicts closed-source software; it should really be
described as a feature of closed-source.

--
Darshan Shaligram <scintilla DeleteThis @gmail.com> Deus vult
 >> Stay informed about: We are doomed..