WR - General Chit-Chatter/Tidbits

[shihonage]

You can simply write :X Appears!: instead of teleport and then use Edit/Find & Replace to replace it with the proper script fragment when you know how the engine works.

Except you can't teleport him, because you can't work around the bug/feature, so you end up writing him into the scene from the start, as a seemingly harmless NPC (until he attacks!), and giving him things to say when you click on him. And then you go through the document and do this for all other teleporting attackers.

That was just one example, and search/replace solutions don't work even for that. It gets a lot more complicated when the documentation grows. Crucial things may have to be handled in different way in order to achieve vaguely the same result.

With quest chains and interconnected quests, it snowballs.

That's why I am against overdocumenting this shit, because there's always a chasm between written word and real implementation, unless you start with implementation.

It is also very easy to wander off from "what's possible" and realize it a bit too late. You will write things in story-language, rather than game-language. Things like "And then the wizard realizes he was betrayed..."... and someone between that DOC and the CODE has to implement it in a workable way and then go back to the doc and rewrite the entire fucking quest (/chain) after it was implemented, to reflect the WAY in which it was implemented.

And that thing is linked to something else. And so it snowballs.

 

[Surf Solar]

I'm on some creative dead end at the moment

staring at an empty design document all day isn't really funny

Chances are, you get overwhelmed by all the possibilities of what you COULD DO, and find yourself lost trying to find what you SHOULD DO right now. It seems that you can go wrong in so many ways, so you get stuck trying to theorize the right way, and then the fear comes in.

Yup, apart that real life strucks me hard lately, this is pretty much the case. I don't have so much time at the moment thanks to the latter sentence and if I have time on the PC, I think I "MUST" create something RIGHT NOW - this mostly ends in the things you described. There's much stuff to do, and I don't know where to start. This is why I've looked for a bit help lately (namely on the fleshing out of locations, dialogs and how the main story arch ties into smaller locations etc).

Let's say you create a maze full of tight corridors and a premise that's entirely underwhelming. It's not just "a lot better" than nothing, it's MONUMENTALLY better.

It's funny, because I actually did exactly the same thing last week. :D (creating maps without anything in mind in opposition to the " I now do a map for location XY") Did it just for fun, without anything particular in mind. Then, after some time, I got ideas where to use it, how to improve it, how to connect it with other maps etc. Sometimes, just working a bit into the blue really helps, yeah.

For example, you want an assassin to teleport behind a door when you do a dialogue option, and you document this and several similar occurrences as part of a whole quest chain, until you actually do it, and realize that Teleport() function in the engine was conceived with a different purpose in mind, and upon doing a Teleport(), the NPCs' home faction is set to the faction of the place he gets teleported to, so you can't make him attack anyone!

