Forums » General Pantheon Discussion

A thing I didn't expect.

This topic has been closed.
    • 844 posts
    October 4, 2020 11:29 PM PDT

    Coming from a background in the game industry, DB Admin, Programmer, Eng, etc. when I design interactive programmatical components I try to make things as dynamic as possible.

    What I mean by that wordy sentence is that I would not use "magic values" hardcoded into my code, like an NPC name.

     

    So I was watching the PA5 shakeout video and I noticed something that surprised me.

    Roenick picked up a quest from an NPC named "Blyn Chapman", but the pop-up quest window identified the NPC as "Bonny Chapman".

    This means all aspects of the quest line is being hard coded, manually written in for everything. The quest does not 'dynamically' pick up the NPCs name as a variable and propogate it throughout and quest dialog it's used in.

    To further complicate matters, the resultant quest entry in the player display is also hard coded with a third name version. Blynn Chasmane!

    When I design systems, I dynamically pick up the quest npc's data as an object variable and populate any related content such as name, gender titling, history, etc. So if I change the name of the NPC in my DB, the text in the quest and anywhere else this NPC is used would change automatically. No need to hunt through the pop-up display code, the player quest panel display, and anywhere else this NPC's name might be used. It all looks to be hard-coded in this situation. Which makes for endless work chasing down simple text fixes in an inumerable number of locations.

    You don't think this is a big deal?

    Imagine when there are thousands of NPC's and Quests.

    I have noticed this in other places as well. For example when Roenick gets his quest item, the Wolf Fur Tunic, it states it was created by Master Zavi (the guy that sent him to the leather worker), not by Finn Kalvoy who just gave it to him. Another linkage issue, but a little more tenuous.

    And before the fanbois start slamming me for not realizing it's "PRE-ALPHA", this is a fundamental design aspect that goes in before content starts being created.


    This post was edited by zewtastic at October 4, 2020 11:32 PM PDT
    • 1921 posts
    October 5, 2020 12:11 AM PDT
    Unfortunately, there's no way this turns out positively, zewtastic. :)
    • 220 posts
    October 5, 2020 12:59 AM PDT

    I’ve seen this type of thing happen when those in charge of hiring don't have the programming experience necessary to do proper vetting. 


    This post was edited by Nekentros at October 5, 2020 1:55 AM PDT
    • 633 posts
    October 5, 2020 2:16 AM PDT

    Perhaps they did have it do it dynamically, but it was bugged?

    • 844 posts
    October 5, 2020 3:00 AM PDT

    vjek said: Unfortunately, there's no way this turns out positively, zewtastic. :)

    So sad, and so true.

    • 902 posts
    October 5, 2020 3:04 AM PDT

    zewtastic, I would agree that there shouldn't be hard-coded names, items, locations (etc.) in any text within the game and if there is, then these should be hunted down and removed as soon as possible. The longer issuses such as these are in the game, the more likely it is that those mistakes will remain, making the game feel unfinished and unpolished.

    I would also say it is our responsibility as pre-alpha, alpha and beta testers to hunt these down and log them. 

    Having said that, you cannot deduce that there is a "fundamental design" flaw because of the hard coded name in the title strip though. There could well be (and I would guess) an internal variable available for just this purpose that the quest author should use, but didnt. I would suggest that this is more likely to be an over-sight by the quest author than a fundamental issue. It is an issue, but it is a QA issue only.

    Well spotted for identifying the above, but give VR the chance to set it right before concluding that there are fundemental problems; without knowing what is available to the team we are just guessing.


    This post was edited by chenzeme at October 5, 2020 3:05 AM PDT
    • 844 posts
    October 5, 2020 3:12 AM PDT

    Nekentros said:

    I’ve seen this type of thing happen when those in charge of hiring don't have the programming experience necessary to do proper vetting. 

    I would conjecture this is more an issue with trying to do big things with a tiny studio, where individuals end up wearing multiple hats none of which they may be expert in.

    • 844 posts
    October 5, 2020 3:20 AM PDT

    kelenin said:

    Perhaps they did have it do it dynamically, but it was bugged?

    A bug doesn't come up with three different names.

    It's an architecture design aspect.

    But it could be changed. I have no idea how they have designed their DB's and it's integration, but I'm sure changes could be made. Unknown how complex and labor intensive that would be, and how it would play with other hard-coded aspects.


    This post was edited by zewtastic at October 5, 2020 3:26 AM PDT
    • 633 posts
    October 5, 2020 3:42 AM PDT

    I agree it looks like way, and may be that way.  But you're making an assumption about their code without seeing it.  Also, who says using variables is better?  Sure it has the aspect of allowing more dynamics (such as changing NPC names auto changing anything that relies on it), but on the other hand that is less performant than having hard-coded values as it would have to do extra lookups of data when people interacted with the NPCs, extra string merging, and therefore extra garbage collection at some point.

    I would normally do what you're saying as well, but I don't design games that have to provide instant responses to tens of thousands of users for each and every action they perform.  And I wouldn't assume they don't have their reasons for doing it however they did do it since I wasn't in their design meetings.

    And you say you don't want to hear about it being pre-alpha, but what if they haven't introduced the ability to insert variables into certain aspects yet, like quest text?  You do realize that they cannot have everything in place, because if they did we wouldn't be doing pre-alpha.  We'd likely be in alpha because all fundamental items are in and need to be tested before mass content is created.

    My point is nobody outside can look at their program and make a blanket "They coded it wrong" without knowing the reasons why they did it the way they did.  I would do it the way you mentioned.  Maybe they plan to.  Maybe they did and it's bugged.  Maybe they want to hard-code it for performance reasons.  Who knows?  And ultimately as long as the end-product works well and they can maintain it in a way they like, we as players shouldn't care how they coded it.

    • 2138 posts
    October 5, 2020 7:38 AM PDT

    But if it is as the OP mentions then , whoah. Talk about community. Testing from the forums 0_o  QA from the forums! . What an earnest bunch- no seriously! No wonder there are no playable trolls in pantheon figuratively and literally, lol. 

    • 3852 posts
    October 5, 2020 8:11 AM PDT

    What zewtastic says sounds right but I don't know enough to be sure there cannot be some other explanation. Perhaps certain things in the shakeout were done manually to get them out the door in time for the test, without this being the long term approach.

    Of course this would raise other questions about how ready things actually are for even a PA test much less the alpha we hope will follow. So it may be a lot better if this is not the case.

    • 724 posts
    October 5, 2020 9:09 AM PDT

    Good find!

    It could also be that the quest designer here didn't know how to use the "insert quest NPCs name into text" feature. If that's the case, that problem should be fixed quickly - before they start coding all those quests!

    • 368 posts
    October 5, 2020 9:10 AM PDT

    As a self proclaimed IT and software professional you ought to know better than to think they are hardcoding npc / quest dialogs into the game. Clearly they need to do some verification on their string resources to make sure that different string collection entries are referencing the same or appropriate contextual verbage. But that should be an easy fix, and not something that should be critical at this point. But to assume they are trying to hardcode dialog trees from beginning to end is fairly ignorant for a scope this size. Especially when in-fact, you have no direct knowledge and have not seen the code base. Did your mother ever teach you what happens when you assume something?

     


    This post was edited by arazons at October 5, 2020 9:20 AM PDT
    • 844 posts
    October 5, 2020 10:41 AM PDT

    arazons said:

    As a self proclaimed IT and software professional you ought to know better than to think they are hardcoding npc / quest dialogs into the game. Clearly they need to do some verification on their string resources to make sure that different string collection entries are referencing the same or appropriate contextual verbage. But that should be an easy fix, and not something that should be critical at this point. But to assume they are trying to hardcode dialog trees from beginning to end is fairly ignorant for a scope this size. Especially when in-fact, you have no direct knowledge and have not seen the code base. Did your mother ever teach you what happens when you assume something?

    "Clearly they need to do some verification on their string resources to make sure that different string collection entries are referencing the same or appropriate contextual verbage. But that should be an easy fix, and not something that should be critical at this point."

    So now you're a self-proclaimed expert? Doing exactly what you accuse me of?

     

    • 844 posts
    October 5, 2020 10:58 AM PDT

    Watch the video yourself.

    https://www.youtube.com/watch?v=6DiyWMGlT58

    Perkins: "The NPC's are very intelligent - And they need to be... built on a deep matrix of flagging that take into account the things you've done... Very large array of details."

    Now this is what I would expect. Each player character has to have a [potentially large] data object that details everything about them. Everything they've done and interacted with, name, class, factions, health, history, etc. Including what quests they've seen, how far into it they are, what steps they completed, what possible perception points they've seen.

    By the same logic each quest, npc, POI, interactable item also should have a data object that can interact with each other.

    Is the problem as simple as someone working on quests doesn't know how to insert the object variable for an NPC name (and other object variables) in all connected areas? Possible. But why? And it still requires going and fixing all those entries. makes no sense to me this many years into development.

     

    Another small observation from the Dire Lord video. They recently changed the attribute "Intelligence" to "Intellect", yet on the character creation panels it's still Intelligence. Another hard-coded value.

     

     

    • 1281 posts
    October 5, 2020 11:37 AM PDT

    If this is true, it's very interesting. Jason Weimann was really against this type of thing (for dynamically pulling ID's from database) and he was on the PROFT team for a couple years. Hard to imagine he would let it slip by.

    I think what's more likely true is that these GUI elements are just placeholders that they quickly threw together to show you what the final product is going to look like.

     


    This post was edited by bigdogchris at October 5, 2020 11:38 AM PDT
    • 368 posts
    October 5, 2020 12:53 PM PDT

    zewtastic said:

    arazons said:

    As a self proclaimed IT and software professional you ought to know better than to think they are hardcoding npc / quest dialogs into the game. Clearly they need to do some verification on their string resources to make sure that different string collection entries are referencing the same or appropriate contextual verbage. But that should be an easy fix, and not something that should be critical at this point. But to assume they are trying to hardcode dialog trees from beginning to end is fairly ignorant for a scope this size. Especially when in-fact, you have no direct knowledge and have not seen the code base. Did your mother ever teach you what happens when you assume something?

    "Clearly they need to do some verification on their string resources to make sure that different string collection entries are referencing the same or appropriate contextual verbage. But that should be an easy fix, and not something that should be critical at this point."

    So now you're a self-proclaimed expert? Doing exactly what you accuse me of?

     

    You still havent seen their code, and you will likely never see it, nor will I. So making assumptions based on very loose observations from a pre-alpha video its just a bit of a stretch to me.

    As a self proclaimed IT and software professional "you ought to know better than to think they are hardcoding npc / quest dialogs into the game"

    You completely disregard the substance of the statement, it really had nothing to do with your self proclaimed expertise, I assumed that you were knowledgeable on the topic and was giving you the benefit of the doubt in that regards. But, I stand by the rest of the statement that as a professional yourself, you should know that they are likely not trying to hardcode every npc/quest dialog into the game. You know it just wouldnt work out well if they tried. I know that, and they cant be that dumb to not know that.

     

     


    This post was edited by arazons at October 5, 2020 1:18 PM PDT
    • 392 posts
    October 5, 2020 1:06 PM PDT

    This is the type of details they would be looking for while VIPs test, without a reply from the devs though its hard to say what or why its setup like this.

    My hope is that the shown quests arent finalized and they just tossed the NPC/windows together real fast without linking them to any of the databases just for the stream/build.

    • 368 posts
    October 5, 2020 1:08 PM PDT

    The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

    • 633 posts
    October 5, 2020 1:10 PM PDT

    Well if you're in Pre-Alpha and you see something like this you believe is a bug.  You report it.  Doesn't matter how it's set up, or how you think it should be.  Just report it as you see it and let them figure out the logistics of how they want to fix it or achieve the results technically.

    What the OP did as far as if this was a report saying he feels it's not correct was awesome, would have been a good bug report without the technical details.  Including screenshots and a description of the problem, and what the expected result should have been.  Just the assumption that anyone knows how things were done internally is the part I don't agree with.

    • 902 posts
    October 6, 2020 1:28 AM PDT

    For those without coding experience I provide a simplified example of the kind of problem encountered above

    Pseudo Code (with no particular coding language in mind):

    set questGiverName = "Joe Bloggs" -- set a variable called questGiverName so it contains the name Joe Bloggs

    set questPage1.Title = questGiverName -- set the title of the quest page 1 to the contents of the variable "questGiverName", i.e. Joe Bloggs

    set questPage2.Title = "Joey Bloggs" -- set the title of the quest page 2 to "Joey Bloggs", this is the "hard coded" value. 

    set questPage3.Title = questGiverName -- set the title of the quest page 3 to the contents of the variable "questGiverName", i.e. Joe Bloggs

    questPage1.ShowPage

    questPage2.ShowPage

    questPage3.ShowPage

    Now questPage1 and questPage3 will show Joe Bloggs in the title but questPage2 will show Joey Bloggs. This is not a fundamental flaw, it is just that questPage2 should have been set with the variable questGiverName and not hard coded.

    The real problem is that if the quest giver's name is changed to say "Jill Bloggs" then we can change the code string questGiverName = "Joe Bloggs" to string questGiverName = "Jill Bloggs" and both questPage1 and questPage3 will be updated with the new name, but questPage2 will still show Joey Bloggs. This means that someone has to hunt through all the pages and manually update the names of any other pages that do not use the variable. Obviously, with 1000s of quests, this will prove to be very very time consuming.

    Ideally questPage2 should also be using the variable and not the hard coded value. Yes it is a bug. No it is not a fundamental design flaw with the coding, it is just an authoring QA issue.


    This post was edited by chenzeme at October 6, 2020 2:22 AM PDT
    • 844 posts
    October 6, 2020 4:49 AM PDT

    My quess is they are still using Lua for NPC functionality.

    A 25+ yo. scripting language that Brad used in EQ1, Vanguard, and most likely in Pantheon.

    It is a highly popular language to use for such applications and many games historically have used it.

    • 1921 posts
    October 6, 2020 7:36 AM PDT

    chenzeme said:

    For those without coding experience I provide a simplified example of the kind of problem encountered above

    Pseudo Code (with no particular coding language in mind):

    set questGiverName = "Joe Bloggs" -- set a variable called questGiverName so it contains the name Joe Bloggs

    set questPage1.Title = questGiverName -- set the title of the quest page 1 to the contents of the variable "questGiverName", i.e. Joe Bloggs

    set questPage2.Title = "Joey Bloggs" -- set the title of the quest page 2 to "Joey Bloggs", this is the "hard coded" value. 

    set questPage3.Title = questGiverName -- set the title of the quest page 3 to the contents of the variable "questGiverName", i.e. Joe Bloggs

    questPage1.ShowPage

    questPage2.ShowPage

    questPage3.ShowPage

    Now questPage1 and questPage3 will show Joe Bloggs in the title but questPage2 will show Joey Bloggs. This is not a fundamental flaw, it is just that questPage2 should have been set with the variable questGiverName and not hard coded.

    The real problem is that if the quest giver's name is changed to say "Jill Bloggs" then we can change the code string questGiverName = "Joe Bloggs" to string questGiverName = "Jill Bloggs" and both questPage1 and questPage3 will be updated with the new name, but questPage2 will still show Joey Bloggs. This means that someone has to hunt through all the pages and manually update the names of any other pages that do not use the variable. Obviously, with 1000s of quests, this will prove to be very very time consuming.

    Ideally questPage2 should also be using the variable and not the hard coded value. Yes it is a bug. No it is not a fundamental design flaw with the coding, it is just an authoring QA issue.

    Good example.
    Would you say that it's an implementation issue, then, if not a design flaw?

    • 902 posts
    October 6, 2020 8:16 AM PDT

    vjek: Would you say that it's an implementation issue, then, if not a design flaw?

    Yes, an implementation of the quest.

    • 1921 posts
    October 6, 2020 9:49 AM PDT

    On any coding project I've been a part of (using Unity or not), this particular implementation detail is the direct result of following (or not) coding best practices, as defined by the team involved, and the design goals of the project.  It also reflects the skill and/or experience of the implementer.
    Put another way, this isn't a one-off thing.  No-one should be permitted to hard code these types of things once, never mind three times, if that's the defined coding guideline for the project.
    In general, as far as a modern methodology goes, hard coding anything like this into any client is just a bad idea.
    Even modern forum software, being implemented on top of or within a web client and a web server model, stores pretty much everything within the underlying database and at rendering time (rendering the web page to the client) isues a SQL query to pull the values out of a table and then displays those results in various placeholder locations on the page.  The templates that are used to display pages are simply a bunch of variable references.

    I know everyone in this community is in super-zealot-defense-mode-activate! , yet, what zewtastic has pointed out isn't a one time error.  It's repeated several times.
    As such, if I was the one doing a code review or if I was the scrum master, agile lead, boss-man, head-honcho, big-cheese, or whatever other term you want to apply to the guy in charge, and I saw this?
    It would be brought up as an example of what not to do, and a coaching opportunity for whatever developer, designer, coder, or programmer typed these lines in this language so they wouldn't repeat this mistake.

    I completely understand the idea that, like many other non-big-publisher projects, this is a small team of apparently 6 "coders" or reasonable hand-drawn facsimiles of "coders".  Even so, and fully comprehending and understanding the context of pre-alpha 1,2,3,4,5 and almost 7 years of development effort, this gives the impression of a rookie mistake from a team of veterans.
    On one hand, I again, completely understand the desire of people to see development as it happens.  Yet, first impressions are important.  Public first impressions, even more so.  If this was a potential customers first impression of Pantheon, they could get the wrong impression, based on what zewtastic has highlighted here. 
    As such, IMHO, it would be better to ensure mistakes like this don't make it into the public builds, in the future.