would this be classified as the POT? post of death?

A couple things I''ve been thinking about the past couple weeks-

For one thing, shouldn''t we be looking more at unstructured (AKA "non-linear", strangely enough) narrative for inspiration? In that vein, I''ve been aiming more for a series of episodes that would be related thematically, and logically cohesive, but not as tightly woven as a classic "literary" plot.

For another, what about starting at the "bushy" end of the Tree of Death? Going with the episodic structure, present the player w. a large number of possible situations (possibly, but not necessarily, tied to geography) and as the player develops their character, the number of available episodes is gradually narrowed to those which more closely fit the developed character. OK, that sounds somewhat convoluted, but hopefully you catch my drift. Then, at a critical point, a number of consecutive episodes would be "unlocked" to finish off the series.

Ok, I don''t want to go on too long, but if this doesn''t make alot of sense w.out examples, let me know.


If you see the Buddha on the road, Kill Him. -apocryphal

Sorry I haven''t been checking in on the thread for ahwile. (I''m messing with OpenGL tonight. The power...)

Here''s some random clarification things/inane babblings that I figure I should probably get off my chest.

First, I''m not sure if I have my idea completely clarified in my head, but I think Wavinator''s idea might be a bit more ambitious. There''s two (probably more, but lets just pretend) different kinds of worlds in games. One is a constantly changing world, things happen even if the player is sitting still. This kind of world obviously takes more AI because the entire world constantly has to figure out what''s going on and act accordingly. The other kind of world is a player driven world. In it nothing really changes unless the player does something, be it move, talk to a NPC, blow up a building, whatever. Now of course there''s lots of shades of grey. Take Diablo (which I played a demo of once, long ago): monsters move around even if the player doesn''t, but no major changes in the plot happen while the player''s sitting still, i.e. Diablo isn''t going to have a heart attack.

The dynamic world would probably be cooler, but the player driven world is easier, and AI scares me.

Now I''m not sure how player-centric the world can be and still work. Obviously you still need things like Bifur the miller, uh, milling, even if the player isn''t talking to him (isn''t that obvious? no?), but the king of thieves trashing the city is probably something that you would want to be player instigated in some way. The world keeps on being the same unless the player does something. The player doesn''t have to directly burn down the city, but he has to at least make the king of thieves angry in some way.

The cool thing about the system (er, you know, whatever I was talking about) is, that it makes all sorts of new triggers for scripting. A trigger is something like "if the player runs off with thief kings daughter, then..." the kind of stuff that you use in RPGs all the time. Really. But of course, as is the point of this thread, you''re limited, because you have to spell out all the triggers before the player even starts playing your game. You go, "if player runs off with thief kings daughter, or if the player kills his cat, or if the player spills soup on him five times and steps on his cat, etc." You have to try and think of everything that the player might do, and you have to provide the player with the means to do it. If you think of a new way to make the thief king mad, you have to add it in your big list.

Now, for system-thingie triggers, you''d say "if thief_king_anger_at_player more than some_number then..." and you''d never touch it again (unless you wanted to change the thief kings temper a bit). The nice things about this should be obvious, the most immediate being, if you think up a new way of making the thief king mad, you give the player the means to do it, and it works. You don''t have to add any more triggers. Or you might decide to take out a few (that whole "player accidently trips on a blue rock at 3:27 and then space monkeys kidnap the thief kings daughter" thing didn''t make sense), you just take it out, and your ready to go. The less immediate cool thing, is that if the player thinks up a new way to do something, that you never thought of, they could do it, and it would work.

I''m starting to get sleepy (2:20 is mighty early in the morning) but I suppose there''s still the side effects thing, which I remember seemed cool at the time, probably is, but I''m not quite remembering why. I guess what it does, is it removes another big "list" of triggers that you would have to deal with. The list is basically, the things that happen when something gets destroyed, or created (more often destroyed, because, er, that just happens more often). Take the mill example again. When the mill gets destroyed, (as I''m sure all my previous examples have shown) all sorts of stuff happens. The town starts starving, the graneries die, whatever. There''s a good amount of things that happen directly because the mill is gone (as opposed to indirectly, the mill goes down, people starve, the thief king''s daughter dies... *cough*). Normally you''d have some kind of script attached to the mill like, "when destroyed, do this and this and this". The problem is that again, you have a big list of actions of ALL the things that might happen when the mill goes away. Really though, that''s none of the mill''s buisness, it''s the things that are affected''s buisness. When you put the load on the things that are affected, things get nice again. If you want to add a new one, you just change the affected object to say "if we''re no longer getting mill vibes, then..." and if you wanted to remove one, you just remove it. An added benifit of this, is that say you rebuilt the mill, and it got destroyed again. Say that when the mill dies, something is supposed to happen, like a character just suddenly can''t stand the horror of not having a mill, and they turn into some wierd necromancer/tortured soul. Well, the mill already got destroyed, and they''re already a tortured soul. So now you would have to add stuff like "but if the mill was already destroyed once, don''t do this, etc." which just get''s messy. If you have it centered on the character themselves, it''s fine, because they already used up their trigger, and the don''t care what''s going on at the mill anymore.

