| El Duderino said: ^^ Again I´m not a programmer... but if you make a 3D enviorment somthing like a Lever that triggers and action is ether there or it is not... what kind of situation could make it dissapear ??? There should be no variables there... right ??? |
While it is true that program outcomes are entirely logical (ignoring faulty hardware), the randomness is generated from the users actions. As an example (I'm not a games programmer, so this example might not actually ever be the case):
Lets say it is a sandbox game like GTA so there isn't any 'levels' persay but a world where objects are required to be loaded in and out of memory in realtime. So as the character moves around, if a new object appears within 300m of them, it will be loaded into memory, and if a 'unique' object (only one instant in 300m) goes out of range, it is unloaded.
Now the adventurous gamer comes along and explores every place in the game, and ends up in an uncommon situation. While every effort has been made to fit all objects in a 300m raidus of the gamer into memory, this one particular place ends up with too many objects. Now to stop the game from crashing, the programmers will have put a fail safe to not load the object into memory if there is no room left, even if it is entirely assumed this will *never* occur. The gamer now explores futher, and because the now 'missing' object is never reloaded, they comes across the place where the object should have been only to find the object not there.
Now this doesn't excuse poor programming as this can theoretically be avoided. Instead of just loading objects as they hit the 300m range then ignoring them, we can perform another check. For this example, let's say that if an object sits within 100m, we recheck that we actually loaded it. If not, we discard the futhest object from the player and load in the closer object. Sounds like it should solve this issue right? We unfortunately this causes us to use extra cpu time and this might be the difference between smooth gameplay, and the game slowing down 'randomly' when we need to perform a large number of checks at once, so because the issue is "never" likely to occur, this check is ignored as the side effect is much greater and more noticable.
Hopefully this gives you a bit of insight into why 'random' bugs can occur.
