Hah hah hah! The little realities of computer game making

[temnix]

I was looking through the files for the Spider's Bane quest in BG1, in Cloakwood, where the party is supposed to bring the body of the dead brother, Chelak. Glanced through the dialogue of the alive brother, Tiber. And I noticed that the last actions there, in the conclusion of the conversation, went like this:

AddexperienceParty(800)
ApplySpellRES("OHMISC90",Myself)
TakePartyItem("MISC90")
EraseJournalEntry(27486)
EscapeArea()

"What is that spell "OHMISC90?" I wondered. I browsed to it in Near Infinity, and it was a nameless spell doing just one thing, setting Strength permanently to 19. I was puzzled for a moment, and then - it was there to make sure Tiber could walk away with the body! I couldn't help but laugh. It brought out the patch-and-glue nature of videogame design so, these spells for the occassion and tricks. I could just imagine Bioware people running the quest and watching Tiber walk helplessly in place. And they shook their heads and put this in.  

[subtledoctor]

These games in particular are incredibly full of patch and glue.

Or maybe it seems that way because we have unprecedented access to the game files and structure.  But it sure seems like there is a lot.

[Azazello]

1 hour ago, temnix said:

It brought out the patch-and-glue nature of videogame design so, these spells for the occassion and tricks. I could just imagine Bioware people running the quest and watching Tiber walk helplessly in place. And they shook their heads and put this in.  

I love these kinds of (re)discoveries and aspects of the classic BG games! Twenty-plus years onward, and there're still little treasures to be found. And more will be found!

[ABlake]

Assuming that WAS the reason for that little spell...

If they just spent a minute to test this, they'd find out that NPCs DON'T have encumbrance... He can have 3 STR and five bodies loaded on him and can still walk just fine.

NotLikeThis

[Isewein]

Seems like a case of coders on two different levels coming up with solutions to the same separately encountered issue then. Good find!

[ABlake]