I guess the other cool thing about the side effects, it substitution, but I already talked about that a lot.

Well, time to go to bed. (Or at least try out the next OpenGL tutorial...)

-Firecat

P.S.
I apologize for however many times I mispelled thief. Y''see I accidently ran into this door, and these demonic penguins started coming out of the ground, and...

Hmmm... Maybe you could make it a little more generic:

How about having an object just drop a trigger at its location, if it is stolen (if owner <> player OR owner <> NULL), damaged, or destroyed {people too}, which could either broadcast, or target the owner of the object. This should be pretty much defaultable behaviour.

So, with the Thief King, he could either have a generic reaction to (object_destroyed) (person_killed) (object_stolen) or (person_stolen), along the lines of add to anger, or he could possibly query the trigger, have a special case for the person_stolen->daughter and a generic response for everything else. Maybe an (object_damaged->cat) for stepping on the cat Then if (thief_king->anger) > REALLY_MAD run the thief_king_trash_town script.

Or...

When the player destroys the mill, it would drop "mill_destroyed" (or perhaps a little more generic, building_destroyed->mill) triggers for everyone in town (if you''re going with small towns, if you''re trying to simulate a huge city, you''d probably have to use a global "townie" trigger). When a townie came within the trigger area, they would destroy their trigger and react as they are scripted...

So, with the "tortured soul", he would come within the range of the (building_destroyed->mill) trigger, and he would then run his (transformation_tortured_soul) script, while everyone else might just have an "anger_self" reaction to the general case(building_destroyed) trigger.

In other words, default behaviour is your friend when going for non-linearity.

Hope that makes some sense

-pwd

I think I see what your getting at, generic behavior can be good, and I think dropping triggers could be cool too.

Now about side effects (I''ll be getting back to dropping triggers and generic behavior. I think.)

The world is made up out of lots of objects. Each object has a list of values, like anger, shiny-ness whatever. The values can be whatever you want. The objects also have a list of triggers for scripts, "if anger > blah", "if shiny-ness < blah", etc. Objects probably won''t have many more than two or three triggers for each characteristic. Objects can also emit "fields" of value changing. A field would have the value it changes, say "morale"; how big it''s area of effect is, say 20; and what it does to the value, it adds 10. Now, every object that has "morale" and is within that object''s field gets 10 added to it. The consequences of destruction would be that the object isn''t emmiting it''s field anymore. You destroy the morale object, and everyone that was in it''s radius get''s a drop of 10 in their morale. Now if you have triggers like "if my "morale" < 20" then they might get triggered if that object get''s destroyed. That''s how I think you should be able to set up a vast amount of triggers, such and such is adding or subtracting from a value, and when it''s gone, it stops doing that, so something happens.

What am I talking about? *ponders*

Ah! Okay, the mill_destroyed script is bad. You don''t want to focus on buildings or specific objects at all. What you want to focus on is their side effects, or the values and such that are changed when they''re around. The other objects don''t care at all about the mill, what they care about is that without the mill''s field adding such and such to their food, it goes below their starving point. So instead of having a "if mill_destroyed" trigger for starving, the have a "if food < starving_level" trigger. This adds so much flexability. Say you created a tapeworm object. Instead of saying "if i_have_tapeworms" you''d just make the tapeworm emit a field that subtracts however much from the food value; "if food < starving_level" would still work.

Please ask questions or suggestions or whatever. Everytime I have to explain or clarify it, I figure out what I''m talking about just a little bit more.

-Firecat

Very good, Firecat. That''s the trick to all of this. When dealing w/ events you don''t worry about the cause you worry about the effect.

On a side note, that''s the way quests should work IMO. The engine shouldn''t worry about how the player accomplishes a quest, it should worry that it''s completed.

