Sign in with
Sign up | Sign in
Your question

Python?

Last response: in Video Games
Share
Anonymous
May 29, 2005 12:54:44 PM

Archived from groups: rec.games.roguelike.development (More info?)

I'm currently writing a roguelike in Python, since I'm completely in
love with the language. I'm thinking that one day, when it's coming
along, I may rewrite the low-level "engine" in C++ and keep most of the
game logic in Python. This way I (or others) could fairly easily create
a new one or modify the existing one. There are some commercial games
that do this, so it seems like a good idea.

Would pure Python be a good way to write and distribute a roguelike? Or
would it be better to have an executable that runs python scripts? I
guess it's good for it to not require Python to be installed, but I
would guess that Python is probably a pretty common install among people
who play RLs (many of whom probably program).

Currently all it depends on is WConio (and I'm going to make a curses
version when I get a linux machine set up). I've got the basic wrapper
and windows and stuff working pretty well currently.

Also, since I've never seriously worked on writing a roguelike, what
kind of things should I work on first? I'm currently getting the @
moving around and that stuff, but what next? Map generation (no clue
where to start here), line-of-sight (ditto), etc?

I'm planning on making a basic dungeon-crawling one first, then
embarking on a survival-horror roguelike of godlike proportions. :) 

J. W. McCall

More about : python

Anonymous
May 29, 2005 1:08:23 PM

Archived from groups: rec.games.roguelike.development (More info?)

Dnia Sun, 29 May 2005 08:54:44 GMT,
J. W. McCall napisal(a):

> I'm currently writing a roguelike in Python, since I'm completely in
> love with the language. I'm thinking that one day, when it's coming
> along, I may rewrite the low-level "engine" in C++ and keep most of the
> game logic in Python. This way I (or others) could fairly easily create
> a new one or modify the existing one. There are some commercial games
> that do this, so it seems like a good idea.

You may want to take a look at my 7drl written in python, available at
http://atos.wmid.amu.edu.pl/~sheep/projects/zday/

> Would pure Python be a good way to write and distribute a roguelike? Or
> would it be better to have an executable that runs python scripts? I
> guess it's good for it to not require Python to be installed, but I
> would guess that Python is probably a pretty common install among people
> who play RLs (many of whom probably program).

It seems that windows folks are unable to install something that comes in
two pieces. They have no problem downloading 25megs setup file that
contains half the libraries they already have, just in case they didn't
have them, and installs it all, sometimes breaking existing installations.
But when they have two files to run, one to install python and the other
one to play the game, they are somehow completely lost.

I can't say why it's so, but that's how it is. So, it's better to prepare
a binary distribution for windows users.

> Currently all it depends on is WConio (and I'm going to make a curses
> version when I get a linux machine set up). I've got the basic wrapper
> and windows and stuff working pretty well currently.

You might want to check some curses implementations for windows:
http://adamv.com/dev/python/curses/
I haven't got the time to check them.

> Also, since I've never seriously worked on writing a roguelike, what
> kind of things should I work on first? I'm currently getting the @
> moving around and that stuff, but what next? Map generation (no clue
> where to start here), line-of-sight (ditto), etc?

Maybe a design doc first? Then you can look at the list of
things-to-implement and pick one you like...
I learned that some kind of message output/logging implemented early
really pays off. It may be less a case with such an easy-to-debug language
like python, but still.

> I'm planning on making a basic dungeon-crawling one first, then
> embarking on a survival-horror roguelike of godlike proportions. :) 

I guess it's a reasonable plan. :) 

--
Radomir 'The Sheep' Dopieralski @**@_ Bee!
(^^) 3
The Quest for the Real World, try #2: goto -1
Anonymous
May 29, 2005 2:46:40 PM

Archived from groups: rec.games.roguelike.development (More info?)

> You may want to take a look at my 7drl written in python, available at
> http://atos.wmid.amu.edu.pl/~sheep/projects/zday/

Yup, already have it. :) 

> You might want to check some curses implementations for windows:
> http://adamv.com/dev/python/curses/
> I haven't got the time to check them.

I searched and searched, but couldn't find one that seemed to work.
I'll check that link out, though.

> Maybe a design doc first? Then you can look at the list of
> things-to-implement and pick one you like...
> I learned that some kind of message output/logging implemented early
> really pays off. It may be less a case with such an easy-to-debug language
> like python, but still.

Good idea.

J. W. McCall
Related resources
Anonymous
May 31, 2005 3:46:47 PM

Archived from groups: rec.games.roguelike.development (More info?)

In article <slrnd9j1k2.bqu.sheep@atos.wmid.amu.edu.pl>,
The Sheep <sheep@sheep.prv.pl> wrote:
>Dnia Sun, 29 May 2005 08:54:44 GMT,
> J. W. McCall napisal(a):

