The Right Language
Mike Sellers
> Joseph N. Hall <j...@ecemwl.UUCP> writes:
> > Has anyone ever thought to write an event-driven core for a
> > rogue-like game? With a queue, asynchronous execution, and a little
> > OOP thrown in? Gosh ...
>
> I have, a good deal. You really need garbage collection. Unless you
> cripple the internal structure. Concurrency would be nice too, but
> that's easier to fudge. Anyone want to suggest the Right Language?
> --
> Felix Lee fl...@shire.cs.psu.edu *!psuvax1!flee
C++. I've been working in it for almost 3 years, and it is what you
want. Object-oriented enough that you can make sense of your design,
but compact enough that you don't have to make performance concessions
or learn YAWL (yet another wonderful language), assuming you already
know C. My company (disclaimer: for whom I would never speak) has
several applications in the area of hundreds of thousands of lines of
code each that run coherently and have no trouble evolving as we go
along.
Then again, I've heard good things about other languages like
Eiffel too.
--
Mike Sellers ...!tektronix!sequent!mntgfx!msellers
Mentor Graphics Corp. msel...@mntgfx.MENTOR.COM
Electronic Packaging and Analysis Division -- AutoSurface Project
"Amor est magis cognitivus quam cognitio"
Felix Lee
is more important than concurrency.
Why is garbage collection important? Because there's no clean way to
destroy objects otherwise. Consider, what do you do when the Amulet
of Rodney explodes? Alpha is wearing it; Beta is afraid of it; Gamma
is trying to steal it; a fuse is going to teleport the Amulet; a
daemon is changing the Amulet's color; etc. You can't deallocate the
Amulet until you remove all references to it. So you mark it as
destroyed and scavenge it later, when references have died off.
Tim Brengle
>destroy objects otherwise. Consider, what do you do when the Amulet
>of Rodney explodes? Alpha is wearing it; Beta is afraid of it; Gamma
>is trying to steal it; a fuse is going to teleport the Amulet; a
>daemon is changing the Amulet's color; etc. You can't deallocate the
>Amulet until you remove all references to it. So you mark it as
>destroyed and scavenge it later, when references have died off.
Speaking as a long-time LISP user and LISP compiler implementor, you should
avoid true garbage collection like the plague! There are few things more
frustrating than waiting while the system plays with itself long enough to free
up a little bit of space.
Besides, reference counting is fast and good enough as long as objects are
"well behaved". That is, as long as all references by objects to themselves
are essentially trivial. One of the reasons that reference counts aren't used
in LISP garbage collectors is because LISP allows you to create circular
structures, resulting in non-trivial self-references.
Tim Brengle
Mr P Johnson Baddow
> No, not C++. C++ doesn't have garbage collection! Garbage collection
> is more important than concurrency.
>
> Why is garbage collection important? Because there's no clean way to
> destroy objects otherwise. Consider, what do you do when the Amulet
> of Rodney explodes? Alpha is wearing it; Beta is afraid of it; Gamma
Using concurrency with message passing (my ideal way, see previous post)
you make the amulet a separate task with message ports instead of methods.
All the other tasks which are trying to do things to the amulet send it
messages. If the amulet has been killed, the messages are ignored.
In fact in my MUD I had a data structure for actions which was sent to the
same port on all objects. By default every action was sent to every object
(players, monsters, property, EVERYTHING) in the same room. An object could
have a virtual presence if it needed to monitor actions in another room.
This allowed all the tasks to keep in sync without the game becoming O(n^2)
on the total number of objects. Destroyed objects just removed all room
references. Bagged objects got messages via their containers.
The advantage of this system is that it is intuitive and object-oriented.
It also works efficiently.
--
Paul Johnson, | `The moving finger writes, And having writ, moves on,'
GEC-Marconi Research | Omar Kyham when contemplating `vi'.
------------------------------------------------------------------------------
The company has put a radio inside my head: it controls everything I say!
Brian McElhinney
>Why is garbage collection important? Because there's no clean way to
>destroy objects otherwise.
Reference counting is pretty easy to do in C++ (which is not as nice as
garbage collection, but goes a long way to satisfying the need you described).
My objections to C++ are that it is a kitchen sink language, and has been
warped in some places (virtual functions jump to mind).
One potential candidate for the "Right Language" is Scheme (the world's best
LISP dialect). You can do a lot more sophisticated/interesting things, such
as creating algorithms dynamically. I always thought it would be interesting
to mutate monster behavior this way and then have them go through natural
selection. Easier said than done...
Brian McElhinney
m...@tc.fluke.com
Steven Grady
My opinion is that the "right" way to go with the ultimate dungeon game
(or whatever) is to have an interpreted language in which the game is
implemented, _and_ the universe is described. (BTW, I make the
assumption that any interpreted language worth it's salt [eg not BASIC]
contains an "eval" function.) This means that the universe can be
modified without re-compiling the game, and can even by modified
dynamically. In fact, this dynamic modification would be how all
actions were implemented. To move things around, the container
property of an object could be set to the new location. The actions of
switches and buttons could correspond to the setting of variables. In
addition, since the world is described with a language, the "values" of
properties of objects could be functions instead of atoms. For
instance (in a lisp-like syntax):
(define-weight 'sword '(if (holding (player) 'amulet) 1 100))
(ie if the player is holding the amulet, then the sword weighs 1, otherwise
it weighs 100).
Of course, once you've got the ability to modify the universe, there's
no reason it has to stop with simple properties like location. It could
also be weight, or color, or value. And if players could make these
modifications via a "spell", that would be a basic implementation of
magic. And since the language is interpreted, there's no reason that
players couldn't create new spells themselves. I've done some fairly
extensive thinking on this concept. It's a bit too complicated to go
into in this posting.
Another important element of the language to use is that it be object-
oriented. There are a number of concepts of OO paradigms that would
be useful. Classes and inheritance mean that the objects can be
defined as a hierarchy, with magical exceptions being easily implemented.
Message-passing makes for a simple implementation of properties being
functions instead of atoms, and allows for an elegant implentation of
special cases for actions (for instance, the standard way for an object
to handle a "move" request might be to go to the new location, but an object
made of acid might also send a "dissolve" message to its new container).
Again, I've put a good deal of thought into the consequences of this
concept.
Some "objects" (ie monsters) might have sophisticated actions associated
with them. Of course, if monsters or other NPCs are implemented as objects,
there's no reason the player(s) couldn't be as well. The "behavior" (that
is, the action associated with a time increment) of a player-object might
be to query that player as to what he wants to do.
In regards to the question of the "right" language, I'm not really
sure what the best answer is. Xlisp supports all the stuff I've
talked about so far, but it's fairly limited in many ways. It might
be possible to write a good single-player adventure in it, but a
multi-player version (which I'm more interested in) would be difficult.
C++ isn't interpreted. Scheme doesn't contain OO support (although one
could add it), but the versions I've seen don't have strong OS support
either. Most lisps are too big. There doesn't seem to be a small,
powerful, interpreted language that has both OS support and OO facilities.
Anyone want to prove me wrong (ie point me at one)? If not, the only
solution might be to implement such a language. I've written a lisp
interpreter before, and although it's not all that difficult, it is a
bit tedious.
Well, like many people reading this newsgroup, I've never implemented
the dream game that I've put the thought into. The main reason is that
the size of the project is intimidating, so I find excuses not to work
on it (like "the right language doesn't exist"). But maybe I'll start with
a vastly simpler game, like a single-player version of this stuff.
It seems like a waste to write a single-player game on a unix machine,
but what the hell. If anything ever comes of this, I'll let people know.
If anyone wants to talk more about the magic or property stuff, send me
some mail.
Steven
...!ucbvax!grady
gr...@postgres.berkeley.edu
"There's another weird lizard farm coming up fast at eleven o'clock."
"I feel the warmth of its presence, Sam."
Joseph N. Hall
virtual methods is needed to construct a sound, elegant framework for
a rogue-like game. Most of the business of generating maps, drawing them,
taking inventories, etc., isn't really simplified by anything more
sophisticated than a slim subset of C++.
What would be very useful, however, would be a simple bytecode interpreter
built to run action routines for critters, objects, rooms, etc., and a
compiler to translate a simple language into bytecode. Smalltalk would
be perfect, but it is too big and too powerful (and they won't let you give
it away). A small subset with an adequate browser would, however, be
a lot of fun and would enable you to interactively debug your monsters'
behaviors (for example) -- sort of like playing a game written in
HyperCard (for you Mac users). I agree that automatic garbage collection
has merit in this context, although I certainly wouldn't burden the
framework by writing the entire game source in a language with extensive
(likely slow) GC support.
Complexity in the action routine language would be unwarranted. At first
you could probably get by quite nicely by using just an "assembler" for the
bytecode.
I investigated this a while back for use in an Adventure-like game (which
got spec-ed out pretty well but never written, alas), and it is certainly
also a viable approach for a rogue-like game.
v v sssss|| joseph hall || 4116 Brewster Drive
v v s s || j...@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606
v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist
-----------|| Disclaimer: NCSU may not share my views, but is welcome to.
Felix Lee
Tim Brengle <bre...@hpcltjb.HP.COM> writes:
> Besides, reference counting is fast and good enough as long as
> objects are "well behaved".
But I can't easily guarantee that objects are "well behaved", in fact
it's natural to have circular references. Reference counting loses.
Andrew Diseker
>Personally, I doubt that much object-oriented support beyond simple
>virtual methods is needed to construct a sound, elegant framework for
>a rogue-like game.
[ ... stuff deleted ... ]
>
>What would be very useful, however, would be a simple bytecode interpreter
>built to run action routines for critters, objects, rooms, etc., and a
>compiler to translate a simple language into bytecode. Smalltalk would
^^^^^^^^^
>be perfect, but it is too big and too powerful (and they won't let you give
>it away). A small subset with an adequate browser would, however, be
>a lot of fun and would enable you to interactively debug your monsters'
>behaviors (for example) -- sort of like playing a game written in
>HyperCard (for you Mac users). I agree that automatic garbage collection
>has merit in this context, although I certainly wouldn't burden the
>framework by writing the entire game source in a language with extensive
>(likely slow) GC support.
>
>Complexity in the action routine language would be unwarranted. At first
>you could probably get by quite nicely by using just an "assembler" for the
>bytecode.
[ ... more stuff deleted ... ]
You might want to look into "A Little Smalltalk", by Timothy Budd,
Addison-Wesley Publishing Company, ISBN 0-201-10698-1. This book describes
an implementation of a subset of Smalltalk, written in C for UN*X machines.
I'm not sure, but I think there are versions floating around for PC's and
MAC's. The book describes a bytecode interpreter, and describes some
example classes and how to use them.
The book lists a Post Office address where one can write to get a
tar tape of source, and chances are if you posted something to
comp.lang.smalltalk you could even more information. The first OO language
I learned was a Smalltalk-80 inplementation on a Tektronix machine, which
was a pretty good system, that unfortunately tended to go into GC on large
images for ~15 minutes at a time ( more a result of the poor design of the
application we wrote, than any language shortcoming ) I've since changed
companies and OO languages ( see .sig, C++ ), and haven't had a chance to
do any 'leisure' programming, but I think that implementing a "Tiny"
Smalltalk would be better suited and more easily learned than trying
to pick up C++. JMHO, though. BTW, I didn't work for Tektronix, and I
haven't had a chance to try the Little Smaltalk code myself, so I can't
answer questions about it, other than what I could copy for you from the
book.
>
>v v sssss|| joseph hall || 4116 Brewster Drive
> v v s s || j...@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606
> v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist
>-----------|| Disclaimer: NCSU may not share my views, but is welcome to.
Andrew Diseker A CRUMPLED FUTURE IN YOUR FIST
Advanced Decision Systems THE KILLING STREAK ASCENDS SUN-KISSED
UUCP: sun!sundc!potomac!adiseker AND THE FIRESTARTER FROM WITHIN
Internet: adis...@potomac.ads.com POKES OUT FROM FEVER BLISTERED GRIN...
Felix Lee
Paul Johnson <p...@hrc63.uucp> writes:
> Using concurrency with message passing you make the amulet a
> separate task with message ports instead of methods. All the other
> tasks which are trying to do things to the amulet send it messages.
> If the amulet has been killed, the messages are ignored.
Something I hadn't really considered. Assign each object a unique id.
However, this still doesn't do what garbage-collection will. Henry is
looking for the Sacred Stone, the Stone is killed without Henry's
knowledge. You cannot free the Stone's data immediately because Henry
is still acting upon the Stone, even though it's been killed. It's
valid for the Stone to respond to messages when it doesn't exist.
Reference counting will fix that, but reference counting won't manage
circular references.
David Forsey
>
>Using concurrency with message passing (my ideal way, see previous post)
>you make the amulet a separate task with message ports instead of methods.
>All the other tasks which are trying to do things to the amulet send it
>messages. If the amulet has been killed, the messages are ignored.
Yep, concurrency is a good idea, but it is not the control of the timing that
is the most difficult to specify and control?
Why have every object as an asynchronous entity? Why not just make the room
the unit of asyncronous action - the mediator of messages? Thus each object
emits messages to its "container" which decides what to do with the message.
Thus if an object is destroyed (or just moved to the next room) you don't
have to scavenge any references from any other objects in the dungeon.
This is what you specify in the following paragraph, but it was not clear
what you meant from the "messages are ignored" statement above.
>In fact in my MUD I had a data structure for actions which was sent to the
>same port on all objects. By default every action was sent to every object
>(players, monsters, property, EVERYTHING) in the same room. An object could
>have a virtual presence if it needed to monitor actions in another room.
>This allowed all the tasks to keep in sync without the game becoming O(n^2)
>on the total number of objects. Destroyed objects just removed all room
>references. Bagged objects got messages via their containers.
To keep the design simple, why not have the room be another container?
Thus events that occur within the room are also sent to the room which
can decide if that event (such as noise or fire etc) should be passed
on to any adjoining rooms. You use the same code for rooms as you do
for bags or satchels. By generalizing and categorizing the types of
actions you require you simplify the coding and generalize the behaviour
of the system. The same code you use to damage objects inside a sack
dropped to the ground allows a room to be shaken up during an earthquake.
Dave Forsey
Computer Graphics Laboratory
University of Waterloo.
Ozan Yigit
>built to run action routines for critters, objects, rooms, etc., and a
>compiler to translate a simple language into bytecode. Smalltalk would
>be perfect, but it is too big and too powerful
Not quite. See "the little smalltalk" from Tim Budd. It comes with a little
bytecode compiler, it is tiny, fast, powerful, and public-domain. It can
be obtained from many sites via anon-ftp. Also try your neigbourhood usenet
archieve site. It is easy to extend the interpreter, so specialized version
of the interpreter should not be too hard to construct.
oz
--
The king: If there's no meaning Usenet: o...@nexus.yorku.ca
in it, that saves a world of trouble ......!uunet!utai!yunexus!oz
you know, as we needn't try to find any. Bitnet: oz@[yulibra|yuyetti]
Lewis Carroll (Alice in Wonderland) Phonet: +1 416 736-5257x3976
Bits_o...@cup.portal.com
point. I've implemented games in BASIC, various Assembly Languages, and
c. I've watched people do it in FORTH, Pascal, various home-grown
interpreters, and various home-grown compilers. The language doesn't
matter. Generally, the higher-level the language, the easier the game
is to write (FORTH is often an exception). I would much rather work in
c than Assembly for most things. I expect to discover that c++ or Modula
are superior to c. It wouldn't surprise me to discover that Smalltalk or
LISP makes the programming easier, but produces a game that's so slow it's
not worth playing.
I'm interested to see that you all seem to be talking about complex RPGs,
and thus about object-oriented programming. I think the OOP paradigm
is very usable for such games, but you shouldn't let the design of your
language dictate what programming paradigm you use. We use OOP concepts with
plain c. It's like they say "Biology is Not Destiny". Well, computer
languages are not destiny either. If you prefer programming in Smalltalk,
by all means do so, but if you can't describe what you want to do with
fundamental operations available in an Assembly language or basic Algol-like
language, you don't know how to do it.
I'm not trying to put the discussion down, I just think you're focusing on
the wrong thing. It's the ideas that go into a program that are important,
not what language it's written in. To steal another pithy saying, "Deeds,
not Words".
******************************************************************************
* Evan Robinson * *
* * I believe in my tusks. *
* bits_o...@cup.portal.com * Long live freedom and damn the ideologies, *
* * -- Robinson Jeffers, _The Stars Go Over *
* Mountain View, CA * The Lonely Ocean_ *
* * *
******************************************************************************
Felix Lee
> I'm not trying to put the discussion down, I just think you're
> focusing on the wrong thing. It's the ideas that go into a program
> that are important, not what language it's written in.
Urf. Okay. The point isn't to create Yet Another game but The Next
Generation of games. Beginning with something like Rogue or Moria or
NetHack, only much more symmetrical. Symmetrical as in, what the
player can do, a monster can do, and vice-versa. NetHack is the most
symmetrical, but in a superficial way; everything is special-cased
code. Asymmetry shows through whenever the N pieces of code that
implement a feature don't agree (e.g., thrown objects).
The obvious (to me) approach is to treat the game as a simulation of
objects, such that everything is an object, objects can be dead/alive,
animate/inanimate, etc. The player is an animate, alive object with a
strategy routine that translates user input into game action.
Is this enough to start worrying about language yet? Or let's discuss
design some more..