TES V: Skyrim

[Grall]

I believe pretty much all of these bugs could be fixed with some checks built into the questing system. Treating everything like a giant state machine and checking vast amounts of combinations for flaws seems like going overboard.

Like if the quest depends on an item, the game should check if the player is already carrying it. A particular quest wants the player to fetch a briar heart, but if you're an alchemist you may already have one (and this is an alchemy quest so you probably do), so the quest may bug on this step and won't let you advance. Worse, some reports say the quest bugs all subsequently obtained briar hearts and turn them into unusable, undroppable quest items... OMFG why is this happening???

...And if a player has just cleared a dungeon that a particular quest depends on, the game should just repopulate it when you get to that particular step of the quest you'll be able to proceed rather than having the game become comfuzzled forever or perhaps if you're lucky, until you've waited/played 30 days of in-game time and the dungeon respawns automatically.

Checking if a function call like malloc() for example succeeded was very important at least in the past, I dunno if modern programming languages handle that transparently now, but back in the bad old days on the Amiga for example, if you didn't check yourself that you actually got the memory you requested, a guru meditation was waiting to happen for you... Has today's programmers grown so complacent and reliant on OS resource management and garbage collection they've forgotten all of these basic practices, I wonder?

 

[pcchen]

I believe pretty much all of these bugs could be fixed with some checks built into the questing system. Treating everything like a giant state machine and checking vast amounts of combinations for flaws seems like going overboard.

In theory, yes. In real world, no, as one can see in the case of Skyrim.

Like if the quest depends on an item, the game should check if the player is already carrying it. A particular quest wants the player to fetch a briar heart, but if you're an alchemist you may already have one (and this is an alchemy quest so you probably do), so the quest may bug on this step and won't let you advance. Worse, some reports say the quest bugs all subsequently obtained briar hearts and turn them into unusable, undroppable quest items... OMFG why is this happening???

That's because the quest item is actually not the normal item. They have different item id internally. Some quests do use the same item id so you can use a "normal" item to finish the quest (e.g. the bear pelt quest), but many quests do use different items.

Part of the reason is probably to limit the quest to be done in a specific way (for example, if the quest is designed for you to get the briar hear from a specific NPC in a specific place, it's probably better to use a different item id so that the quest item has to be obtained that way).

Actually Skyrim is already doing a lot of these checks. For example, some quests may require you to steal from somebody (or some NPC may try to kill another NPC). If the said NPC is dead, the game automatically find another one as the target. However, these kind of automatic adaptation has its limit. MMO-RPG such as World of Warcraft avoids these problems by making everything more or less permanent (i.e. all dead NPC respawn after a set of time). In World of Warcraft for example, it's impossible to be stuck into some "unfinishable" quest because you can always drop the quest and delete all quest items, and the NPC giving the quest is always there (but mind you it's not always that way, especially in beta).

However, since there are so many quests (and worse, Radiant quests are generated automatically, so technically there are ~infinite number of quests), it's bound to have some checks missing. That's why I think it's probably better to make an automatic state checking. Even Radiant quests are generated in a fixed way so the number of states should be finite.

Checking if a function call like malloc() for example succeeded was very important at least in the past, I dunno if modern programming languages handle that transparently now, but back in the bad old days on the Amiga for example, if you didn't check yourself that you actually got the memory you requested, a guru meditation was waiting to happen for you... Has today's programmers grown so complacent and reliant on OS resource management and garbage collection they've forgotten all of these basic practices, I wonder?

Well, back then memory is very limited so a malloc call returning NULL is a possibility. However, nowadays many programmers just assume that malloc always returns a valid pointer. Even if they check for NULL they don't really know what to do next, and many just crash the application or raise a unrecoverable exception.

 

[pcchen]

1.4 Update is now live. Here's a list of all fixes:

http://www.bethblog.com/2012/02/01/1-4-update-now-on-steam/#more-17658

 

[xatnys]