>> Would pure Python be a good way to write and distribute a roguelike? Or
>> would it be better to have an executable that runs python scripts? I
>> guess it's good for it to not require Python to be installed, but I
>> would guess that Python is probably a pretty common install among people
>> who play RLs (many of whom probably program).

>It seems that windows folks are unable to install something that comes in
>two pieces. They have no problem downloading 25megs setup file that
>contains half the libraries they already have, just in case they didn't
>have them, and installs it all, sometimes breaking existing installations.
>But when they have two files to run, one to install python and the other
>one to play the game, they are somehow completely lost.

No, what end users (not just Windows users) want is for it to Just
Work. Windows installers, for all their faults, are nice in that
they'll do everything to install the software with no more than a few
mouse clicks, and that you can remove it easily afterwards if you
don't like the program. Ditto for rpm, Debian packages and so on.

My experience with running others' $LANGUAGE programs[1]
tends to go like this:

1) Download the program and try to run it. It doesn't work.

2) Read the README file and discover I need $LANGUAGE.

3) Install $LANGUAGE from my Linux distribution. Try again and
find that it still doesn't work.

4) Pore through the README and discover that it needs a later
version of $LANGUAGE or one with a different build-time
configuration.

5) Uninstall the rpm, then download the $LANGUAGE source kit from
the website. Build $LANGUAGE from source. If you've been evil in
a past life, you will at this point run into problems that require
editing configure-generated Makefiles. Finally, install $LANGUAGE
in /usr/local.

6) Try the program again. Discover that it needs $LIBRARY as
well. Go to the website for $LIBRARY, download it and install it
in /usr/local/$LANGUAGE/. If $LANGUAGE provides a handy automated
way to do this and I've used it, I'll also now have to clean up
the resulting mess.

7) Try the program again. This time, it gets as far as the
startup screen before dying horribly. Browse through the source
code and discover it needs $OLD_VERSION of $LIBRARY, not the
current one.

8) Search the web for $OLD_VERSION. Fail to find it, but discover
that the only difference between $OLD_VERSION and the current one is
that the function beat_me has been renamed to beat_me_harder.

9) Go through the source code of the program and rename all three
calls to beat_me to beat_me_harder. Run the program. It works.

10) Try the program for a bit, conclude that it's not very good
and never use it again.

and, optionally:

11) Sometime later, recall that you'd actually done all of the
above before for some other, more useful program and that program
no longer works because it's incompatible with the current version
of $LANGUAGE, which you so eagerly installed overtop the previous
installation. How important this program is to you right now, and
how much time you have to fix everything, is a function of your
conduct in previous lives.

That's not to say that you shouldn't use Python (or Perl, Java, PHP or
whatever). However, if you do, you should put together a binary
distribution that contains everything needed to run the program
_including_ the runtime for your language and does so in a way that
doesn't affect other such programs. If that means you need to stick a
copy of Python.exe and a bunch of library files in
C:/Program Files/YourGame, so be it.

After all, disk space is cheap these days. My time isn't.



--Chris



[1] Lots of languages are offenders at this, not just Python, although
it seems to be involved in the worst of my own bad experiences.
--
Chris Reuter http://www.blit.ca
The Internet wasn't invented to save people a trip to the local video store.
Bandwidth is too valuable to be wasted on Hollywood movies, be they pirated
or not.
Anonymous
May 31, 2005 8:22:59 PM

Archived from groups: rec.games.roguelike.development (More info?)

Dnia Tue, 31 May 2005 11:46:47 -0400,
Chris Reuter napisal(a):

> In article <slrnd9j1k2.bqu.sheep@atos.wmid.amu.edu.pl>,
> The Sheep <sheep@sheep.prv.pl> wrote:
>>Dnia Sun, 29 May 2005 08:54:44 GMT,
>> J. W. McCall napisal(a):

> [1] Lots of languages are offenders at this, not just Python, although
> it seems to be involved in the worst of my own bad experiences.

You mean you had the problems you describe with Python actually?
Oh my, what kind of a broken linux distribution you must be using Oo)

--
Radomir 'The Sheep' Dopieralski @**@_ Bee!
(pq) 3
.v.vVvVVVvVv.v..
Anonymous
June 1, 2005 9:00:19 PM

Archived from groups: rec.games.roguelike.development (More info?)

In article <slrnd9p3qa.28e.sheep@atos.wmid.amu.edu.pl>,
The Sheep <sheep@sheep.prv.pl> wrote:
>Dnia Tue, 31 May 2005 11:46:47 -0400,
> Chris Reuter napisal(a):
>
>> In article <slrnd9j1k2.bqu.sheep@atos.wmid.amu.edu.pl>,
>> The Sheep <sheep@sheep.prv.pl> wrote:
>>>Dnia Sun, 29 May 2005 08:54:44 GMT,
>>> J. W. McCall napisal(a):
>
>> [1] Lots of languages are offenders at this, not just Python, although
>> it seems to be involved in the worst of my own bad experiences.
>
>You mean you had the problems you describe with Python actually?

