Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rabiat

Pages: 1 ... 4 5 [6]
76
Other Announcements / Re: Advanced magic, freeform system
« on: June 16, 2008, 08:20:51 AM »
I think the overlapping tokens problem is what's called lexical ambiguity in computational linguistics. If by 'realistic syntax' you mean 'naturalistic syntax', there's no reason to avoid it. Syntactic ambiguity is more difficult to resolve.

Native speakers resolve ambiguity so quickly they don't even see it's there. Natural language parsers usually resolve structural ambiguity by ordering the ambiguous parse results by reverse frequency of occurrence, and picking the topmost result; i.e. if several syntactic patterns fit the sentence, they pick the pattern that is most often used by native speakers.

Since you have the option of defining the language itself, you can avoid the problem altogether by restricting the grammar in such a way that a word's functional category (e.g. subject/main verb/object) follows from its position in the sentence. If you avoid syntactic ambiguity, lexical ambiguity is no longer an issue.

77
Other Announcements / Re: Advanced magic, freeform system
« on: June 15, 2008, 09:27:22 AM »
A low-level functional symbolic language for spells could resemble an assembly language. You might be interested in (or be familiar with) Redcode, which is used in Core War. In Redcode, every syntactically valid statement (one instruction with two operands) is considered functionally valid, which is about as free-form as it gets. The Redcode instruction set only allows for arithmetic operations, memory management and control flow, but device I/O could be adopted from any real-world assembly language.

Conceptually, the interpretation and execution of a spell in terms of an instruction set could happen abstractly within the caster's mind. Peripherals (and their I/O) are more interesting. The caster's body, and his physical surroundings, allow themselves to be controlled by the caster's mind through an interface. For this purpose, you could define 'ports' connected to the caster's peripherals, such as a mana battery, a heat source, the target NPC, a 'resource blender' which extracts magical ingredients from available inventory items, or whatever you need.

An interface such as this allows the game designer to define the caster's access level to the game's internal state; for instance, a caster cannot directly decrement a NPC's hit points, but he could request a poisonous potion form his inventory selector, instruct a heat source to evaporate the potion, and call the air around him to send a poisonous cloud toward the NPC. Each 'device' handles the request in terms of the game engine, or reports an error condition if the request cannot be fulfilled. The execution of instructions requires energy from the caster's mana battery; if there is no mana left, the battery supplies its own error condition, similar to a hardware interrupt.

This is about as atomic as my imagination allows me to define spellcasting. I think the concept could be broken down into the machine code underlying an assembly language, which would more closely resemble the DNA idea. I'm not seeing the Matrix all around me just yet though, so I'll leave this as an exercise to those who do. ;)

I'm not sure whether I understand your point about overlapping tokens. It could be the language barrier, or my view of spellcasting has become ridiculously formal since the hardware metaphor came up. I think you'd want to avoid ambiguous semantics, unless you want local ambiguity to be resolved through context or fuzzy logic. Also, I don't think I understand why you'd want your spells to be perfectly transitive (if that's what you're saying). It's hardly possible to remove arithmetic or logical symmetry, and I think it would be cool to see the alternatives casters come up with to achieve the same result. I'm sure that everyone who's ever done anything in Perl can appreciate that. ;)

78
Other Announcements / Re: Advanced magic, freeform system
« on: June 14, 2008, 08:51:52 AM »
From what you're saying, it seems to me you're trying to define the syntax for a magic (programming) language. This reminds me of Ursula LeGuin's concept of magic in her Earthsea novels. If that's what you're going for, my suggestion above doesn't do justice to the complexity of what you're trying to accomplish.

From a linguistic point of view, you'd probably want to define a formal grammar consisting of syntactic categories and symbols. Given some rewrite rules for a generative grammar, it's relatively easy to parse imperative sentences such as the ones in the opening post. A stupid example:

Sentence: DitransitiveVerb, DirectObject, "from", SourceObject, "to", TargetObject.
Sentence: TransitiveVerb, DirectObject, "to", TargetObject.
Sentence: IntransitiveVerb, TargetObject, {Adverb}.
DirectObject: {Adjective}, Noun.
SourceObject: Pronoun.
TargetObject: Pronoun.
DitransitiveVerb: "transfer".
TransitiveVerb: "show".
IntransitiveVerb: "rupture".
Adverb: "moderately" | "greatly".
Adjective: "much".
Noun: "life" | "air" | "fear".
Pronoun: "me" | "him" | "them".

Most interactive fiction authoring systems (e.g. Inform or Hugo) provide ways to define grammars such as these, if only as template sentences with slots for arguments.

From a programming point of view, you'd be looking for a similar grammar, perhaps with a more limited syntax. Whether a player casts "rupture target greatly" as an imperative sentence or a function like 'void rupture(npc target, int intensity);' essentially makes to difference.