I have a feeling this won't fix my game breaking issue of crashing between cells, but here goes nothing!

 

[Grall]

It says something about fixing a bug with hitching at cell boundaries, so they've done some work on those boundaries anyway. If the bug included crashing maybe you're all good now!

 

[Daozang]

There is a rumor going around that come Tuesday, with the release of the CK, they'll have an official high resolution texture pack along with it!

 

[Grall]

I don't mind the textures as they are now, I think the game looks fabulous. I would rather they worked on the LoD system as there's a lot of detail popping when moving around, and also offered a built-in way to increase the view distance of the highest LoD without having to bury oneself in the config files (which there are like 5 of them or something, spread out all over the place...)

 

[Daozang]

With ugridstoload, you can almost eliminate the pop up. But depending on your hardware, it can be the reason for many CTDs...

 

[KimB]

Why? People buy huge quantities of their games already so why waste resources fixing them? The gaming public is happy to be a free beta tester. To me it just highlights that stability and buginess really don't matter that much. They are generally just used to support an already held opinion about a title.

Bugs tend to slow down software development dramatically. It is usually far, far faster and easier to avoid the bugs in the first place than it is to just throw something together and fix the bugs later. And the larger the project is, the more important it is to catch bugs early.

The main obstacle to this is just that it takes a lot of discipline and a lot of careful thought and planning to produce and adhere to a software development strategy that avoids as many bugs as possible. Most programmers just like to get in there and get it done.

 

[Jedi2016]

There is a rumor going around that come Tuesday, with the release of the CK, they'll have an official high resolution texture pack along with it!

First I've heard of it, but it would be nice.

Tried out the new patch. Runs more or less like it did before, really. Good in some spots, bad in others. Haven't tried the real "fps killer" spots yet, like Markarth. I get around 50fps at the top of Whiterun, with SMAA and one of the Whiterun texture packs. A couple of texture glitches when I first booted it up, related to water.. might have been the water texture I'm using, it didn't happen everywhere, and I've seen it do weird stuff before.

Should be interesting to see what happens when the CK comes out.

 

[Sxotty]

Bugs tend to slow down software development dramatically. It is usually far, far faster and easier to avoid the bugs in the first place than it is to just throw something together and fix the bugs later. And the larger the project is, the more important it is to catch bugs early.

The main obstacle to this is just that it takes a lot of discipline and a lot of careful thought and planning to produce and adhere to a software development strategy that avoids as many bugs as possible. Most programmers just like to get in there and get it done.

A lot of the bugs here though would not make much difference. Making it so someone can't find a chest and complete some silly side quest doesn't slow development much IMO.

 

[kyleb]

Well it doesn't slow down development at all if you never go back to try to fix all that crap.

 

[KimB]

Well it doesn't slow down development at all if you never go back to try to fix all that crap.

The issue here is that there were far, far more bugs before the game was released. This is guaranteed. Any software development project, in fact, is going to have a lot of bugs. The main thing to do is to have a solid validation process for the individual pieces of the software, as well as even stronger validation for the parts that interconnect all of the disparate pieces.

The mundane, preventable nature of many of the bugs that made it through testing screams bad development process to me. I would be willing to bet that for each bug that still exists in the game, another 10+ had to be fixed after the central game was more-or-less in place. So yes, that's going to slow development down a lot.

With games as big and complex as the Elder Scrolls series, Bethesda really needs to step back and take a hard look at their software development process.

 

[ERP]

I was in 2 minds having purchasing Skyrim, as much as I want to reward a developer for building a stellar game, I don't want to reward releasing buggy poorly tested crap.

It's a great game despite the poor technical showing, unfortunately the success reinforces their development practices and TES 6 will likely be the same bug infested technical piece of shit. I'll still buy it and the cycle will continue.

I don't often criticize a developer at the technical level, but they clearly have no idea how to develop quality software, there process is clearly broken, and it probably does end up costing them money, but it's common developer fault to attribute success to what you are doing rather than realize that you are successful despite it.