Not entirely. The list was a composite of the kind of experiences
I've had over the years with various programs written in various
scripting languages. The last few that I can remember involved
Python, though.

I'm now at the point where, when I'm searching Freshmeat for an
open-source program to do X, I skip the Python ones on the first
couple of passes, just because I expect this sort of trouble with it.

The problem isn't anything intrinsic with Python. It's just
sloppiness on the developers' part.

>Oh my, what kind of a broken linux distribution you must be using Oo)

I was using the latest Fedora Core the last time I tried to install
BitTorrent[1]. The latest BitTorrent, from the official site, used
some minor feature from the latest version of Python that wasn't in
the included Python distribution. I think the Fedora packages were
one minor version behind.

Of course, I couldn't install my own Python build because quite a lot
of Fedora's support system is written in Python and I risked breaking
that. Not to mention that I really didn't want to go through the
hassle of installing a new Python distribution just for one program.

Eventually, I found a compatible BitTorrent rpm package and just used
that. It was also a minor version behind but it worked.
Unfortunately, some trackers wouldn't talk to it so I finally gave up
and switched to Azureus, which required a Java runtime but nonetheless
works correctly.


--Chris



[1] Remember kids: don't use BitTorrent to pirate movies and music.
It's much too centralized for that. Use some other P2P system
instead.
--
Chris Reuter http://www.blit.ca
"Watching Elmo be joined by the Backstreet Boys is like having the person who
is repeatedly kicking you in the balls suddenly say, 'Oh. I'm sorry. I forgot
to set you on fire first.'" --Jeff Vogel in talk.bizarre
Anonymous
June 2, 2005 5:11:34 AM

Archived from groups: rec.games.roguelike.development (More info?)

Chris Reuter wrote:

> In article <slrnd9p3qa.28e.sheep@atos.wmid.amu.edu.pl>,
> The Sheep <sheep@sheep.prv.pl> wrote:
>>Dnia Tue, 31 May 2005 11:46:47 -0400,
>> Chris Reuter napisal(a):
>>
>>> In article <slrnd9j1k2.bqu.sheep@atos.wmid.amu.edu.pl>,
>>> The Sheep <sheep@sheep.prv.pl> wrote:
>>>>Dnia Sun, 29 May 2005 08:54:44 GMT,
>>>> J. W. McCall napisal(a):
>>
>>> [1] Lots of languages are offenders at this, not just Python, although
>>> it seems to be involved in the worst of my own bad experiences.
>>
>>You mean you had the problems you describe with Python actually?
>
> Not entirely. The list was a composite of the kind of experiences
> I've had over the years with various programs written in various
> scripting languages. The last few that I can remember involved
> Python, though.
>
> I'm now at the point where, when I'm searching Freshmeat for an
> open-source program to do X, I skip the Python ones on the first
> couple of passes, just because I expect this sort of trouble with it.
>
> The problem isn't anything intrinsic with Python. It's just
> sloppiness on the developers' part.

This isn't a problem with Python or with any scripting language in general.
It's more some sloppy work on the part of your distribution. Myself I have
no problems with 2 different version of Python installed at once. Also, you
can hardly say that Python itself has a too fast release cycle. There was
18 months between the 2 latest major versions and there's hardly any
program that breaks between minor versions.

>>Oh my, what kind of a broken linux distribution you must be using Oo)
>
> I was using the latest Fedora Core the last time I tried to install
> BitTorrent[1]. The latest BitTorrent, from the official site, used
> some minor feature from the latest version of Python that wasn't in
> the included Python distribution. I think the Fedora packages were
> one minor version behind.
>
> Of course, I couldn't install my own Python build because quite a lot
> of Fedora's support system is written in Python and I risked breaking
> that. Not to mention that I really didn't want to go through the
> hassle of installing a new Python distribution just for one program.

Considering that according to the official site, BitTorrent requires a 2.2
Python version for the textmode, I'm amazed that you still are working with
such an old release. ( You need a 2.3 version for the GUI but that's
probably more a problem with wxPython or pyGTK themselves )

Sloppy programing doesn't make a bad language. Consider scons which still
works with Python 1.5 or something.

> Eventually, I found a compatible BitTorrent rpm package and just used
> that. It was also a minor version behind but it worked.
> Unfortunately, some trackers wouldn't talk to it so I finally gave up
> and switched to Azureus, which required a Java runtime but nonetheless
> works correctly.

So, you say Java has an advantage because :
- the language isn't updated often
- Nobody uses the new features anyway
- Since it isn't package in most Linux distro, you don't break anything when
you have to install a new version anyway
Anonymous
June 2, 2005 1:11:58 PM

Archived from groups: rec.games.roguelike.development (More info?)

