Jump to content

Photo

Gamebryo Engine - Debate

tes game engine debate

  • Please log in to reply
24 replies to this topic

#1
AdamRundolf001

AdamRundolf001

    Fan

  • Members
  • PipPipPip
  • 434 posts

Here are a few things that are commonly known about the gamebryo/creation engine:

 

- It doesn't support multi-threading

- It's more optimized for single core up to four core processors

- It crashes like there's no tomorrow

- The graphics are absolutely horrible

- Forcing multithreading causes crazy glitches and bugs

 

So bethesda's engine is basically a piece of "crap".

 

But the community cannot fix everything! Bethsoft you have to make the effort to fix this or make a new engine.

 

And they did:

 

The Creation Engine Plus

 

Thanks to bethesda's work we now have more modding capabilities. Just think of when we'll get the Skyrim Special Edition Script Extender!

But there's no rush on my part... take as long as you guys need!


Edited by AdamRundolf001, 07 December 2016 - 07:13 PM.


#2
Ethreon

Ethreon

    Hobo Feral

  • Supporter
  • PipPipPipPipPip
  • 13,941 posts

You realize Gamebryo+updates= CK right? The core is the same, just like any other engine..



#3
Vagrant0

Vagrant0

    relic of a by-gone age

  • Supporter
  • PipPipPipPipPip
  • 10,491 posts

To be as basic as I can about this old and exhausted topic:

 

All engines have bugs and limitations. Changing the engine doesn't mean that these will be solved, we will just have a different bunch. Take a look around at other 'openworld' games, most these games also have rather severe performance issues, collision bugs, pathing bugs, ai bugs. Even your beloved Witcher 3. The reality is that there really aren't any engines around which can handle the scale of a world that you have with Skyrim or similar games, meanwhile no matter what engine they do use, there will be problems simply because you're trying to do so much. Neither Unity or Unreal allow for background simulation without actively loading areas, which is why the NPC behavior in these games is usually VERY limited. It's not a problem for most games since they have a very static world or just respawn whatever is supposed to appear somewhere... Meanwhile in FO4 you have caravans and settlers who actually move through the map on their routes instead of just randomly blinking into existence.

 

Bethesda owns the engine. They are able to code and update the engine however they want. When Ron Howard talks about how "the technology just isn't there yet" in regards to a TES: VI, he's talking about the engine not being able to do what they want to do yet. Skyrim SE was a half-step towards getting there. It is creating a situation where they are able to bring an older game up to use a more recent version of the engine while getting feedback about how it performs in a wide variety of systems, while also funding the project through new sales. If we consider that the engine used in Oblivion was a step further than Morrowind, and the engine used in Skyrim is a step further than Oblivion, and the engine that was used in Fallout 4 a step further than Skyrim, it's very clear that they are developing and improving not only on its functionality in terms of game systems, but also bringing it in line with modern hardware and software requirements.

 

And remember, the internet is full of idiots that make clickbait "check out this glitch" videos who like to call attention to what are usually uncommon bugs as if it was a systemic problem.



#4
HeyYou

HeyYou

    Resident poster

  • Supporter
  • PipPipPipPipPip
  • 9,108 posts

I am not aware of ANY game engine that can actually efficiently use more than one or two cores, or even deal well with hyperthreading....... Computer hardware has WAY outpaced game engine development. For beth games, processor speed is more important than how many cores you have. I suspect that it would run better on a dual core @ 3.6ghz, than it would on an 8 core, @ 2.5.......



#5
Ethreon

Ethreon

    Hobo Feral

  • Supporter
  • PipPipPipPipPip
  • 13,941 posts

processsor AND ram.



#6
HeyYou

HeyYou

    Resident poster

  • Supporter
  • PipPipPipPipPip
  • 9,108 posts

processsor AND ram.

With the advent of the 64 bit engine, ram limitations are somewhat alleviated, now, beth just needs to teach the game engine how to PROPERLY handle memory...... :D



#7
JimboUK

JimboUK

    There's someone watching me, I can tell.

  • Premium Member
  • 44,919 posts

There are other games that use the engine without issue, the problem isn't Gamebryo, it's what Bethesda does with it.



#8
Vagrant0

Vagrant0

    relic of a by-gone age

  • Supporter
  • PipPipPipPipPip
  • 10,491 posts

There are other games that use the engine without issue, the problem isn't Gamebryo, it's what Bethesda does with it.

Quite a bit of this.

 

Their QA team either doesn't have the time/budget to fix issues or the QA team simply does not have the ability to notice what is actually happening within the game (having to run around in a corner of a room trying to move out of bounds instead of just being able to see the collision mesh to see where the gap is). It wouldn't be as large of a problem if most of the scripting and event work was designed better than "it just working (barely)".



#9
HeyYou

HeyYou

    Resident poster

  • Supporter
  • PipPipPipPipPip
  • 9,108 posts

Yeah, I was really annoyed when they went with papyrus, and an external script engine. Makes doing a scripts that are timing dependent rather hit or miss. That, and I didn't really wanna learn yet another scripting language..... I think OBSE was the pinnacle of scripting...... you could do a LOT of neat stuff. (and we did.....) Oh well. I don't ever see beth going back to that.



#10
PoorlyAged

PoorlyAged

    \

  • Account closed
  • PipPipPip
  • 645 posts

Warning, technical rant follows.

 

What Bethesda really needs it a good lint-picker.  The memory leaks and the ever growing hunger for more memory also have an impact on the games performance, impacts the frequency of crashes and freezes and other bugs caused by memory thrashing.    

 

What's a memory leak?  Simple explanation.  A program gets a bit of storage to store a list (let's say your inventory).  As you collect more trophies (or just stuff to sell) while wading through a dungeon, the list grows and the original storage  reserved for the list is exhausted.  More storage is obtained for the growing list.  At some point you wind up selling the detritus to a vendor.  The list shrinks back to your weapons and armor again.  But that second block of storage is not returned to the system and is still there, unused and taking up memory.  This is compounded when the game exhausts your original reserved storage a second time, because a new extension is obtained which leaves that first extension allocated and not used.  

 

As these unused blocks of memory accumulate, the system allows the game to use more virtual memory.  As the needed blocks eventually wind up in different storage sections, these sections must be swapped in and out to continue play, causing the memory manager to thrash.  Additionally, these orphaned storage blocks lead to fragmented memory and the game is unable to get a contiguous block of storage of sufficient size to meet the games need (like the game locks up when you open a door). 

 

This is why the game seems to bog down the longer a session of play extends and why a save and restart of  the game sometimes improves the games performance.

 

A lint-picker is a programs that scans programs and attempts to pair every GetStorage to a FreeStorage in an attempt to ensure that there is a FreeStorage associated with every GetStorage.  


Edited by PoorlyAged, 05 February 2017 - 05:31 AM.






Also tagged with one or more of these keywords: tes, game engine, debate

Page loaded in: 1.096 seconds