What's nice about the programming language metaphor is that the caster and his surroundings can be seen as the hardware which is manipulated by the spell. If you want to allow spellcasters to freely manipulate this hardware within the boundaries of magic, you'd have to create an interface language between the player and the game engine. As a game designer you wouldn't want the player to have access to the game engine - "for(;;){increaseHealth(PC,maxint);}" would be cheating - but you would like the player to access a lower level than just "cast(frostBolt,NPC);". Something inbetween, which allows the spellcaster to express "absorb heat from nearby lava pit; if (mana left is greater than 10) { bind heat into fireball; throw fireball at critter; } else { breathe fire at critter for 4 MP; }" would be reasonable.

Spells such as these would be procedurally executed, so as a game developer you don't have to exhaustively code the effects of every possible expression. A spell could fail for any reason 'at runtime'; syntax errors reported by the spel interpreter, hardware failure reported by the game engine (absence of a heat source or NPC, or low mana), or functional bugs in the spell code such as "transfer(excruciating pain,balrog,me);".

79
Other Announcements / Re: Advanced magic, freeform system
« on: June 13, 2008, 11:05:51 AM »
Heheh, "mana hacking".  ;D

The concept appears similar to an idea I've had for procedurally generated objects (in particular, NPCs and items). If you break down an object into its components, or characteristics, random objects can be constructed by assigning random values to each characteristic. The same thing could apply to spells.

If you manage to come up with a set of sensible characteristics for spells, and assign meaningful values to them, you could allow players to compose spells according to a predetermined syntax. The easiest encoding I can come up with is a simple list of values, in which every position represents a characteristic. For example:

Position 1: mana consumption; determines spell power.
Values: 1 - 9, representing for how many magic points the player wishes to cast the spell.
Example: cast a Fire spell for 1 MP to light a cigarette; cast same spell for 4 MP to burninate a peasant.

Position 2: target
Values: 1 (target PC), 2 (target NPC), 3 (target wielded item), 4 (area effect)
Example: cast a Frost spell with target 2 to freeze an NPC; cast same spell with target 1 if you're on fire; cast same spell with target 4 to freeze nearby water.

Position 3: spell type
Values: 1 (conjuration), 2 (enchantment), 3 (divination) etc.
Example: cast a Fire spell of type 1 to throw a fireball, or type 2 to light an area, or type 3 to reveal unseen heat sources on the map.

Position 4: effect; allows the caster to reverse the effect of a spell.
Values: 1 (positive effect), 2 (negative effect)
Example: cast a Heal spel with effect 1 to heal wounds; cast same spell with effect 2 to inflict pain.

Position 5: element; determines the spell's elemental flavour.
Values: 1 (air), 2 (water/ice), 3 (earth), 4 (fire)
Example: cast a Bolt spell with element 4 to hurl a fireball, or with element 2 for a bolt of frost.

These are just silly examples, but you get the idea. A spell would be encoded as a five digit sequence. A spell "12112" could be used to target a small frost bolt at a NPC; "64313" would reveal the entire map; accidentally casting "33221" would curse the weapon you're wielding.

This example is too simple to accommodate or encode spells in such a way that they make sense. You'd have to define the common characteristics for your spells carefully, and come up with sensible values for each characteristic. Once you have those, you'd probably have to come up with a better grammar than a string of digits. One game that did this quite nicely is Loom. It allowed the player to cast spells by playing notes. Although most spells were pre-defined sequences, there was some logical arrangement; e.g. playing a tune backwards would produce the opposite effect.

Finally, you don't want to code the effects of every possible combination. You'd have to define as many generalisations as possible, although there are bound to be lots of specific exceptions. Similar spells could probably be handled as groups. There could be a general rule that higher mana consumption would make the spell more powerful, but more difficult to cast. And for nonsensical sequences, the spell parser could decide to produce some harmless random side effect based on some values in the input.

80
Other Announcements / Re: JADE
« on: March 31, 2008, 06:16:30 PM »
Despite my earlier comment about Dwarf Fortress, I've played it for a while and immensely enjoyed discovering the things you can do. I can see why people find it unplayable though; it requires a lot of patience to learn the controls, and some of the gameplay elements are extremely hard to figure out (building an indoor water supply and a lasting food stockpile to survive the first winter, for starters). Once you get past survival, it's a very rewarding game to play.

