Aliens don't have beards don't be ridiculous!

 

And the Onyx engine supports facial animations/expressions/lip-syncing, yes.

Aliens don't have beards don't be ridiculous!

 

And the Onyx engine supports facial animations/expressions/lip-syncing, yes.

i will be interested in the X-mas special edition, with an alien masqueraded as Santa Claus!

That's great news. I take HL2's (or Bloodlines for that matter) facial animation capabilities over fancy graphics anyday.

 

As this is going to have both it is win-win situation

HL2's face animations was indeed win imo, so it sure is win. Win equals win.

 

Cratetracking, btw?

Edited June 15, 200817 yr by Accept

I thought ME's facial expression is impressive by its own right. Furthermore the face that makes the variety of expressions is customisable to boot.

 

But again, unlike Half-Life 2, ME's face gen is a middleware which pretty much cost a bomb to have it featured in it.

I still think we should have called it OnyxBeast...

I still think we should have called it OnyxBeast...

 

Illuminate Labs' Beast lightning solution?

 

http://www.beyond3d.com/content/pr/112

 

http://www.illuminatelabs.com/

 

By incorporating Illuminate Labs

Clearly, Steelyx is the best name for evolved Onyx:

I'm giving this presentation in about an hour and I just discovered that our conversation editor has "trouble" displaying node banks in Vista.

 

w00t

Come on Josh, you can do it!

I'm giving this presentation in about an hour and I just discovered that our conversation editor has "trouble" displaying node banks in Vista.

 

w00t

 

... Little late in the day for finding that out wouldn't you say?

Hmmm. Sounding pretty good if its the one.

 

You are reading too much into Anthony's post. The Onyx Engine has nothing to do with Beast lighting middleware.

 

As for the Vista issue - right now the majority of the team is running XP, so I wouldn't be surprised to find issues with tools at this point in the project when running Vista. Yeah, it still stinks for J.E.S. though.

Can't be helped. Its all of you peeps faults for being so mystarious with info.

 

Thus speculation horrors will reign until then. ^.^

Edited June 24, 200817 yr by Zoma

Hmmm. Sounding pretty good if its the one.

 

You are reading too much into Anthony's post. The Onyx Engine has nothing to do with Beast lighting middleware.

 

As for the Vista issue - right now the majority of the team is running XP, so I wouldn't be surprised to find issues with tools at this point in the project when running Vista. Yeah, it still stinks for J.E.S. though.

 

I think the game industry should take a stand and refuse to develop for Vista.

 

I mean, it'd probably save you money with all the testing you wouldn't have to do; you don't use Vista, most of your customers don't use Vista, and the ones who do are only using it because they think you will make your games for it.

 

Mwahahahaha

But what poor little me?

 

I just divorced XP and married Vista. Will I not get my social welfare benefits too?

... Little late in the day for finding that out wouldn't you say?

It wasn't really a big deal. The more important aspect of the conversation editor portion of the presentation was showing our node "flowchart". The total effect was hampered a bit by having a 1024x768 projector, but it seemed to go over pretty well.

Glad it worked out .

 

I do find it interesting that a new approch to designing dialogue flow is taking place, from an organisational point of view I never particularly liked "tree's", the idea of a more state machine based approch does have a percieved overall impact on the complexity of the resulting dialogue sequence.

 

That said I suppose functionally speaking it's more of less the same from an internal point of view, but I do imagine that it will allow for more complex dialogue to take place, with more "branching" due to the tools design itself.

 

So that leads me to my question... Does the tool allow for more complex dialogue sequence's due to better organisation and flow?

I think the game industry should take a stand and refuse to develop for Vista.

 

totally agree

Thread pruned again. Enough with the mutual baiting and trolling guys.

 

In the voice of Michelle Dubois from 'Allo 'Allo : Listen very carefully, I shall say this only once.

Does the tool allow for more complex dialogue sequence's due to better organisation and flow?

 