I know, yours is just an example, but atleast for teleporting in the engine it's pretty straightforward ( void r_TeleportToMap (int mappid, int entid) ) and doesn't do weird stuff like changing the critters proto (or flags set there, what faction he's in etc). But I get what you mean. Mostly I try to keep everything grounded, I look at Fallout 1/2 and see if idea xy could be done in there aswell, if yes, cool, if no, look if something can be improved to make it work or if it's a trainwreck, then write it in the doc. I guess it really helps that I worked quite a long time already with the engine before I started my own game, to know what the engine can and what not and so on.

Don't start a mountain of theoretical documentation, because you will have trouble connecting it to gameplay. You can't tell in advance how it will work, whether the engine has the right tools to do a quest that way, etc etc. Update the document, update the script, update the document in every place that your new discovery affects... You will get lost in a constant feedback loop between theory and practice.

You're ofcourse right, but as said above, I planned to get 1-2 more people on boat, atleast some small documentation is needed, else everyone just says "wtf am I supposed to do here?" I mostly have problems with the main story arch, there are bits I want to improve, but regardless what I come up with, I am not satisfied with, hence the "staring at empty design doc".

P.S. never make quests tied to other quests. If you have:

quest 1: bring NPC some petrol
quest 2: bring him matches so he sets himself on fire

I do quite the contrary, because there's lots of branching and each quest has atleast a bit to do with the other. As long as the creator is aware how many variables are available and there always more than 3 ways to do thing XY, I think it is ok.


As for your post: Thanks. It's nice to see that I'm probably not the only one having these kinds of symptoms every now and then.

 

[shihonage]

I do quite the contrary, because there's lots of branching and each quest has atleast a bit to do with the other. As long as the creator is aware how many variables are available and there always more than 3 ways to do thing XY, I think it is ok.

The point is to greatly EASE and ASSIST the management of branching. In fact... to make it MANAGEABLE in the first place.

The idea behind quests is to alter state of the world. Therefore, the natural way to define "quest entry conditions" is NOT by checking other quests, but by checking the state of the world.

Who knows HOW you altered the state? Maybe you added 5 more quests that can give the NPC the diezel fuel. Now you gotta check ALL of their status in the followup quest?

The point is that he has diezel fuel, not that you completed a list of quests.

What if you complete a quest that gives him diezel fuel and then steal it back? In your approach, he would still ask for matches to set himself on fire. In my approach, he would check for diezel fuel and simply not do that.

There's never a NEED to reference quests from other quests. It's a flawed and bug-spawning approach. If you need to alter state variables ("you changed NPCs mind about alcoholism!"), they're located in individual NPC data, not quests.

Though I don't know if FOnline allows for such a thing.

Anyway... just my $2000.02. I empathize with your creative mindset, your drive and your troubles as well.

Good luck to us all

 

[Surf Solar]

What if you complete a quest that gives him diezel fuel and then steal it back? In your approach, he would still ask for matches to set himself on fire. In my approach, he would check for diezel fuel and simply not do that.

There's never a NEED to reference quests from other quests. It's a flawed and bug-spawning approach. If you need to alter state variables ("you changed NPCs mind about alcoholism!"), they're located in individual NPC data, not quests.

Though I don't know if FOnline allows for such a thing.

All referencing is basically done through variables, not "quest done yes/no". To use your example with the alcoholic guy, I just create a new entry in the vars file, name it "guy_with_alcoholic_problem" or whatever. I then set it to 6 different conditions, each has a number. Like, 0 - is default without the player ever interferring, 1 - player cured alcoholism by whatever means, 2 - player killed alcoholic 3 - player tried to heal addiction but failed, npc died (for other npc to reference this 4 - player tried to heal addiction but failed, npc still lives though 5 - player asked his companion to cure the addiction 6 - player talked npc into suicide because alcohol is a devil, he'll never get cured etc etc.
All these variables can be easily changed to one on another wether via script if action xy is done, or even easier via a single dialogue node. If it's a global variable, you can set a check at any other npc in the gameworld, write a dialogue node to reference "I heard npc xy an entire continent away finally bought the farm, a shame for him" and if the demanded variable is true for the player because he did this action, this particular npc will utter this line. It's a very easy system and allows for great branching, it only depends on the developers creativity.

So tl;dr - I have such variables with up to 15 different conditions for every NPC who is more than "generic townsfolk" - it's not stored in "questdata" - thus allowing easy sorting. I maybe just was a bit too vague on that in my previous post, or I simply misunderstood you.

 

[Surf Solar]

Hahaha. Just the day I whined on here that there's a lack of creativity, my helper "Samira" ( may you be blessed if you ever will read this thread, my priestress of coding ) does magic , so something awesome happens. You know that, when you have some stream of consciousness which turns into "man! why haven't I thinked of that before???"? This happened today. :D Not only that we brainstormed about the final few main story archs and almost fleshed out the last missing lines, no I was also inclined to finally finish the devices needed to complete "chapter" 1 - it's playable now. :> I'm really happy at the moment as some single, very very minor thing which turned out to be a real bitch made its appearance back. I am talking about some kind of "Jukebox". It eats only prewar quarters, a limited ressource, but plays a couple of songs if the player has repaired said machine. This may sound trivial, but it was a bitch to code this thing to make song XY play at jukebox condition ABC. Now I can even waste precious hours on very minor shit like that, you can gather holodiscs with songs on it to play in the local jukebox, lol! :D

"NPC failure" is because I forgot to add an AI file to the critter. Don't worry. I really try to add minor "atmosphere" stuff like that, aswell as "combat" stuff. Right now, we are trying out if "player can control all his followers in battle" and see if it gets too easy.

Basically, I just got my motivation back.

On some sidenote, I want to add some shiny animated "thing" here in the bottom right corner:

I want something like the Diablo Mana bar showed in example above for EINS - but it must make sense in the current interface. It is supposed to be "animating" for normal exploration, if player engages battle it stops to animate, and if the player has his turn, it starts animating but has a different color.

Now my question - what , in terms to the other "wooden" stuff, would you add there as an animated object? What would make sense in the setting? Also, "EINS" - would you mind if this "Skilldex" graphic would just stay, or do you want it to be changed since the rest of the inventory is changed too?

Thanks for your feedback!

Also:

 

[Excidium]

So you're back to work at full speed? Nice!

Did you make that critter?

Right now, we are trying out if "player can control all his followers in battle" and see if it gets too easy.

If it gets too easy then you balance it to be more challenging!

About the thing in the corner: I don't know. Maybe a chronometer or a small terminal screen...

 

[curry]

Hahaha. Just the day I whined on here that there's a lack of creativity, my helper "Samira" ( may you be blessed if you ever will read this thread, my priestress of coding ) does magic , so something awesome happens.

something awesome happens

something awesome happens

 

[pipka]

Then it was Deathclaw Age : Fallout.

 

[Surf Solar]

So you're back to work at full speed? Nice!

I hope so.

Did you make that critter?

No, it's from a talented critter maker over there on the russian FOnline boards, but now I have my deathclaw equivalent, since it wouldn't make sense to have deathclaws around the Michigan area.

If it gets too easy then you balance it to be more challenging!

Easier said than it is done. :D Right now I can blaze my way through the first parts of the game if I do an unarmed powerbuild, whereas all the other combat skills are relatively tight attached to the weapon progression I've put in. I don't want to "nerf" Unarmed/Close Quarter Combat though, so I have to think about some workarounds.

About the thing in the corner: I don't know. Maybe a chronometer or a small terminal screen...

Hm, a terminal wouldn't really fit since these were the elements I wanted to remove from the vanilla interface to begin with.. But the chronometer sure sounds nice

although I'm a bit worried that it might look too Arcanum-y after that, have to experiment with it.

Then it was Deathclaw Age : Fallout.

True. One can only learn from the Masters of RPG at BioWare.

 

[ghostdog]

Maybe you should go the Mass effect / Alpha protocol route, conceal the actual lines and give the player the three mandatory choices of conversational disposition :

 

[Excidium]

Did you make that critter?

No, it's from a talented critter maker over there on the russian FOnline boards, but now I have my deathclaw equivalent, since it wouldn't make sense to have deathclaws around the Michigan area.

Cool! Are there going to be other new critters?

If it gets too easy then you balance it to be more challenging!

Easier said than it is done. :D Right now I can blaze my way through the first parts of the game if I do an unarmed powerbuild, whereas all the other combat skills are relatively tight attached to the weapon progression I've put in. I don't want to "nerf" Unarmed/Close Quarter Combat though, so I have to think about some workarounds.

I understand.

About the thing in the corner: I don't know. Maybe a chronometer or a small terminal screen...

Hm, a terminal wouldn't really fit since these were the elements I wanted to remove from the vanilla interface to begin with.. But the chronometer sure sounds nice

http://felixmoessbauer.de/tl_files/feli ... ometer.png

although I'm a bit worried that it might look too Arcanum-y after that, have to experiment with it.

Hm. Yeah, maybe something like this or this could work better than a chronometer.

Then it was Deathclaw Age : Fallout.

True. One can only learn from the Masters of RPG at BioWare.

http://www.abload.de/img/dialog141t9.png

 

[Surf Solar]

About the thing in the corner: I don't know. Maybe a chronometer or a small terminal screen...

Hm, a terminal wouldn't really fit since these were the elements I wanted to remove from the vanilla interface to begin with.. But the chronometer sure sounds nice

http://felixmoessbauer.de/tl_files/feli ... ometer.png

although I'm a bit worried that it might look too Arcanum-y after that, have to experiment with it.

Hm. Yeah, maybe something like this or this could work better than a chronometer.

I've fiddled around with some stuff but I honestly don't know..On the bottom right, there are the "end turn" and "end combat" buttons. The animation and stuff is ofcourse just WIP and I'm starting to think that there is a bit too much unused space. The animation plays when combat is triggered, when combat is off, that thing is "closed". What I wanted to do additionally is some kind of arrow, going from left to right on that scale depending how much the player is radiated (there's MUCH more radiation damage in WR), problem is, it would only display that stuff when combat is on, which is subpar.




UI's.... how are UI's formed...

 

[sgc_meltdown]

bro would it be possible to just cover up HALF of that leaving your ectometer rockin 24/7

 

[Surf Solar]

lol, fuck me, but you're a real bro. Always coming up with solutions which should be rather obvious to me, but I've never thought about them. I think it's some kind of Tunnel Vision, one is so "deep" into details that the most obvious things aren't visible. Ah and yes, it's possible and I'll do so. Thanks again. :>

Only thing I need to do now is to draw or render a nice looking arrow for that thing, and to replace the original buttons. FINALLY this fucker will be finished then.

 

[SCO]

You know shihonage is right about that quest advice concerning state entanglements.

It's what software developers call low coupling.


Plus, as a semi-related advantage, organizing your quests this way can open the game to alternate solutions that you've maybe haven't even planned. Sell gasoline to the dude for him to start setting himself on fire without having to start the quest?

(this can make trouble with your dialog assumptions ofcourse, since scripters often don't bother to check in them if the quests happened when they are supposedly connected quests chains).

 

[shihonage]

tage, organizing your quests this way can open the game to alternate solutions that you've maybe haven't even planned. Sell gasoline to the dude for him to start setting himself on fire without having to start the quest?

That's exactly the purpose. This method allows the change of operating mode from "controlling" (literally having to account for every single action player does in advance), to "containing".

"Containing" makes sure that no matter what crazy shit the player does in what order, the world's reaction to it still makes logical sense. Most of the time, at least.

Instead of micromanaging player to a T, he's in sort of a resin bubble that expands in different directions, but doesn't break. The grand idea here is that this bubble is built through content organization METHOD, rather than content itself. Programmatically - not through menial labor.

Of course I haven't done enough in its implementation to run into potential problems with this approach - there are always problems - but I will eventually. Intuitively it just feels that no matter the problems, this is the only approach worth pursuing.

 

[Surf Solar]

Hm, maybe it's the late hour, maybe it's the limited vocabulary, but I don't "get" the aforementionend posts, even if I know you want to help me. :/ Gotta read it tomorrow again...

Even if the gasoline guy accidently sets himself on fire without the player interfering, or some other NPC does it, the variable is flexible enough so it still changes, even without any influence of the player.. Or, maybe, I misunderstood, as said...

 

[shihonage]

I was just agreeing with a guy agreeing with me
And you agreed with this concept before, too

So this was rather redundant, but hey, it bumps thread!

 

[SCO]

It's the trigger conditions of the script.

Instead of being governed by the dialog saying "you've now completed quest XYZ, now do this", you'd say "you've now have the gasoline added to your inventory, that is needed for script Y, execute it (once)".

One deals with one of the possible ROOT causes of a condition, the other deals with the real CONDITION to do the action XYZ. One will only work if the root cause happens, the other can happen in many ways.

Just decompose the solution condition so it doesn't rely on a root cause, but on the simplest preconditions you can.
Of course, you may want to only do that by a quest - that is a possible condition too.

Most software is underspecified/simplified and full of these "possible cause" taken as the only condition, and since a program does not know nothing you didn't program, most programs are inflexible.

This is a very fine idea, but it's unpractical in a sense - it's antinarrative, as i'm sure you can see. So we plant gasoline in the guy's inventory with our pickpocket skill.
What's he going to say in the floating text? "Thanks for selling me the gasoline?"

It's hard to do narrative without knowing the root cause too. Thus emergent behavior can't narrative rich easily. Some coupling is inevitable.

You are free to ignore this blabber, i don't even know what i don't know

 

[Surf Solar]

Don't worry, all your above said is in. The language is easy to understand to add all of these conditions in a couple of minutes. It's not that only dialogue nodes trigger changes in global vars.

I've made some similar system like in Arcanum for the "Pipboy" (in WR the "Journal") where "you" always scribble some stuff in your book when something "important" is changed. There are messages in for stuff you've normally do quests for, but the npc can get himself killed by some dogs.

Actually, it's better to describe some of the minor quests I have in.

There is a town the player might be interested to get in right after the start of the game. The first NPC he meets is a Scavenger from said town, looting some of the closer farms and stuff for food. The player might normally talk with him, he gives the first starting guides for crafting, exploring and such. If the player has the right build, the scav might give him allowance to even get into his hometown! (it's some perkcheck + CH). The player can threaten him to tell the password to enter the town (only with high strength/endurance at startup plus some trait I will later mention...) If the player has very high charisma and an additional trait, he might just convince said npc to even join you on your travel to this town... The NPC can get slaughtered on his way too, even if he is a crucial one, there is always option 2, 3, or even 4 to advance... The NPC can even be dead before you arrive there (too late...) and the game still goes normally on. Said NPCs health is an indicator (vars....) in many, many other dialogues and quests too, so it is very possible that one player has a totally different story progression to another..

Even if the guy follows you, there's a) the possbility he still get slaughtered by mobs on the way, b) you screw up some minor repair quest by choosing constantly the wrong options or choosing nodes your character at this point can't be experienced, c) you just kill him (only with powerbuilds, trying to limit this a bit, somehow) d) gets killed by another npc on your way to the town. All this can happen without the player actually interfering.


Really, this is just the first 10 minutes of the game, and it is very easy to handle that with many many variables, as long as you are creative enough as the developer.

Maybe I should do some "C&C" video like Vince once did for AoD, but I don't think people would be interested to see 242958294829048 quest runs on "ugly" graphics...


EDIT: What the fuck? 13k views of this thread? oO I love you, codex.

 

[shihonage]

It's the trigger conditions of the script.

Instead of being governed by the dialog saying "you've now completed quest XYZ, now do this", you'd say "you've now have the gasoline added to your inventory, that is needed for script Y, execute it (once)".

One deals with one of the possible ROOT causes of a condition, the other deals with the real CONDITION to do the action XYZ. One will only work if the root cause happens, the other can happen in many ways.

Just decompose the solution condition so it doesn't rely on a root cause, but on the simplest preconditions you can.
Of course, you may want to only do that by a quest - that is a possible condition too.

Most software is underspecified/simplified and full of these "possible cause" taken as the only condition, and since a program does not know nothing you didn't program, most programs are inflexible.

This is a very fine idea, but it's unpractical in a sense - it's antinarrative, as i'm sure you can see. So we plant gasoline in the guy's inventory with our pickpocket skill.
What's he going to say in the floating text? "Thanks for selling me the gasoline?"

It's hard to do narrative without knowing the root cause too. Thus emergent behavior can't narrative rich easily. Some coupling is inevitable.

You are free to ignore this blabber, i don't even know what i don't know

I understood every word of what you said. It's only anti-narrative if you let it be so, however. The solutions to this type of problem usually come from a cheap, cheap place. But cheap isn't always bad.

Sometimes it's as cheap as using "ambiguous phrasing". Other times it affects the entire quest chain profoundly. Yet there are many things that affect game narrative profoundly, and this isn't the worst of them.

In this scenario, the gasoline guy would say nothing. He would thank you for bringing him gasoline, because that's what you did, and because that's the only person who could do it. Where you got it, he doesn't care. The nature of transaction (selling vs. planting), he doesn't care.

In non-computery sense, this system is based around "wants" and "cares". Every NPC has a limited world of things they give a shit about.

For instance, if you stole this gasoline from some gang, the gang will have a problem with missing gasoline. Since they don't know who stole it, they will hire YOU to get them more gasoline.

If they DID know who stole it, they'd trigger a town fight in which you'd have to kill all of them or die. This is NOT ELEGANT, it is ugly, but it is a way to plug the "leak of nonsense" THEN AND THERE (as you're stealing), before it spreads. Sometimes you'll just run into these seemingly simplistic design decisions, and realize that Fallout did it because without them there'd be a SHITTON OF NARRATIVE PROBLEMS.

I've ran into this with my testing of more localized factions and non-lethal combat. It leaves "narrative leaks" where things may stop making sense, and when the game runs into narrative/AI limitations, it just has to seal them off, hard.

These sacrifices have the ultimate payoff - a "containment" system that:

a) doesn't need a lot of regression testing
b) never veers out of context, into "nonsense territory" - your actions always generate at least vaguely understandable result
c) shifts and forms C&C branches dynamically to create unique sequences of events

 