Plus, DF is a software engineering masterpiece. JADE has the same potential, and at least Biskup shows a similar persistence in developing it. JADE is supposed to provide a lot more complexity than ADOM, but I sincerely hope the learning curve isn't going to be as steep as DF's (or even Incursion's). Adams took the risk of scaring away thousands of potential players when he created a unique work of bizarre genius. JADE however is a game in a tradition of roguelike RPGs, and if it is to meet the expectations of ADOM fanatics, it can't afford to do the same.

81
Other Announcements / Re: JADE
« on: March 25, 2008, 07:41:25 PM »
The interface looks pretty neat compared to ADOM, and the engine appears to be up and running. Given Biskups ambitions with JADE, it's no small feat if the thing doesn't collapse under its own weight in the next couple of months. He must've given thought to that, even if there are no results to show for it yet.

Also, I like the look and scale of the wilderness map. I always thought the map scale of the wilderness in ADOM was too large. The dungeons are too similar to ADOM for my taste, though. I was hoping to see some variety.

The city looks ridiculously large (nearly identical to a screenshot Biskup posted some years ago, btw). It could work, if it's going to have named districts/streets and coherent population. City size seems to kill performance, though.

I'm curious about NPC advancement and random quests, and whether they'd make a great game. In this stage of development, I hope Biskup shows some restraint and doesn't create the Unlimited Universe of Unplayability. I mean, Incursion is an enjoyable game if you're an insomniac statistics teacher, and Dwarf Fortress simply rocks once you've actually quit your job to study key bindings.

83
The closest thing I know is Paganitzu, released by Apogee in 1991. It wouldn't qualify as a roguelike, but it's a nice little puzzle game, and by now it's freeware.

84
Programming / Re: Labyrinth generation
« on: July 31, 2007, 07:08:01 AM »
Quote
You can try cellular automata algorithm (never seen this one put to good use).

There's an article on RogueBasin with some nice examples: Cellular Automata Method for Generating Random Cave-Like Levels.

85
Isn't this release worth mentioning on the front page?

I've been waiting for this one. Now that it's out, I can't find the time to play it. Argh. :$

86
Early Dev / Re: Lands of Elderlore
« on: July 13, 2007, 02:24:20 PM »
Quote from: Gamer_2k4
I don't suppose you're referring to Civilization 2?

No, it wasn't Civ 2. I don't remember what it was called, some kind of war game from the Civ 1 period. I didn't play it for very long, for obvious reasons. But didn't Civ 2 support custom control configurations?

Quote
I never had any trouble with the unrotated setup, because the controls are intuitive.  If you want to move to the tile above you, you press the up key.  Simple.

That's why every isometric game should support custom controls. To you it's intuitive,  I still wake up screaming fifteen years after. ;) Maybe it has to do with the perception of grid lines as cardinal directions.

87
Early Dev / Re: Lands of Elderlore
« on: July 13, 2007, 01:35:29 PM »
First of all, nice screen caps Altefcat. Looks very promising.

Quote from: Anvilfolk
What usually annoys me the most with keyboard input on isometric is people trying to use the standard arrow movement, when it obviously doesn't fit. (...) it might be more intuitive to move on an isometric grid if the "arrows point the way you're going to move" - the standard up-down-left-right don't.

I was wondering about that too. Personally I don't have any problems playing isometric with cursors or numpad if the display is tilted 45 degrees counterclockwise to the display (i.e. pressing the up cursor moves you up and left). I fiddled with game controls once to try a 45 degrees clockwise rotation (i.e. pressing up moves you up and right); it took me a lot longer to get used to and it kept feeling strangely unfamiliar. I always figured that's because I'm right-handed. Then again, I remember playing some ancient turn based strategy game with isometric display where the controls weren't rotated at all (i.e. pressing up moves you, well, up). Having to use diagonal movement keys on the keypad to move along the grid is absolutely horrible. :o I think your suggestion to use the 'qw/as' keys (or 'az/qs' in French ;)) could work very well.

88
Programming / Re: Labyrinth generation
« on: July 11, 2007, 08:53:39 AM »
Sorry if I'm stating the obvious, but maybe this could serve as a starting point for those who are unfamiliar with maze generation. Here are some widely used, basic techniques to create mazes:

  • Rogue style: horizontally and vertically divide a map in sections to guarantee there's no overlap, build a room in each section, then dig tunnels between the rooms. (This is the technique used in e.g. Rogue and Biskup's QHack)
  • Recursive subdivision: start by dividing a clear map in two halves, or four quarters, using walls. Then subdivide each room in the same manner, and continue until all rooms are small enough. (This is the technique used in e.g. Alphaman and DoomRL)
  • Overlapping shapes: fill a map with rock tiles, then dig out shapes (circles, crosses, or L-shapes) at random locations, making sure that at least a single tile overlaps with a previously dug out tile. (This technique produces results similar to e.g. Dungeon Crawl's Lair branch)
  • Prim's/Kruskal's algorithms: fill a map with rock tiles, then dig out 1x3 sections, making sure each section overlaps with a single previously dug out tile. This creates a perfect maze, i.e. one that has a single path from one point to another. (Doesn't occur in any RLs that I know of)

These are just basic approaches, and each requires some postprocessing to create a playable Roguelike map. By themselves, none of them will produce nice NetHack or Angband style maps. Recursive subdivision doesn't create twisty tunnels, Prim and Kruskal don't make rooms at all, and the 'overlapping shapes' technique doesn't create very nice rooms or tunnels, just a roughly hewn cave. The advantage of all techniques is that they can be used to guarantee connected mazes (i.e. with no unreachable segments).

I've always liked perfect mazes as a starting point, but they involve lots of postprocessing. Creating loops in tunnels, filling up dead ends to free up space for rooms, inserting doors at appropriate places, etc.

Here's a couple of references I'd recommend:


I'd be very interested if anyone knows more techniques or references.

Pages: 1 ... 4 5 [6]