For instance, the player is told to get an item from a certain NPC. As long as the Player returns w/ the item, that''s all that should matter. If the player kills the NPC to retrieve it, pick his pockets. The more ways the player can interact w/ the game state and world the better, but the point is that however the player completes the goal is fine w/ the engine.

It''s the same idea w/ the triggers and events you were talking about, Firecat. This is good thinking





"All you touch and all you see is all your life will ever be --Pink Floyd
Need help? Well, go FAQ yourself.

This is about a game called Gryps

It seems to be sort of what we are thinking about in some ways.

Quests in Gryps are not preprogrammed, but come into existence by states in the environment. An example to clarify this:

In a typical RPG, a priest would hire the player to retrieve a powerful magical artifact from a dragon, which stole it and brought it to its lair. The players would then try to kill the dragon, or sneak in and steal the artifact. They get a reward if they successfully bring back the artifact to the priest.

In Gryps, the same quest could happen in the following way: A dragon, a species which naturally covets magical artifacts, passes a city on its hunting trip and sees one of his loved artifacts glittering on the altar of the local temple. He grabs it, causing some minor confusion along the way, and returns home into its lair. There he throws it on top of his treasure and leaves again to continue his hunt. The priest discovers his theft and spreads the word that he is looking for someone to retrieve it. Meanwhile the player, who is totally unaware of the whole thing, wanders around and finds a cave. Because he is curious, or because it rains and he hates getting wet, he enters the cave and finds there in a dark corner a heap of magical artifacts. Happy about his discovery he starts filling his bags, picking up the artifact of the priest. But after a short while the cave is getting dark, as a giant shape is entering the cave. The dragon returned. The player tries to hide in the shadows of the cave, but he is lucky as in this very moment a horde of warriors (probably other players, hired by the priest) attacks the dragon. The player uses his chance and escapes. The dragon is slain and the warriors, not knowing which artifact they need, take all. Naturally the priest is not very content that his artifact is not among the ones returned and sends the warriors out again to retrieve it. Now the player is actually part of some big quest, although he has no idea, and did not really intend to do it. It’s just like in real life.

Actually, this "quest" may not really happen, it is just a coincidence that came into existence by the needs of the different parties.






"All you touch and all you see is all your life will ever be --Pink Floyd
Need help? Well, go FAQ yourself.

Okay, some really cool thoughts I had (this doesn''t belong in the writing forum. Oh well...) A lot of this is borrowing OOP (Object Oriented Programming) things and applying them, but here it is:

First almost everything is an object. The ground probably won''t be an object, but nearly everything else is. Trees, people, items, buildings, cats, whatever. When they player or someone does something to an object, it sends an action to the affected object, and the object acts accordingly.

Objects will be inherited from other objects. A human extends a mammal which extends an animal. Obviously some object types, like "mammal" won''t be things that you actually use in the game. These will be "abstract". The difference between this abstract and the abstract in Java is that you''ll be able to actually implement uh, things. I''ll get back to this. Actions will also have inheritence, a kung fu kick extends a kick, which extends a strike (whatever, wierd examples). When an action gets performed on an object, it goes to it''s "action" method which takes an action as it''s input (it wouldn''t be an actual method thingie in the editor, but these are the terms I''m thinking in). The action method is set up like "if action.actionType = "poison" do blah, else if action.actionType = ...". Now say you set up mammals so that when they had a poison action they started losing health. Everything that extended mammals and didn''t have it''s own thing to handle poison actions would default to mammals poison thing. This means that with a couple lines of script/code, you can make almost every animal in the game poisonable. Now say you made a new poison, that would extend the base poison class. It would work with all the old things that could be poisoned, but you could make certain objects, at your leisure, affected differently.

There''s more stuff I was thinking that I should explain, but I''m getting sleepy. Commentations are good

-Firecat

quote: Original post by Anonymous Poster.

For another, what about starting at the "bushy" end of the Tree of Death? Going with the episodic structure, present the player w. a large number of possible situations (possibly, but not necessarily, tied to geography) and as the player develops their character, the number of available episodes is gradually narrowed to those which more closely fit the developed character. OK, that sounds somewhat convoluted, but hopefully you catch my drift. Then, at a critical point, a number of consecutive episodes would be "unlocked" to finish off the series.
If you see the Buddha on the road, Kill Him. -apocryphal

very good.
To fire cat. I see what you mean about triggers.
Let me think about it. Your AI suggestions are
right on.

---------------------------------------------------------------
All your base are belong to us
http://www.people.fas.harvard.edu/~pyang/base/allyourbase.swf

screw it I''m scripting the whole thing
see you in eight years