Skyrim is still the best game I've played in years, imagine for a minute how good the game could have been...

 

[Jedi2016]

Don't forget that part of the problem was that they set a very specific release date far ahead of time, and come hell or high water, the game was going to release on 11/11/11 whether it was ready or not. In this case, it wasn't quite ready. I don't know if I would fault the development process so much as the idea of a fixed release date. I remember back in the day it was fairly common for some big titles to be delayed now and again, sometimes by several months, in order to make sure it was actually ready. These days, developers are scared as hell to do it, especially considering they can just release the game as-is and then patch it up after launch. Makes me feel sorry for the folks that don't have their consoles online and can't benefit from the post-release patches.

 

[Vadi]

Seems the game is a potential risk and they keep it barely good enough, and the visuals take away money from coding. Also you can speed up coding only so much. After all, is there any other comparable game? Surely you could develop a perfect game, just code it in Erlang.

PS
I love the cursor bug in text fields ...



Jedi, I got a water bug too, without any mods apart from ugrids=7, it was completely transparent after a fast travel.



edit:
Ah yes, I forgot it was caused by alt+tab.

 

[kyleb]

Jedi, I got a water bug too, without any mods apart from ugrids=7, it was completely transparent after a fast travel.

I get transparent water that from alt-tabing on occasion, no tweaks at all.

 

[Jedi2016]

This was one area just outside of Windhelm, I think it was. Whenever I moved the screen in any way, whether I moved my character or just panned around with the mouse, the water would flicker horribly until I came to a stop, at which point it displayed normally. Not a LOD issue, since I could walk right up to the water and it would do the same thing. But the next time I saw water, further south, it was fine, and I didn't see the problem again.

 

[Dresden]

High rez texture pack tomorrow?

http://www.bluesnews.com/s/129719/skyrim-hi-rez-pack-tuesday

 

[KimB]

I was in 2 minds having purchasing Skyrim, as much as I want to reward a developer for building a stellar game, I don't want to reward releasing buggy poorly tested crap.

Honestly, it's not that bad for the vast majority of players. I have logged in over 300 hours now, and I really haven't seen that many bugs. I think I maybe saw one showstopping bug in all of my playthroughs, though, after playing through the main quest, every guild quest, and quite a few side quests. A few others were visual glitches that were annoying but not completely out of bounds.

To me, the bugs in Skyrim are minor annoyances. My complaint that they really need a better developer process is more focused towards the software development side: the existence of so many bugs in the final product is indicative of an inefficient process. They could get far, far more done with a more solid process that caught more bugs early in development. That is to say, we could get a far more intricate, involved game if Bethesda hardened up their process to catch bugs earlier.

To name an example of how this might be done, quests in RPG's are very similar, in many ways, to multithreading. One of the main problems with multithreading is what to do when two different threads want to make use of the same resource when no single thread necessarily has any idea what the other threads are doing. In a quest, this issue arises whenever one aspect of one quest impacts another. In principle, many of the quests in a game like Skyrim can be completed in any order. So it is certainly not possible to know beforehand what the player is going to do, and in practice it is even going to be impossible to test every conceivable ordering of the quests, or which quests will be active concurrently. If the different quests made use of the same areas or resources, and doing one quest blocked other quests, this could cause a massive testing nightmare.

Except it doesn't have to: a lot of computer science research has gone into the problem of concurrency with mulithreading, and this research could be applied in a straightforward manner to quests in an RPG like Skyrim. By doing this, developers of a game like Skyrim could free themselves of the restriction of avoiding interactions between quests at all costs, freeing them up to produce much more non-linear quest lines and having quests that actually impact the game world in a tangible manner.

This, to me, would be the real benefit that gamers could expect from developers sticking to more a rigorous development process: the more rigorous development process allows for a more complicated, and ultimately more interesting, game.