Dnia Wed, 1 Jun 2005 17:00:19 -0400,
Chris Reuter napisal(a):

> In article <slrnd9p3qa.28e.sheep@atos.wmid.amu.edu.pl>,
> The Sheep <sheep@sheep.prv.pl> wrote:
>>Dnia Tue, 31 May 2005 11:46:47 -0400,
>> Chris Reuter napisal(a):
>>> [1] Lots of languages are offenders at this, not just Python, although
>>> it seems to be involved in the worst of my own bad experiences.
>>You mean you had the problems you describe with Python actually?

> Not entirely. The list was a composite of the kind of experiences
> I've had over the years with various programs written in various
> scripting languages. The last few that I can remember involved
> Python, though.

Something's really broken here.

> I'm now at the point where, when I'm searching Freshmeat for an
> open-source program to do X, I skip the Python ones on the first
> couple of passes, just because I expect this sort of trouble with it.

There's a Python distro specifically designed for testing -- it contains
the newest versions of interpreter and modules, which should be sufficient
for most cases, as the Python is mostly backward-compatible (at least
when the difference between versions is smaller than 0.2).

> The problem isn't anything intrinsic with Python. It's just
> sloppiness on the developers' part.

Probably.

>>Oh my, what kind of a broken linux distribution you must be using Oo)
>
> I was using the latest Fedora Core the last time I tried to install
> BitTorrent[1]. The latest BitTorrent, from the official site, used
> some minor feature from the latest version of Python that wasn't in
> the included Python distribution. I think the Fedora packages were
> one minor version behind.
>
> Of course, I couldn't install my own Python build because quite a lot
> of Fedora's support system is written in Python and I risked breaking
> that. Not to mention that I really didn't want to go through the
> hassle of installing a new Python distribution just for one program.
>
> Eventually, I found a compatible BitTorrent rpm package and just used
> that. It was also a minor version behind but it worked.
> Unfortunately, some trackers wouldn't talk to it so I finally gave up
> and switched to Azureus, which required a Java runtime but nonetheless
> works correctly.

Isn't it the problem with any packages with dependencies?

--
Radomir `The Sheep' Dopieralski @**@_
(Uu) 3 Sigh!
. . . ..v.vVvVVvVvv.v.. .
Anonymous
June 2, 2005 9:10:41 PM

Archived from groups: rec.games.roguelike.development (More info?)

One branch over,

Christophe Cavalaria <chris.cavalaria@free.fr> wrote:
Chris Reuter wrote:

>> The problem isn't anything intrinsic with Python. It's just
>> sloppiness on the developers' part.
>
>This isn't a problem with Python or with any scripting language in general.
>It's more some sloppy work on the part of your distribution. Myself I have
>no problems with 2 different version of Python installed at once.

That may be the case, but look: even if the latest Python magically
guaranteed that multiple installations didn't interfere with each
other, it still would have meant downloading and installing a new
version of Python just to run one program.

That, frankly, is far more trouble than it's worth.


>So, you say Java has an advantage because :

No. I said that the Java-based program installed painlessly and
_worked_. That's all.

This is not the language advocacy you are looking for. Move along.


In article <slrnd9tjar.t24.thesheep@atos.wmid.amu.edu.pl>,
The Sheep <sheep1 % sheep.prv.pl> wrote:
[My troubles installing BitTorrent]
>Isn't it the problem with any packages with dependencies?

I don't think it's fair to blame the Fedora folks for that. Python is
a huge part of that distro's infrastructure and changing the Python
system means they need to retest everything that uses it. That's a
big job.

But that's not my point. My real point is this: if you have written a
program and you want people to use it, you should make it as easy as
possible for them to do so.

If I've written the Greatest Roguelike Ever and I've managed to
convince Joe Blow to download it and give it a try, he's going to give
up if he can't get it to work.

And really, who can blame him. The net is full of half-assed amateur
games (and other programs). Chances are, my game is just another one
of those. If he can't get it to work immediately, he's just as likely
to find a good game somewhere else.

Yes, that's a lot of work for us, and it's not what you'd call fun
work. Darn. If you want people to play your game, you have to do it.

Interpreted languages have a disadvantage here--the interpreter is a
dependency. But if you want people to try your game, you'll have to
come up with a way to resolve that.


--Chris


--
Chris Reuter http://www.blit.ca
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." --Benjamin Franklin, 1759
Anonymous
June 3, 2005 6:17:31 PM

Archived from groups: rec.games.roguelike.development (More info?)

Dnia Thu, 2 Jun 2005 17:10:41 -0400,
Chris Reuter napisal(a):

> In article <slrnd9tjar.t24.thesheep@atos.wmid.amu.edu.pl>,
> The Sheep <sheep1 % sheep.prv.pl> wrote:
> [My troubles installing BitTorrent]
>>Isn't it the problem with any packages with dependencies?
>
> I don't think it's fair to blame the Fedora folks for that. Python is
> a huge part of that distro's infrastructure and changing the Python
> system means they need to retest everything that uses it. That's a
> big job.

I don't even try to blame anyone. Who says that there's any fault?
I just say that all the packages that have any dependencies suffer
form the same problem, it's not not interpreted languages.

You've got installation computer with old libc, then most builds
won't work for you. And yes, upgrading your libc is gonna be painful and
will likely break lots of programs.

> But that's not my point. My real point is this: if you have written a
> program and you want people to use it, you should make it as easy as
> possible for them to do so.

The most games for Atari ST had this resolved pretty well. They contained
their own OS, so you just booted the computer from the disk with the game,
and didn't have to worry about any dependencies.

> If I've written the Greatest Roguelike Ever and I've managed to
> convince Joe Blow to download it and give it a try, he's going to give
> up if he can't get it to work.

> And really, who can blame him. The net is full of half-assed amateur
> games (and other programs). Chances are, my game is just another one
> of those. If he can't get it to work immediately, he's just as likely
> to find a good game somewhere else.

> Yes, that's a lot of work for us, and it's not what you'd call fun
> work. Darn. If you want people to play your game, you have to do it.

And if you don't? ;) 

> Interpreted languages have a disadvantage here--the interpreter is a
> dependency. But if you want people to try your game, you'll have to
> come up with a way to resolve that.

That's not a feature of interpreted languages. It just so happens that
Java was prepared better than Python on that particular installation.

--
Radomir `The Sheep' Dopieralski @**@_
(--) 3 ..zzZZ
. . . ..v.vVvVVvVvv.v.. .
Anonymous
June 3, 2005 6:31:27 PM