I think it only makes the dialouge of that rate of complexity be created a lot quicker than usually ( devs, correct me if i'm wrong )

So that leads me to my question... Does the tool allow for more complex dialogue sequence's due to better organisation and flow?

I can't really say for sure. I think it makes the visual organization of nodes much more distinctive and intuitive, but I don't think there's necessarily any complexity it allows for that a tree-style editor technically couldn't handle. One powerful new Onyx conversation editor feature that Josh Verrall added (that unfortunately I was unable to show due to technical issues) was the node bank editor. Its usage is a bit specific, but it can dramatically cut down the amount of time a designer needs to spend plotting out node relationships.

 

It's pretty common in Obsidian games for companions to pipe up with side comments on your behavior. Sometimes these comments spawn full side conversations, but usually they are "one-offs" that may modify and influence level or set a flag. We often structure our conversations so that all participating characters fall through a cascading tree in such a way that there is essentially only one way to go through it for any given set of characters.

 

Let's say we have a cast of six companions in a game. I want four to potentially respond to this comment:

 

PC: "You're an idiot, Mr. Fancy."

> Jake: Hey, don't talk to Mr. Fancy like that.
  > Bob: I never liked Mr. Fancy anyway.
  > Sarah: Oh, poor Mr. Fancy!
	  > Satan: I love fire.

		  > Mr. Fancy: Your reproach cuts to my very soul, monster!

 

And we would probably structure these nodes such that it checks first for Jake's presence and plays his node if true, then Bob's if he is present, then Sarah's if she is present, then Satan, and finally Mr. Fancy. Absent party members are skipped. Without using some trickier logic, no individual companion can respond to another because the line to which they respond may be rendered invalid by that previous line's speaker being absent -- that isn't to say it is difficult logic to implement, but the designer now has to deal with an exploding multiplicity of conditions and connections to the nodes around each companion's reply. In short, it must be used sparingly for logistical reasons.

 

WELL MOVE OVER, GRAMPS! Node linking just got... crazy.

 

Basically a node bank encapsulates a group of nodes, any nodes the designer wants, really. When a node bank is hit, the cascading logic within the bank's member nodes is only valid for that bank. Once a single node's conditions have been met, that node is played and the conditions on the links from the bank are followed as though they came for a single node.

 

So... who cares? Okay, basically this allows a designer to group a bunch of nodes with similar emotional themes or impact and then transition to a set of varied exits or even another node bank with a tiny number of virtual links. So, let's say you had 10 potential companions and they can all have an opinion on how you treat Mr. Fancy.

 

Likes Mr. Fancy:

Frank

Bob

Bill

Joanne

Margaret

 

Dislikes Mr. Fancy:

Tim

Jack

Sassy

Olivier

 

Neutral:

Satan

 

From my initial negative response to Mr. Fancy, I could create one node bank with all of the "Likes Mr. Fancy" companions piping up -- probably in order of strength of opinion. So if Margaret liked Mr. Fancy the most, followed by Frank with Joanne being only slightly positive, the bank would look like this:

 

Margaret: Arrrgh! Why are you so mean to Mr. Fancy?!?!

Frank: What the heck is wrong with you?

Bill: Whoa, that was harsh.

Bob: Ease up, bro.

Joanne: He's not that bad.

 

The dislikers respond in this way, to those who like Mr. Fancy:

 

Sassy: Huh? That guy sucks. Seriously, he's terrible.

Olivier: You're defending Mr. Fancy? Whatever, man.

Jack: The guy's not that great.

Tim: I don't really like him, either.

 

And Satan says:

 

Satan: I like fire.

 

The node bank structure would probably look like this:

 

 PC Negative Response --> Positive reply bank --> Negative reply bank to positive reply --> Mr. Fancy reply
				--> Satan's reply --> Mr. Fancy's reply

 

If the party composition were Frank, Bill, and Tim, the conversation would go like this in game:

 

PC: "You're an idiot, Mr. Fancy." --> Frank: "What the heck is wrong with you?" --> Tim: "I don't really like him, either." --> Mr. Fancy: "Your reproach cuts to my very soul, monster!"

 

If the party were Margaret, Joanne, Satan.

 

PC: "You're an idiot, Mr. Fancy." --> Margaret: "Arrrgh! Why are you so mean to Mr. Fancy?!?!" --> Mr. Fancy: "Your reproach cuts to my very soul, monster!"

 

If Sassy and Satan:

 

PC: "You're an idiot, Mr. Fancy." --> Satan: "I like fire." --> Mr. Fancy: "Your reproach cuts to my very soul, monster!"

 

I'd probably also put in a negative node bank for "stand alone" replies if only characters with a negative opinion on Mr. Fancy were in the party (well, those guys and Satan, since his reply is pretty worthless and immaterial). The important thing is that the writer's main job stays writing, with a lot of potentially complex interconnectivity and response logic smoothed out to allow for more character combinations. If you try mapping out all of the potential logic for this in a traditional tree structure editor, it gets messy.

 

The net result for the player, from a practical perspective, is that it's more likely that any combination of characters they have can respond, and in turn respond to another character's response, at any given point in dialogue.

I see. So the overall result is not so much the complexity of the conversation, but a more robust and complete system which is easier to control from a design perspective. The fact that conversations are likely to be more complete quicker must surely end in the simple fact that, better tools = more content, specifically in this case.

 

For some reason I had the impression the tool would allow for nodes to communicate over conversations so to speak, this may still be the case of course, but I thought the likelyhood of an impact taking place over perhaps several conversations to be more likely. There is always the chance of this already is in place with a tree based system + script (the end of NWN2 springs to mind). I do imagine maintaining it is likely to be a bit of a nightmare, and hence I thought that the system you're speaking of actually made such a process easier, and still could very well be the case.

 

I'm certainly looking forwards to sampling the end result.

hmm... "Satan" sounds a bit like our favourite KOTOR droid

The primary advantage to Sawyer's system appears to be that it is much easier to design, and it's much easier for the player to see, companions who not only throw in inconsequential jibes but really be a part of the conversation. Sounds great, actually.

Hmmm. Sounding pretty good if its the one.

 

You are reading too much into Anthony's post. The Onyx Engine has nothing to do with Beast lighting middleware.

 

 

at first i thought this said:

"You are reading too much into Anthony's post. The Onyx Engine has nothing to do with Breast lighting middleware."

 

i was all " wtf? did you guys suddenly get infected with the Korean MMO disease!"

Edited July 3, 200817 yr by sogi_ya