I'd code it in much the same way as combat between Eddie Guerrero and
Sarah Silverman while standing on a listinge of California Election
In other words, the specifics aren't that important. I'm not aware of
any Inform-specific examples, but looking at the TADS-3 BattleSim demo
might be worthwhile. You could do worse than trying to implement some
version of D&D combat.
P.S. Some of you may be wondering how I came up with the first
paragraph of my reply. I just looked at the top three search terms at
Google for this week; it was a happy coincidence that one of them is a
We don't do a lot of combat, Ramona; for most folks, it's up there
with mazes, hunger puzzles and the like. There's only one author
whose games commonly (no, /always/) contain combat sequences.
You can find an Inform port of one of these games here:
Right at the bottom are two versions of AttackFoe(). If you
comment out the first one and uncomment the longer one which
follows, you'll be able to experience the uncontrollability, frustration
and regular random death of the author's style. At least this should
give you an idea of what to avoid.
You'll find all my IF pages at http://www.firthworks.com/roger
WARNING: aggressive spam deletion -- use a meaningful Subject!
There are some past RAIF threads on combat listed at:
Having done some fencing in real life, I would love to see a system that
seems believable and enjoyable (but not gory :-) ...
An old post had this to say about "Planetfall", which unfortunately I don't
have access to:
Another excellent example of non-random combat is the
amoeba in Planetfall. Granted, it does warrant a couple
of saves and restores, but it definately shows how
combat can be handled in a non-random way and yet
remain a challenge.
Anyone have any more details on how this worked ?
>Having done some fencing in real life, I would love to see a system that
>seems believable and enjoyable (but not gory :-) ...
Hmm, _Queen of Swords_ by Jessica Knoch is probably not what you
The cube tastes like sugar. You are suddenly surrounded by a herd
of moose. They start talking to you about a moose-load of things.
Too gory ? Details might be interesting anyway. What happens in the combat
system of that game ?
> The cube tastes like sugar. You are suddenly surrounded by a herd
> of moose. They start talking to you about a moose-load of things.
(I keep wondering where this .sig comes from ...)
That could be considered a spoiler. If you don't mind that, though...
... there isn't one. It's a microdetailed simulation of suiting up and
getting the wires right.
> Rand...@gmail.com wrote:
>> I was hoping the DM4 would have something on this since it had parts of
>> the different classic games but I can't find it. I also couldn't
>> locate it in the IBG index. (Someone in the archives posted about the
>> combat in Zork but no one answered them.) If you were standing on say
>> a leaf and you were a tomato hookworm and you were battling an aphid
>> how would something like that be coded?
> I'd code it in much the same way as combat between Eddie Guerrero and
> Sarah Silverman while standing on a listinge of California Election
> Results. ;-)
Last week on Sunday, Eddie Guerrero passed away in his room -- found by
his nephew -- both Raw and Smackdown celebrated his life that week
without the usual in-fighting -- WWE will never be the same again.......
> In other words, the specifics aren't that important. I'm not aware of
> any Inform-specific examples, but looking at the TADS-3 BattleSim demo
> might be worthwhile. You could do worse than trying to implement some
> version of D&D combat.
> P.S. Some of you may be wondering how I came up with the first
> paragraph of my reply. I just looked at the top three search terms at
> Google for this week; it was a happy coincidence that one of them is a
> professional wrestler.
The mad programmer strikes again.......
>"Sophie Fruehling" <sfrue...@LOVELY-SPAM.aon.at.invalid> wrote in message
>>>Having done some fencing in real life, I would love to see a system that
>>>seems believable and enjoyable (but not gory :-) ...
>> Hmm, _Queen of Swords_ by Jessica Knoch is probably not what you
>> mean... :)
>Too gory ? Details might be interesting anyway. What happens in the combat
>system of that game ?
Well, as Michael said, there is no combat. But it's certainly
believable, and if you did fancing yourself, you might find it
>> The cube tastes like sugar. You are suddenly surrounded by a herd
>> of moose. They start talking to you about a moose-load of things.
>(I keep wondering where this .sig comes from ...)
It's from John Laird's _Haunt_, the game with the rabid moose.
You find yourself staring at the
? for a long time, and enjoying it.
With this combat library, roleplaying characteristics can be included
to inform games, making it able to have combats based on life points,
attack capabilities, etc...
I am not the biggest fan of combat in interactive fiction, but I never
quite allow with the usual comment of "we never do those things"
(referred to mazes, combat or hunger), because:
- I could make an interesting logical puzzle based in a maze.
- I could write a dramatic "stranded" story based on a hunger puzzle,
- ... why not? I liked "Beyond Zork". And yes, it had combat in it.
As allways, it's not usually "what is done", but "how it is done".
If anyone's interested, I can translate the above library.
I'm sorry to hear that. When I noticed that his name was a top search
term, I found it interesting but didn't think to investigate why.
If it isn't much trouble, then please do so. Are the PDFs also in
Spanish? (I didn't look at them yet.)
Yes, they are. They're articles originally published in SPAC (The
spanish version of SPAG magazine) about "how to create a combat library
in inform". The example given was this same library.
I won't translate the whole articles. I'll just translate the library
and some instructions of use. As soon as I'm finished I'll post it
I have put combat into three games. The Hugo source code to the first
one is on the IF Archive (it's called scourge.hug). I've refactored and
(at least in my mind) improved it over the years by adding more
features, but when it comes right down to it you could have the best
text-based combat simulator in the world and a lot of your players will
still not enjoy it much. IMHO, combat shouldn't be a selling point, but
rather something that helps model your game world like a
supporter/container drawer or properly functioning rope.
It was my experience that you may not want to add too much too soon.
Here's sort of the process I went through, in terms of features:
1st crack at it:
o Give all characters a variable for maximum hit points and current hit
o Hand to hand & melee weapon combat only.
o Gave all characters hero, neutral and villain flags -- heroes join a
fight the PC becomes involved in, neutrals don't fight at all unless
specifically attacked and villains all team up against the player and
his allies when attacked.
o Added missile weapons (and then kept track of shots remaining and
provided ways to re-supply the weapons.
o Made it so that almost any character, except for the PC's best
friends, could be attacked at any time.
o Removed the whole team-up / group fight thing. A bunch of NPCs
beating each other up wasn't that entertaining, I don't think.
o Added the ability to throw regular items in combat.
o Added code so that some items could be used once as a weapon, but
then described as broken from then on.
o Put in a feature where certain characters had a weakness to certain
items or materials. If they received a successful hit from an item that
qualified they'd instantly be knocked out.
o Some rudimentary ways of handling an enemy follow you around after
combat had been initiated.
o Made the PC comment during while fighting (this required a lot of
content and looking back I should have added four times as much for the
PC to say).
o Put in a difference between hitting someone with a fist and kicking
someone due to the fact that one character's bare skin would cause
... If I had any general advice to give out, it would be use classes
for everything and "describe" all your objects as best you can for
later use. You eventually might want to differentiate between sharp and
blunt objects, between things that can be thrown and things that can be
shot and deal with a character being dead versus being defeated. I
guess the advice one gets on doing classes in general really applies
Let me know if there's anything I can do to help. Hugo and Inform are
pretty similar, so hopefully the scourge.hug file can give you one
person's early take on it. Good luck!
OK, I bit the bullet and put together a complete (though minimal)
implementation of "d20-style" combat:
I've tested it (unlike so much of the code that I post <grin>), plus it
is an example of an Inform extension using the latest features of the
library (which reminds me, I really should put a library version check
in there somewhere). It's only drawback is that it doesn't actually
keep track of the damage that's being inflicted. Since there seemed to
be many ways to do that, I left the details up to the game author.
Note that d20 defines a natural roll of '1' to always be a miss, and a
natural '20' to always be a hit. To that end, there are three optional
subroutines that an author can define:
Only invoked when an attack succeeds.
'defense' is the object being damaged
'damage' is the number of hit-points of damage
Returning a true (non-zero) value supresses the normal message.
Only invoked when a natural '20' is rolled on a d20.
'defense' is the object being damaged
'damage' is the number of hit-points of damage
Returning a false (zero) value causes combat_inflict to be called.
Only invoked when a natural '1' is rolled on a d20.
'offense' is the object that was attacking
Returning a true (non-zero) value supresses the normal message.
I hope that you enjoy it. If the feedback is positive, I may start
doing this with all of my validated Inform code.
Forgive the question, but why have you posted this on ifwiki,
rather than putting it in the 'contributions' directory in the
archive? The archive mechanism seems to me to be working
well; people are familiar with looking for stuff there, and
are much less likely to search the ifwiki. I'd prefer that we
didn't cause this kind of confusion.
Irrespective of where you post the code, surely it's a good
idea to include /all/ necessary information with it? Your notes
above about optional subroutines will be lost without trace
after a few days. And an example of actual use would be
helpful, I'm sure.
> Forgive the question, but why have you posted this on ifwiki,
> rather than putting it in the 'contributions' directory in the
> archive? The archive mechanism seems to me to be working
> well; people are familiar with looking for stuff there, and
> are much less likely to search the ifwiki. I'd prefer that we
> didn't cause this kind of confusion.
In part, so that I can get feedback before it goes into the archive,
asuming a consensous that it should go there.
I've noticed that contributions tend to 'freeze' once they are
submitted. For example, look at 'flags.h' and 'newflags.h': the former
is linked to in several places on the Internet, yet the latter is a
better routine in almost all respects. Yet someone looking at 'flags'
will have no idea that it's been superceded. I've also found code that
just plain doesn't work (perhaps due to subsequent library updates), yet
I'm unsure what to do about it. Should I upload a new version with
minor changes? If so, should I replace the existing version or should I
prefix the word 'new' to its name? If I call it 'new-extension.h', what
happens when someone else wants to improve it again in a couple of years.
Using a wiki impies stronger permissions for someone else to update my
code later, without having to go through a submission process (however
> Irrespective of where you post the code, surely it's a good
> idea to include /all/ necessary information with it? Your notes
> above about optional subroutines will be lost without trace
> after a few days. And an example of actual use would be
> helpful, I'm sure.
Definitely. I finished that code literally fifteen minutes before
leaving home to spend Thanksgiving with out-of-state in-laws. Putting
it on the wiki, even in its undocumented state, allowed people to
stumble across it, even if it wound up taking a while for me to describe
how to use it. In fact, I only started writing the documentation when I
returned and wrote the upstream post, intending to copy it to the wiki
page, but I'm trying to decide the "best" way to include it. The
obvious answer is to put it on the page itself, but what about a
parallel documentation page? Or maybe drop it on the (currently
non-existent) discussion page? OK, maybe not that way.
So it's my suggestion that the discussion be on raif + ifwiki, but
files should be elsewhere. When the discussion is completed, the raif
Google Groups discussion can be linked into the IFWiki page and the
IFWiki page can simply reference the finalized extension file on the
Does this sound reasonable?
If you're still determining what the problem is or if the solution is a
simple one, then this usenet newsgroup is where those discussions
IFWiki is just a repository of historical discussions and markers to
important artifacts. It's meant to compliment, not replace.
"Content" can be divided up in several ways. One of the most popular is
temporal/temporary vs permanent. Temporal content is anything naturally
ordered by time; it ages and drops out of sight as it ages. Email,
USENET and blogs handle it very well. Permanent content, OTOH, needs a
different indexing mechanism such as provided by search engines;
Wordpress provides 'pages' that exist in parallel with blog entries for
this purpose, and ifarchive and ifwiki also handle this type content
Another way to look at content is dynamic vs static. Wikis exist at one
end of this continium, while ifarchive exists far to the other. For
things that are truly static, such as out-of-print games and competition
entries, ifarchive is excellent, but for things that need to change
slowly over time, it seems less suitable. There are semi-regular
discussions here as people try to use something from the archive and
discover that bit-rot has set in. And while no one would dare modify a
copy of Zork, that world-view spills over into other areas, especially
since there's no defined method for updating content as it ages.
I guess I'm trying to fix that. I wrote that extention to satisfy some
personal curiousity, but I don't really intend to ever use it in
anything that I write. If someone does decide to use it, I expect them
to quickly have ideas for improvements, and I want to urge them to merge
those ideas back into my code. I certainly don't want people to point
links to my code and miss someone else's enhancements, as I have noticed
happening with 'flags.h'.
Using sourceforge is an interesting idea, though. Unfortunately, it
really wants a project leader associated with its projects, and that
again seems a little too structured for I-F. Maybe I need to invent a
"sourcewiki.org" to aim for that middle ground, especially if it
supports literate programming techniques.
We also have semi-regular discussions where people try to find
something that *wasn't* on the archive, and discover that link-rot has
set in. (The most recent example being Simon Stapleton's Glulxa.)
I think you're mixing up the static-dynamic axis with the issue of
single-author vs collaborative. There are many resources on the
archive which are updated slowly over time. That's not a problem.
Where it falls down is when the original author falls off the net --
we don't have a way to say "Ok, this file is the current version of
that file, even though it was contributed by someone else." So we get,
effectively, development forks of some resources. ("X-new", "X-newer",
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
I'm still thinking about what to put in this space.
Requirements might be:
* version control
* wiki style home page
* user logins
* mailing lists
* bug/issue tracking
I guess that mostly describes sf.net.
I would really prefer not to have IFWiki.Org take on this sort of
content though. I think the IFWiki is for collaborative dissemination
of information. This other tool would be an IF source
collaboration/project mgmt system.
Now that's interesting. Where can such lists be found (tads