Archived from groups: rec.games.roguelike.development (More info?)

In article <slrnda0pjl.hjo.thesheep@atos.wmid.amu.edu.pl>,
The Sheep <sheep1 % sheep.prv.pl> wrote:
>Dnia Thu, 2 Jun 2005 17:10:41 -0400,
> Chris Reuter napisal(a):

>I just say that all the packages that have any dependencies suffer
>form the same problem, it's not not interpreted languages.

Interpreted languages have the extra dependency of requiring the
presence of the interpreter. Compiled languages do not.

You could statically link a C program to its libraries so that all it
needs is a compatible kernel to run. You could even, if you have too
much free time, replace the kernel calls with code that bangs on the
actual hardware so that it will run without an operating system.

With an interpreted language, you can't. You always need to have an
interpreter there.

Of course, there's an easy fix: include the interpreter with the
program, either by dropping it in the tar file or doing something
cleverer like embedding your program in a C string and then statically
linking that into the interpreter.



>You've got installation computer with old libc, then most builds
>won't work for you. And yes, upgrading your libc is gonna be painful and
>will likely break lots of programs.

Sure, but that doesn't happen much in practice. Libc has been stable
for so long that C programs just work. The have to.

Also, I could always just statically link to libc. Then, my program
wouldn't have that dependency.

But that's irrelevent. Yes, every computer program out there has
dependencies. That's obvious. The issue is: how many of your users
is that going to exclude and how much work will it make the others do?

The answer to both should be "as little as possible". That's all I'm
saying.


>> Yes, that's a lot of work for us, and it's not what you'd call fun
>> work. Darn. If you want people to play your game, you have to do it.
>
>And if you don't? ;) 

Well then, you're fine.

>> Interpreted languages have a disadvantage here--the interpreter is a
>> dependency. But if you want people to try your game, you'll have to
>> come up with a way to resolve that.
>
>That's not a feature of interpreted languages. It just so happens that
>Java was prepared better than Python on that particular installation.

Nah, I think it means that the Java PROGRAM was better packaged than
the Python PROGRAM.


--Chris


--
Chris Reuter http://www.blit.ca
"Wow, a teacher being stupid and a jerk as well? Never in my education did I
experience that more than once a year."
--Joseph Michael Bay, <bk0eoa$mns$1@news.Stanford.EDU>
Anonymous
June 4, 2005 1:53:36 AM

Archived from groups: rec.games.roguelike.development (More info?)

Chris Reuter wrote:

> In article <slrnda0pjl.hjo.thesheep@atos.wmid.amu.edu.pl>,
> The Sheep <sheep1 % sheep.prv.pl> wrote:
>>Dnia Thu, 2 Jun 2005 17:10:41 -0400,
>> Chris Reuter napisal(a):
>
>>I just say that all the packages that have any dependencies suffer
>>form the same problem, it's not not interpreted languages.
>
> Interpreted languages have the extra dependency of requiring the
> presence of the interpreter. Compiled languages do not.
>
> You could statically link a C program to its libraries so that all it
> needs is a compatible kernel to run. You could even, if you have too
> much free time, replace the kernel calls with code that bangs on the
> actual hardware so that it will run without an operating system.
>
> With an interpreted language, you can't. You always need to have an
> interpreter there.