If they were so worried about this, they could just use DestroyItem., instead of making a whole new spell just for this (seeing as the spell name contains MISC90 it's safe to assume that it was made solely for this purpose).

And you'd think that it's only natural to ask yourself, "would the NPC ACTUALLY be encumbered to begin with?", and verify that FIRST, before going about implementing a "fix" that is NOT even needed.

Must say I don't find this nearly as amusing as some may. smh

[Azazello]

It's easy to backseat-QA code and development decisions - especially after 20 years! We should be glad the game works at all.

[subtledoctor]

"OH" is an Overhaul file prefix, so this spell was added specifically for the EE game.  Presumably to fix what was presumed to be a bug in the original, or in the original after being ported to the BG2 engine.  (I wonder what this script looks like in Tutu/BGT.)  That bug report must have come from somewhere...

Might be just something like, "I gave Tiber his brother's body, then I killed him before he could walk away, but he wasn't carrying the body!"

Edited May 5, 2020 by subtledoctor

[Kilivitz]

16 hours ago, subtledoctor said:

"OH" is an Overhaul file prefix, so this spell was added specifically for the EE game.  Presumably to fix what was presumed to be a bug in the original, or in the original after being ported to the BG2 engine.  (I wonder what this script looks like in Tutu/BGT.)  That bug report must have come from somewhere...

Might be just something like, "I gave Tiber his brother's body, then I killed him before he could walk away, but he wasn't carrying the body!"

You know, solving issues that weren't issues to begin with sounds pretty spot on for Beamdog, IMHO.

[temnix]

22 hours ago, subtledoctor said:

These games in particular are incredibly full of patch and glue.

Or maybe it seems that way because we have unprecedented access to the game files and structure.  But it sure seems like there is a lot.

That's a good comment. We probably have too much access. Maybe all games are created this way, and it's just a normal part of the process. The lengths to which I go myself to get some of my features to work, it's bending space. But everything will look shiny with the hood closed. The problem is with being both a mechanic and a driver.

[Ardanis]

I think it's IE-specific. Other games I tinkered with were far more internally organized and structured.

[Jarno Mikkola]

Actually this is confusion about the making of the game projects. Or just coding. They can vary a lot between projects.

On 5/5/2020 at 2:53 AM, ABlake said:

And you'd think that it's only natural to ask yourself, "would the NPC ACTUALLY be encumbered to begin with?", and verify that FIRST, before going about implementing a "fix" that is NOT even needed.

You could ask that from a person yes... but if you just happen to be alone in your home, isolated and can't go out for a reason or another, and phoning a person that might know this is not a thing you know who to contact, why not just make sure the thing you do will end up in the final project, why not just make sure yourself that it works and add a few features you know how to do.

[ABlake]

31 minutes ago, Jarno Mikkola said:

You could ask that from a person yes... but if you just happen to be alone in your home, isolated and can't go out for a reason or another, and phoning a person that might know this is not a thing you know who to contact, why not just make sure the thing you do will end up in the final project, why not just make sure yourself that it works and add a few features you know how to do.

So we're assuming that the person happened to be alone in his home, isolated, couldn't go out for a reason or another, unable to contact someone for more information, and STILL worked on the code for the game when they didn't even have access to the game? They must have not had access to the game, because otherwise they would've been able to launch it and verify the thing, like I said. You're saying if it were you, you would still work (and agree to handle the task) when you're in that kind of situation? The guy must've been in the middle of a desert or some post-apocalyptic world in an alternate timeline or something, for months, or even years. You'd think his superior would've assigned the task to someone else who was in a more suitable situation to work...

That's a LOT to assume all at once.

Just how hard do you think it is to get access to the game, launch it, and verify that, "NPCs DON'T HAVE ENCUMBRANCE"? And how much time do you think that'd take?

Yeah, no, to me there's no excuse for the fact that no one bothered to verify this detail before deciding that a fix was needed. If you tell me, "but it's such a trivial detail, it's ok to not verify things and just go with the "safe" way", then, well, I guess we have quite different working standards. That's fine.

[Jarno Mikkola]

31 minutes ago, ABlake said:

That's a LOT to assume all at once.

Just how hard do you think it is to get access to the game, launch it, and verify that, "NPCs DON'T HAVE ENCUMBRANCE"? And how much time do you think that'd take?

Let's say, we turn time back say 20 years and assume the worker has a computer, and internet access at this point. That was a thing by then. But do they have a copy of the latest release candidate at hand. NO WAY IN HELL !!!

Assume as much as you like, but I would like to go with the least one of them, and point this out just so you know, the game was 2.5 GB's to install and the dualup would have taken a month to download the thing, hello the games install process fails to find enough install space if you have too much. Even if the engine was ready to run by then. As should you know, the old engines were build by the project, and not a large game corporation making it to millions of games all at one.

Stop living in today and try the past for one reason or another.

[Azazello]

13 hours ago, ABlake said:

Yeah, no, to me there's no excuse for the fact that no one bothered to verify this detail before deciding that a fix was needed. If you tell me, "but it's such a trivial detail, it's ok to not verify things and just go with the "safe" way", then, well, I guess we have quite different working standards. That's fine.

You're not a developer, that's obvious; (neither am I); otherwise, you would totally understand that these kinds of kludges, and similarly the oversight of minor issues [which could lead to major bug(s)], happens in software development all.the.time. In every type of application--games to major business packages to programming languages to dev platforms to desktop widgets.

These kludges pass through several levels of review- after several coders have worked on the same blocks, and after one or more rounds of testing, and a QA (quality assurance) process after all of that -- all of which, so many eyes have seen the 'fix', may know that it is yes a bandage - but if it works, and it works simply, and it doesn't break anything else... so be it.

These are not 'bad' coding or development cycle - they're simply tools used at the time to get the job done.

It could take years before someone goes back and data-mines the code to find such gems, or lumps of coal.

We can criticize all we want, from the comforts of our self-isolating chairs, years after the fact, that these bandaids aren't effective; but we can't reasonably label these as incompetent or a dysfunctional process.