[skyst]

Then it was Deathclaw Age : Fallout.

True. One can only learn from the Masters of RPG at BioWare.

[/quote]

Brilliant pic.

I would say the same of all the work you've posted, actually, can't wait to see it finished.

 

[Surf Solar]

Summer still not over yet, the better half of the team is rather spending her time going out and enjoying the weather, leaving me back as the only true basement dweller - thus my capacities are rather limited.

So I've just dicked a bit around and tried to learn more ropes with 3d modeling, setting up cameras and what not. Stumbled upon this nice scene and maybe consider it to use (although with heavy modifying, adding rubble, tearing holes in the houses, removing those cars etc... ) The tunnel can be used for some dungeon crawling aswell, maybe. Gotta see if it fits to the document I've ready for the old map.

It reminded me a bit of some footage in "The Road" and I got some map which is already finished which I could replace with that scene incase it turns out to be better looking. Let's see. So yeah, only reporting in, showing some life signs.

 

[Surf Solar]

User "Karpov" from the FOnline community contributed another great thing and did the first full "gory death" 3d animation. You can also see how the new 3d-critters look and feel. : http://www.youtube.com/watch?v=dj0rEUk1 ... r_embedded
Shaders, pixelisation etc. isn't working 100% yet, so later the critters will blend better in the background, with still having the good thing that new critter appearances can easily be made, without relying on the old 2d editing method in Fallout 2 modding (redrawing thousands of pictures).

(Non WR) NCR armor 3d model is here: http://www.youtube.com/watch?v=3y3iBGQpX6s

 

[Excidium]

Looks awesome.