You are a master of the obvious you know.

> Of course, there's an easy fix: include the interpreter with the
> program, either by dropping it in the tar file or doing something

Have a look at py2exe and py2app.

> cleverer like embedding your program in a C string and then statically
> linking that into the interpreter.

Python Freeze is what you are looking for.

>>You've got installation computer with old libc, then most builds
>>won't work for you. And yes, upgrading your libc is gonna be painful and
>>will likely break lots of programs.
>
> Sure, but that doesn't happen much in practice. Libc has been stable
> for so long that C programs just work. The have to.

Yeah, that's why binaries compiled with glibc 2.1 broke with 2.2 and
binaries compiled with 2.2 break with 2.3.

> Also, I could always just statically link to libc. Then, my program
> wouldn't have that dependency.

As you said, you can also staticaly link with the interpreter.

> But that's irrelevent. Yes, every computer program out there has
> dependencies. That's obvious. The issue is: how many of your users
> is that going to exclude and how much work will it make the others do?
>
> The answer to both should be "as little as possible". That's all I'm
> saying.

That's the packager job to do
Anonymous
June 4, 2005 8:11:19 PM

Archived from groups: rec.games.roguelike.development (More info?)

U¿ytkownik "Chris Reuter" <cgreuter@csclub.uwaterloo.ca> napisa³ w
wiadomo¶ci news:hksn7d.71f.ln@catarneh.blit.ca...
> No. I said that the Java-based program installed painlessly and
> _worked_. That's all.
>
> This is not the language advocacy you are looking for. Move along.

:-) So maybe we need some run-time advocacy? The Python runtime is
around 1MB, so it can be included into any download. How big is Java's
again?

> Interpreted languages have a disadvantage here--the interpreter is a
> dependency. But if you want people to try your game, you'll have to
> come up with a way to resolve that.

Every language has some kind of runtime dependancy (even if it's just
glibc or msvcr71.dll). The question is: how easy is it to blend the
full runtime with your package. Python and C/C++ make it very easy,
Java makes it _impossible_ due to its so called "free" license.

regards,
Filip
--
Contrary to what some people say, my OS _is_ my lifestyle choice, not
a tool choice; however, I am against osizm
Anonymous
June 6, 2005 6:57:05 PM

Archived from groups: rec.games.roguelike.development (More info?)

In article <d7sd32$hma$1@nemesis.news.tpi.pl>,
Filip Dreger <fdreger@amiga.pl> wrote:
>U¿ytkownik "Chris Reuter" <cgreuter@csclub.uwaterloo.ca> napisa³ w
>wiadomo¶ci news:hksn7d.71f.ln@catarneh.blit.ca...

>> Interpreted languages have a disadvantage here--the interpreter is a
>> dependency. But if you want people to try your game, you'll have to
>> come up with a way to resolve that.
>
>Every language has some kind of runtime dependancy

This is true, in that every program needs a compatible computer and,
most of the time anyway, an operating system.

> (even if it's just
>glibc or msvcr71.dll).

However, it is still possible to bypass the need for an external C
library by statically linking your program to your library.


> The question is: how easy is it to blend the
>full runtime with your package. Python and C/C++ make it very easy,
>Java makes it _impossible_ due to its so called "free" license.

Actually, (the last time I checked, anyway), the Java licence allowed
you to include the runtime with your programs. Also, curse you for
making me defend Java!

All of this, by the way, is irrelevant to my original point. I
realize that most languages out there have ways of letting developers
bypass inflicting dependency hell on their users. I just wish more
developers would actually USE them.


--Chris


--
Chris Reuter http://www.blit.ca
"'How will this software get my users laid' should be on the minds of anyone
writing social software[.]"
--JWZ, <http://www.jwz.org/doc/groupware.html&gt;
Anonymous
June 6, 2005 7:00:27 PM

Archived from groups: rec.games.roguelike.development (More info?)

In article <42a0b547$0$16566$636a15ce@news.free.fr>,
Christophe Cavalaria <chris.cavalaria@free.fr> wrote:
>Chris Reuter wrote:
[...]
>> The answer to both should be "as little as possible". That's all I'm
>> saying.
>
>That's the packager job to do

If you'd actually read my posts before responding, you'd know that
THAT is exactly my point.


--Chris


--
Chris Reuter http://www.blit.ca
"There'd be a lot less cheesy poetry if more people came armed with Crazy Glue,
is my take on the matter."
--Kent Paul Dolan, on falling cherry blossoms
Anonymous
June 6, 2005 11:51:44 PM

Archived from groups: rec.games.roguelike.development (More info?)

Dnia Mon, 6 Jun 2005 14:57:05 -0400,
Chris Reuter napisal(a):

