Yohimbe has asked for the wisdom of the Perl Monks concerning the following question:
The idea is to build a demo of a game in Perl/tk.
Basic premise is this: Various players request moves in a
gui client, send the move request off to a server. Server
then resolves all moves, stores resultant
game state in db, client reconnects, gets new game state,
game continues.
Assume secure sockets, crypto secure ident, and
spoofing pretty much handled, as in, we'll do
that in the real version if there is one.
One assumes that using perl for this would be slow, and
thats okay by me, since this is to be a proof of concept,
not a playable game.
I've taken a stab at mocking up a perl/tk client, and I'm
satisfied that perl/tk will give us enough features.
The next obvious thing to do is start work on the server end.
We're now working out game rules on paper, but
I was hoping the monks could give me some ideas:
Game rules by external grammar? ie write a parser and a
separate rule file? .. making it "pluggable"
Hard code game rules in a module, and expose an api so we
re write the module for different rules? Also pluggable and
possibly easier to write than a grammar.
Hack up some kind of xs api to the demi-OOP capabilities
of the zip/infocomm game engine?
some other, much smarter idea that I'm missing?
Help me perlmonks, you're my only hope!
--
Jay "Yohimbe" Thorne, alpha geek for UserFriendly
Re: Rule Based Game Engines
by Corion (Patriarch) on Feb 23, 2001 at 00:52 UTC
|
Among the many projects put onto the backburner for until when I find enough time/money to go about implementing them, there also is an RPG engine. Here's what I've thought of, some of this is also available pre-canned as badly formatted XML from my unofficial directory on a student operated machine which might be up or not.
The language
Regarding the scripting language, I've come up with two requirements to it, easy things should be easy, and complex things should be possible. Translated, this means first, the language should be convenient to use. In my opinion, Perl is not necessarily useful, as Perl mostly has intrinsic operators for string manipulation (the RE operators), and you won't be manipulating strings much in your RPG (at least, I won't in mine). The other side is, that you will want a turing-complete language, preferably with support for scope, recursion and maybe even threads and synchronisation, depending on how your game/scripting will be implemented and what the requirements are. The turing-completeness is necessary, since you will need the language to implement the stuff that the data dosen't provide and initial design didn't anticipate.
Other people I've been talking to (on irc mostly) have thought about using and embedding Python, since it is easily embedded, has a clean object system (at least, cleaner than Perl), and has a strict syntax. The strict syntax makes it suitable for the intended user base, which are more likely content-creators than programmers.
Using a Java JVM as the scripting engine is also interesting, but in both cases (Python and Java), it's the object model that makes or breaks the ease-of-use of your engine. The object model should reflect how your users think within the confines of your engine.
Other other people have implemented their own JavaScript scripting, but I shy away from implementing my own toy language, since it's (too) much work or useless.
FedEx vs. Scripting
My own idea, as outlined in that XML document, is to try to get away almost completely without scripting by simply allowing only one metaphor, the FedEx metaphor. The FedEx metaphor (FedEx quest" == "Get item A, go to place B and give it to person C, receive item D) stays until now, as I can implement with it almost every test case I've come up with relatively elegant.
My XML document also (should) outline some of these test cases and how the FedEx metaphor should solve them, my favourite case being the BadCitizen problem and the Door / entrance fee problem :
- Door / Entrance fee : You have a door and a person you have to pay to get entry to that door, but the person and door are not in the same place. How to permit the player only after he as paid the fee entry through the door ?
- BadCitizen : A player attacks a peaceful non-player in a town. How will the attack of the guards and the response of the rest of the townfolk be modeled ? The most interesting case would be to allow murderers to get away with it, if there is no (townfolk) witness.
The "solutions" with the FedEx metaphor are easy, if you allow "attributes" to be attached to the player, where "attributes" are simply invisible items which the player cannot influence.
- Door / Entrance fee : When paying the entrance fee, the player gets an "attribute" DoorPaid attached. The door is a "filtering" door, which only allows world-objects with the DoorPaid attribute through and removes this attribute on leaving the door area.
- BadCitizen : This one is a bit more tricky. A two-component attribute set is needed together with some rules for the guards : If a citizen (NPC) is attacked by the player, he attaches the attribute Murderer.NPCHandle to the player. If that attacked citizen "sees" any other citizens, he attaches to them the attribute AttackedBy.PlayerHandle. If then those two attributes meet, guards will have a rule to attack the player.
The Client
If your game is to be anything multiplayer, you will need some separation of the game logic between the central server and the connected clients. The client cannot be trusted. As long as this premise holds, the client has only the function of presenting a more or less funky UI to the user, all game logic must be finally decided by the game server. As the (at least my) game will be hard turn based (even if the user dosen't perceive it as such, e.g. Baldur's Gate II), a http based interface is the easiest starting point, as there are plenty of libraries to use and connection persistance, security (if necessary) and reference implementations are already there. After a plain HTML interface, or parallel to it, I would consider a Java client, which does offload some of the UI interaction to the clients machine.
Games to look at
In my opinion, no cool engine does make a good game. The main thing that makes a good game is the same thing that makes people come back to a website, it's good content. Quake had almost no success, and was at its time a success because of the new gameplay idea and the multiplayer features. Half-Life, a game based on (almost) the same engine as Quake is, had even more success (with me) becazse it had a long, well thought-out gripping story and much better design to it. Quake ]I[ Arena is basically a engine demo and/or proof of concept of id Software to sell their engine to other content developers. The Infocom adventures had the maximum of story, because they were almost purely text based, but people expect more entertainment of a game today. If you are so inclined, you could also consider /. and this site as a massively multiplayer RPG, in which the players themselves create most if not all content. If you go through some old articles on GamaSutra, you will also find some post-mortem articles on RPGs and multiplayer-RPGs, recounting what was good and what went wrong with the development and merchantability of the game.
Parts of this node have appeared before on the chatterbox.
| [reply] |
Re: Rule Based Game Engines
by TheoPetersen (Priest) on Feb 22, 2001 at 23:41 UTC
|
There are some good thoughts on this in Plugin based Perl app.
I recommend the first approach, mostly since I took it myself;
I use Parse::RecDescent for the parsing, though keep an
eye out for its upcoming faster replacement. The rules parsed by
my grammar allow for external modules that I require
on the fly. | [reply] [d/l] |
Re: Rule Based Game Engines
by princepawn (Parson) on Feb 23, 2001 at 05:21 UTC
|
Games::Rezrov is an Perl implementation of the
Infocom gaming engine. You might check that out.
Again, the distributed, decoupled nature of your
problem seems like a natural application for POE.
In fact, if you use Tk before you
use POE, POE will substitute it's event loop
for Tk's.
| [reply] [d/l] [select] |
Re: Rule Based Game Engines
by Yohimbe (Pilgrim) on Feb 23, 2001 at 01:49 UTC
|
Wow. some immense food for thought.
AFAICS, external grammar seems to be in order, the reasons
seem logical. English is too ambiguous, and from my
experience, zip/infocomm is too hard for non-coders to
hack.
Grammar then is a big part of the devel.
I'm hearing from CB opinions that a web browser client in
java, or just plain HTML might be a better client at start
than Perl/Tk. Fair enough.
Thanks all for your input.
--
Jay "Yohimbe" Thorne, alpha geek for
UserFriendly | [reply] |
Re: Rule Based Game Engines
by Corion (Patriarch) on Feb 23, 2001 at 04:29 UTC
|
Before I fell to the FedEx metaphor, I was thinking about how the game AI for every NPC would be handling the stack of states an NPC would be in. The different states would have different priorities, for example, an attack threatens the life of the NPC and thus must be reacted to before opening the door for the player. I toyed around with some perlish syntax then, mostly like grepping through the "history of events" for that NPC, to simulate memories for that NPC.
If this memory concept is used (which I'm not really sure of), then some language extension that makes searching through the memories easy would be quite necessary, as almost all AI code will be actions based on memory and the current game situation. In that case, either a specialized object (for Python or Java) or some mutation of Perl (m// matches on NPC memory instead of STDIN) could make sense to ease the use of the scripting stuff.
| [reply] |
Re: Rule Based Game Engines
by coreolyn (Parson) on Feb 23, 2001 at 19:32 UTC
|
You may find worldforge a valuable resource (though the site is not all that well organized). Lurking on their mailing lists provides tons of valuable game/interface/server-design conversations. It's not Perl, but no matter what language many of the gaming issues you're tinkering with are discussed there.
Their media is GPL :)
coreolyn
| [reply] |
Re: Rule Based Game Engines
by Anonymous Monk on Aug 07, 2013 at 18:04 UTC
|
Couldn't you get a free game engine and write it in Perl? | [reply] |
|
|