Mord Sith said:
AoD is supposed to come out this year.
Also, Final Fantasy is utter shit.
Thank you.
Emil is back
- Thread starter Brother None
- Start date
AoD is supposed to come out this year.
Also, Final Fantasy is utter shit.
Thank you.
Mord_Sith
Mildly Dipped
I haven't been fond of anything since 6 (Yeah you heard my you FF7 Fanbois) so I can partially agree with you Wooz.
But it's still closer to a cRPG than PAGES is going to be.
But it's still closer to a cRPG than PAGES is going to be.
Soulforged
First time out of the vault
A video game is at its core a piece of software, its purpose goes beyond simple utility but that doesn't change what it is. Sometimes when you develope software it's necessary to apply certain restrictions to keep your code from breaking, or in this scale, a whole lot of quests. Some times it's very difficult to near impossible to foresee all the consequences of a little change in a piece of code, therefore it's safer and better to apply these restrictions.Wooz said:
I sympathize but as I said this is software development first, roleplaying later, at least if you want to be realistic. There are many bothersome nuances in programming and they do not relax on games particularily. Notice that I'm not even talking on artistic design implementation, ideology or quest implementation, I'm talking about more essential things to all programs, on small scales they're predictable enough that you can almost do whatever you want, on this scale however, the very fact you're using several threads to run your rutines already takes that simplicity away.whirlingdervish said:
Mord_Sith
Mildly Dipped
Programming Nuances yes, but but killing off a quest giver shouldn't crash the game, internal databasing is where this comes in, it's quite simple, when making a quest with dependencies, make a dependencies join table and every new game creates a new dependency tree.
When a dependency is unfinished OR failed, it doesn't trigger the next quest, you're thinking of it in a 'what if it triggers' the point is that you don't set it to trigger unless all conditions are met.
If for example, you have a basic Fed-Ex quest, talk to quest giver A, get the quest, kill quest giver A, when you talk to quest completer A to do the Fed-Ex, if the dependency is that the giver must live for the scenario to be completed then they fail.
It's a simple logic check, it's not that hard, I do databasing and web coding for a living and when you start doing conditionals in SQL as well as 3-4 inner table joins successfully ordered by company and timestamp let me know.
I don't know the intricacies of C based programming save Java, however I do know that the Nuances you mention, are not from the code, they're from sloppy coding.
When a dependency is unfinished OR failed, it doesn't trigger the next quest, you're thinking of it in a 'what if it triggers' the point is that you don't set it to trigger unless all conditions are met.
If for example, you have a basic Fed-Ex quest, talk to quest giver A, get the quest, kill quest giver A, when you talk to quest completer A to do the Fed-Ex, if the dependency is that the giver must live for the scenario to be completed then they fail.
It's a simple logic check, it's not that hard, I do databasing and web coding for a living and when you start doing conditionals in SQL as well as 3-4 inner table joins successfully ordered by company and timestamp let me know.
I don't know the intricacies of C based programming save Java, however I do know that the Nuances you mention, are not from the code, they're from sloppy coding.
whirlingdervish
Brahmin Cavalry Commander
Im pretty capable with c++ myself, and I don't get where he's going with that.
The ability to code the consequences exists and has for some time, even in a huge (so they say) world like oblivion's.
If the game world and it's related quests (and other shit you can actually affect by choice) were intricate and huge, maybe there would be a problem that would take some tricky coding and some huge arrays and matrixes of quest related npcs and objects to handle. Unfortunately for all parties involved, Bethesda only seems capable of doing one or the other. (big or intricate)
My comment was more of the "They aren't even giving us 3 options to choose from" type.
I don't see complexity being a problem since the incredibly simple "yes"/"no"/"oops killed the wrong guy" options are more than we can expect those tables of data to have.
From what I've seen of the game so far, the occasional grey area of being an apathetic do-nothing PC is going to be something to look forward to because of the overflow of incredibly linear quests with only a good and bad option. (do it or not, kill him or that guy instead, etc.)
We aren't going to have all that many choices of multiple ways to beat a quest, or multiple small things we can do in X location to affect how person Y treats us and so on.
that's not what I call role playing.
that's called flipping a coin and occasionally walking away from an NPC who's blathering on about some shit they can't seem to get themselves and expect you to fetch.
the complexity that would make coding such a quest checking system difficult, just isn't there as far as I can tell, from the reliable sources of information we have so far.
The ability to code the consequences exists and has for some time, even in a huge (so they say) world like oblivion's.
If the game world and it's related quests (and other shit you can actually affect by choice) were intricate and huge, maybe there would be a problem that would take some tricky coding and some huge arrays and matrixes of quest related npcs and objects to handle. Unfortunately for all parties involved, Bethesda only seems capable of doing one or the other. (big or intricate)
My comment was more of the "They aren't even giving us 3 options to choose from" type.
I don't see complexity being a problem since the incredibly simple "yes"/"no"/"oops killed the wrong guy" options are more than we can expect those tables of data to have.
From what I've seen of the game so far, the occasional grey area of being an apathetic do-nothing PC is going to be something to look forward to because of the overflow of incredibly linear quests with only a good and bad option. (do it or not, kill him or that guy instead, etc.)
We aren't going to have all that many choices of multiple ways to beat a quest, or multiple small things we can do in X location to affect how person Y treats us and so on.
that's not what I call role playing.
that's called flipping a coin and occasionally walking away from an NPC who's blathering on about some shit they can't seem to get themselves and expect you to fetch.
the complexity that would make coding such a quest checking system difficult, just isn't there as far as I can tell, from the reliable sources of information we have so far.
Soulforged
First time out of the vault
You could have a memory management issue in that case, though that is a possible solution.Mord_Sith said:
The problem is this, I don't know how far are they going with RAI this time. Suppose that this time around RAI is in fact so advanced that object A, a person, trivial, has low responsability (that's how they manage NPC-environment interaction) and decides to kill an important character called B, who's important by the fact that he's an essential link in the main quest (if there's such a thing). Even if B could get replaced ad infinitum with a series of characters who could all reasonably provide you the same service you wouldn't want such an essential character destroyed. The PC could do the same without knowing the importance of such character, and suddenly you've no more game, practically speaking.
I develope software too, with Java, but I cannot compare what I do (mostly fiscal applications) with something as big as a game, even the graphical engine is infinitely more complex than anything I could wrap my mind around at this moment.
Yes they're from sloppy coding, but sloppy coding isn't completly avoidable, and its consequences escalate easily under the right conditions.
Mord_Sith
Mildly Dipped
True enough, but the engine isn't what we're talking about, we're talking about the interaction, the engine tells the NPCs how to act, how to display the environment, what tools they're given to develop the rest of the game, as well as model hookups etc.
The engine hooks up to every part of the game, however it does not influence things like PC action-reactions, dialog trees, NPC counts, etc, an engine is a framework that the gaming company builds around.
Besides, memory management problems, what in the blue blazes do you think a save file is?
It's a database file that the game reads and it stores everything about your character.
As for sloppy coding being unavoidable, it is avoidable, if everyone stuck to doing their documentation on top of the coding, but being a programmer yourself, you should know how often documentation is done.
However, blaming the engine for a design company's laziness, is pure and utter bullocks, the engine (once again) is a framework, if it's C++ Based, and you need something specific that the engine can't do, you make a MODULE, or a FUNCTION, you should know this.
As for Fiscal Applications, there is heads and tails more calculations done on a corp grade bookkeeping program for balancing purposes, not to mention how many decimal places they calculate to, it's effing insane and gives me headaches when I look at anything to do with accounting, and I love logic puzzles. Something about reverse math makes my head all spinny...
The engine hooks up to every part of the game, however it does not influence things like PC action-reactions, dialog trees, NPC counts, etc, an engine is a framework that the gaming company builds around.
Besides, memory management problems, what in the blue blazes do you think a save file is?
It's a database file that the game reads and it stores everything about your character.
As for sloppy coding being unavoidable, it is avoidable, if everyone stuck to doing their documentation on top of the coding, but being a programmer yourself, you should know how often documentation is done.
However, blaming the engine for a design company's laziness, is pure and utter bullocks, the engine (once again) is a framework, if it's C++ Based, and you need something specific that the engine can't do, you make a MODULE, or a FUNCTION, you should know this.
As for Fiscal Applications, there is heads and tails more calculations done on a corp grade bookkeeping program for balancing purposes, not to mention how many decimal places they calculate to, it's effing insane and gives me headaches when I look at anything to do with accounting, and I love logic puzzles. Something about reverse math makes my head all spinny...
patriot_41
Where'd That 6th Toe Come From?
Wait, what? 
If it was possible in '98 why isn't it possible 10 years later? Fallout 2 was beatable with killing nearly every NPC. As far as I remember, the Elder shouldn't be killed, and Tully and the Bridgekeeper were unkillable because of a design decision.
And in FO1 the Overseer can be killed in the end of the game.
If it was possible in '98 why isn't it possible 10 years later? Fallout 2 was beatable with killing nearly every NPC. As far as I remember, the Elder shouldn't be killed, and Tully and the Bridgekeeper were unkillable because of a design decision.
And in FO1 the Overseer can be killed in the end of the game.
Let's not forget Arcanum- wasn't every NPC killable in Arcanum, no exceptions?patriot_41 said:Wait, what?
If it was possible in '98 why isn't it possible 10 years later? Fallout 2 was beatable with killing nearly every NPC. As far as I remember, the Elder shouldn't be killed, and Tully and the Bridgekeeper were unkillable because of a design decision.
And in FO1 the Overseer can be killed in the end of the game.
Soulforged
First time out of the vault
I stand corrected.Mord_Sith said:
True, but I can "forget" to document sometimes.
I didn't blame the engine though, what I'm saying is that the engine is so complex that the consequences on a game of such scale are very hard to foresee when you start making changes.
That could be true, I don't know, for me it only takes a look at how graphics and physics have gotten today to realize how complex the logic and the math behind it might be.
Mord_Sith
Mildly Dipped
True, but that's a physics engine module, they don't even code that anymore, they're likely going to tweak and slap it into Fallout.
At least that's if they're doing proper Object Oriented Coding.
This isn't an earth moving change, it's modifying what should exist in the NPC module, if it doesn't, they should re-build that module of the engine and attach it, as dialog is one of the weakest parts of Oblivion.
However they have a decent dialog interpreter, you can have quite a few different dialogs in the box, it's just that they didn't design a fully fleshed dialog tree.
Ok here's a database 101:
When calling from a database and pulling all relevant information for a particular event you have limiters set up in the database call. Databases can handle a significant amount of records in them (I'm looking forward to handling over 25,000 people across Canada for their grads this spring -.-) as long as the database is built correctly.
To connect the Conditions in a gaming example, to the Dialogs, you would need a third join table designed to create the many to many relationships between these two tables (there are many dialogs that have conditions, and many conditions per dialog.)
From there you connect in the join table with a third column, Actor ID that connects a specific set of Dialogs and Conditions to any one actor (or NPC) in the game.
The primary key on the join table is a compound key of all three fields, this prevents duplicate dialog conditions for the same person from cropping up and speeds up indexing.
--End Lesson--
So you see that it's really not that hard to have a small database for character interaction requirements that COULD include a NPC's death, or lack thereof.
The Immortals, are not a design limitation, they're a design choice, they don't want to make it so the XBrick kiddies can kill off their major plot line givers to avoid a flood of ignorant callers saying 'I broke my game because I shot XXX guy, FIX IT!'
They're programming for the lowest common denominator, and that my friends, is the stupids of the world, they call it a design limitation because they don't want to have to explain their decision that could potentially offend someone, they do need to look out for getting potentially sued for some of this kinda talk that I can get away with.
It's the same with Web Design, it's not a nice thing to say, but you gotta program it so that a trained chimp can use it, and even then you're going to get people asking questions about it.
At least that's if they're doing proper Object Oriented Coding.
This isn't an earth moving change, it's modifying what should exist in the NPC module, if it doesn't, they should re-build that module of the engine and attach it, as dialog is one of the weakest parts of Oblivion.
However they have a decent dialog interpreter, you can have quite a few different dialogs in the box, it's just that they didn't design a fully fleshed dialog tree.
Ok here's a database 101:
When calling from a database and pulling all relevant information for a particular event you have limiters set up in the database call. Databases can handle a significant amount of records in them (I'm looking forward to handling over 25,000 people across Canada for their grads this spring -.-) as long as the database is built correctly.
To connect the Conditions in a gaming example, to the Dialogs, you would need a third join table designed to create the many to many relationships between these two tables (there are many dialogs that have conditions, and many conditions per dialog.)
From there you connect in the join table with a third column, Actor ID that connects a specific set of Dialogs and Conditions to any one actor (or NPC) in the game.
The primary key on the join table is a compound key of all three fields, this prevents duplicate dialog conditions for the same person from cropping up and speeds up indexing.
--End Lesson--
So you see that it's really not that hard to have a small database for character interaction requirements that COULD include a NPC's death, or lack thereof.
The Immortals, are not a design limitation, they're a design choice, they don't want to make it so the XBrick kiddies can kill off their major plot line givers to avoid a flood of ignorant callers saying 'I broke my game because I shot XXX guy, FIX IT!'
They're programming for the lowest common denominator, and that my friends, is the stupids of the world, they call it a design limitation because they don't want to have to explain their decision that could potentially offend someone, they do need to look out for getting potentially sued for some of this kinda talk that I can get away with.
It's the same with Web Design, it's not a nice thing to say, but you gotta program it so that a trained chimp can use it, and even then you're going to get people asking questions about it.