> In article <d7sd32$hma$1@nemesis.news.tpi.pl>,
> Filip Dreger <fdreger@amiga.pl> wrote:
>>U¿ytkownik "Chris Reuter" <cgreuter@csclub.uwaterloo.ca> napisa³ w
>>wiadomo¶ci news:hksn7d.71f.ln@catarneh.blit.ca...
>>Every language has some kind of runtime dependancy
> This is true, in that every program needs a compatible computer and,
> most of the time anyway, an operating system.
>> (even if it's just
>>glibc or msvcr71.dll).
> However, it is still possible to bypass the need for an external C
> library by statically linking your program to your library.

Maybe you can do it with libc, but problems appear when the library itself
depends on hardware (like those for OpenGL). Sure, you can still link them
all somehow, and at startup present a choice:

a) cga
b) hercules
c) tandy
d) ega

Like the good old days. But nowadays the hardware is rarely
backward-compatible (look at winmodems, for example).

Sure, I can easily make a small (<10 megs) linux distribution, prepared
to run python interpreter and my game, and then tell the users to just
boot it. But it will only work on the computers that this particular linux
distribution will run at. Chances are, that python interpreters will
evolve together with their target machines, and so the source will be much
more portable than such a bootdisk.

Plus, nobody wants to close all the programs and reboot just to play some
game, and I see no other option to get rid of all software dependencies.

--
Radomir `The Sheep' Dopieralski @**@_
($s) 3 Ching!
. . . ..v.vVvVVvVvv.v.. .
Anonymous
June 9, 2005 11:18:53 PM

Archived from groups: rec.games.roguelike.development (More info?)

Dnia Thu, 9 Jun 2005 14:11:24 -0400,
Chris Reuter napisal(a):

> In article <42a65372@dnews.tpgi.com.au>, Glen Wheeler <gew75@uow.edu.au> wrote:
> [...]
>> So your argument is... what exactly? What are you trying to say?
>
> That having hard-to-resolve dependencies is a bug.

It's a bug of the distribution in which the package that has
the hard-to-resolve dependency is included. Obviously, it can't
be a bug of a standalone package -- because each and every package
would be buggy then. Right?

--
Radomir `The Sheep' Dopieralski @**@_
(@a) 3 Be?
. . . ..v.vVvVVvVvv.v.. .
Anonymous
June 14, 2005 9:10:53 PM

Archived from groups: rec.games.roguelike.development (More info?)

In article <slrndah5gm.t4r.thesheep@atos.wmid.amu.edu.pl>,
The Sheep <sheep1 % sheep.prv.pl> wrote:
>Dnia Thu, 9 Jun 2005 14:11:24 -0400,
> Chris Reuter napisal(a):
>
>> In article <42a65372@dnews.tpgi.com.au>, Glen Wheeler <gew75@uow.edu.au> wrote:
>> [...]
>>> So your argument is... what exactly? What are you trying to say?
>>
>> That having hard-to-resolve dependencies is a bug.
>
>It's a bug of the distribution in which the package that has
>the hard-to-resolve dependency is included.

No, it's your bug. Or, to be more precise, it's your problem.

If the user can't get your program working, he or she won't use it.
It doesn't matter whether that's because of a bug in your code or
because the OS changed underneath you; they won't use it. And if your
program is a commercial software product, you'll go broke.

People want to get software, install it and use it. If they can't do
that with yours, they'll go on to someone else's and curse your name.
It doesn't matter who's fault the problem is--you're the one who has
to fix it.

> Obviously, it can't
>be a bug of a standalone package -- because each and every package
>would be buggy then. Right?

I think you misunderstand me. I'm saying that it's the developer's
responsibility to make sure that a program doesn't have troublesome
dependencies.

If I can install a package by typing "yum install foobar" or "rpm -i
foobar.rpm" (or even by double-clicking on foobar.msi), that's not a
bug. I can do that with most of the software I use.


--Chris


--
Chris Reuter http://www.blit.ca
"Please Wait While The Email Loads..."
--From a piece of spam
Anonymous
June 15, 2005 10:42:21 AM

Archived from groups: rec.games.roguelike.development (More info?)

At Tue, 14 Jun 2005 17:10:53 -0400,
Chris Reuter wrote:

> In article <slrndah5gm.t4r.thesheep@atos.wmid.amu.edu.pl>,
> The Sheep <sheep1 % sheep.prv.pl> wrote:

>>It's a bug of the distribution in which the package that has
>>the hard-to-resolve dependency is included.
> No, it's your bug. Or, to be more precise, it's your problem.

Oh, I see, so I should contribute a path to the broken distribution then?

> If the user can't get your program working, he or she won't use it.
> It doesn't matter whether that's because of a bug in your code or
> because the OS changed underneath you; they won't use it.

Do you suggest that I should check my game against all possible
distributions to make sure it doesn't use something that's not there?

> And if your
> program is a commercial software product, you'll go broke.

If my product is commercial, it will usually be distributed by my
company, not some third party. Then I can easily take care about
dependencies.

> People want to get software, install it and use it. If they can't do
> that with yours, they'll go on to someone else's and curse your name.

Or they will switch to another os/distribution that doesn;t have those
problems. I like Windows much better since I deleted it from my hdd :) 

> It doesn't matter who's fault the problem is--you're the one who has
> to fix it.
You seem to mistake two different roles -- the developer and the packager.
It's developer's task to make sure the program works and has no bugs.
It's packager's task to make sure it's easy to install.

For alpha/beta projects, there are usually no packagers. For
small/young/not popular projects, the developer does the job of the
packager.

But in most cases the packagers are the people associated with certain
distribution -- then they are in position to take care about dependencies,
include proper packges in the distro, etc.

>> Obviously, it can't
>>be a bug of a standalone package -- because each and every package
>>would be buggy then. Right?

> I think you misunderstand me. I'm saying that it's the developer's
> responsibility to make sure that a program doesn't have troublesome
> dependencies.

And I'm disagreeing with it. Shoot me. :) 

> If I can install a package by typing "yum install foobar" or "rpm -i
> foobar.rpm" (or even by double-clicking on foobar.msi), that's not a
> bug. I can do that with most of the software I use.

That's because of work of the boys (and girls) who hacked your
distribution together.

Note, for example, that rpm's are supposed to be as fragmented as
possible. The are often packages like foo-1.0.rpm, foo-libs.1.0.rpm,
foo-progs.1.0.rpm, foo-devel.1.0.rpm, foo-static.1.0.rpm,
foo-common.10.rpm, etc., which all belong to a single program, all depend
on each other, yet are separated. Just downloading one of those rpms and
installing it won't work.

Many distributions offer automated downloading and installing of
dependencies, which might fool some users.

--
Radomir `The Sheep' Dopieralski @**@_
(==) 3 Yawn?
. . . ..v.vVvVVvVvv.v.. .
Anonymous
June 17, 2005 8:57:09 PM

Archived from groups: rec.games.roguelike.development (More info?)

In article <slrndavjea.si9.thesheep@atos.wmid.amu.edu.pl>,
The Sheep <sheep1 % sheep.prv.pl> wrote:
>At Tue, 14 Jun 2005 17:10:53 -0400,
> Chris Reuter wrote:

>> I think you misunderstand me. I'm saying that it's the developer's
>> responsibility to make sure that a program doesn't have troublesome
>> dependencies.
>
>And I'm disagreeing with it. Shoot me. :) 

Look, this is getting repetitive. All I'm saying is this: If a
program is too hard[1] to install, people won't use it. It doesn't
matter why or whose fault it is--they just won't.

If, like many OSS developers, this doesn't bother you, that's okay.
It's not like they're paying you for it. You had your fun and now
it's available to anyone who feels like playing with it. It's no
biggie if nobody does.

However, if you want people to use it, either because it'll bring you
money or just out of the goodness of your heart, you have a problem
and nobody else is going to solve it for you. The standard excuse is
usually something like, "your OS is broken" but that doesn't matter.
Nobody else in the world cares enough about your program to fix
whatever needs to be fixed. Therefore, the job falls on you.

Understand? It's okay not to bend over backwards to make your game
compatible with every platform out there, but it's not okay to then
complain that people aren't playing it.


--Chris



[1] The meaning of "too hard" varies from person to person, though,
depending on their skill level and how important it is to them
that they can run your program.
--
Chris Reuter http://www.blit.ca
"You can tell when you're working with 'Enterprise Software Solutions' because
the vendor freebies are red t-shirts."
--Anthony de Boer, <clqp3e$13e$1@blacksun.leftmind.net>
Anonymous
June 19, 2005 9:54:54 PM

Archived from groups: rec.games.roguelike.development (More info?)

U¿ytkownik "Chris Reuter" <cgreuter@csclub.uwaterloo.ca> napisa³ w
wiadomo¶ci


> Actually, (the last time I checked, anyway), the Java licence
> allowed
> you to include the runtime with your programs. Also, curse you for
> making me defend Java!

:-)
Sorry for answering so late, I was away from rgd for some time.
Yes, you can distribute Java along with your program but:
- you are not allowed to make the installer invisible! My roguelike
is written in Python, but most windows users will never notice the
fact, from their point of view it's just click'n'play. With Java, I
could add the runtime (ergh... 10 megs? or more?) but it would have to
be placed in a separate archive and would require a separate
installation - something we all wish to avoid.
- a game that contains JRE is not free to copy. Each distributor (eg.
publisher of a magazine who wants to put it on his cover CD) is
obliged to put a special, additional information printed on all the
media that contain it. I'd rather not make my game so difficult to
handle.

regards,
Filip
!