VanceIX said:
Alright. Then tell me this, which is more taxing- a preloaded hallway in an enclosed area, or flying a helicopter through a city? Since the individual areas can be loaded all at once, due to the linearity of the game, rendering is made simpler. The developer knows that there is a set route that the player will follow. They can add scripted events that are not very taxing, as they know where the user is heading, and when they will reach a point. Then, you have a game where you have an entire city that needs to render bit by bit depending on where the user decides to go. The user may decide they want to fly a helicopter through the city streets, causing massive explosions in the game environment.
Enclosed areas allow better optimisation, period. When a developer knows exactly what the user is doing at any given time, they can script events instead of having them happen in real time, giving the illusion of graphical prowess. When an entire level is able to be loaded at once, it's much easier to deal with rendering other details, rather than having to render dynamically depending on what the user does.
|
It depends. If something is preloaded, its much less to render then something dynamically changing simply because everything has to be recomputed every pass and then rendered rather then rendering something statically. Just because a hallway is preloaded doesn't mean it has arbitrary limits on dynamism, nor does a helicopter flying through a city have to have dynamical elements. It can be completely static, and in that case it can either load the entire map at one time which is a matter of scale, or it can load portions of the precomputed map similar to the hall way.
In that scenario, where the only difference is that we are constantly rendering a hallway versus a helicopter flying through a static city, both loading the exact same area/draw distance with the only difference being that since the helicopter is moving and thus the objects rendered in the area are changing, then the technical demands are exactly the same.
Rendering is the most demanding part of running optimized games, this is why GPU is usually more important and alot more powerful then CPUs now a days.
Linearity/Openess means very little when it comes to Rendering, that entirely depends on how a game is designed.
In regards to Optimization, again that is a matter of scale not linearity, and of design as well.
And just so we're clear I'm going to give you a primer because you don't seem to understand what most of the words you are actually using mean aside from what the media tells you:
Essentially, what it means to render and object is to render its mesh(which is kind of like a skeleton, but a skeleton is an animated mesh using single meshes as frames), a mesh is made up of indicies, vertices, and normals(for lighting), the mesh makes the shape and the texture is applied to that shape to make an object. Lastly, in order to see this, it must be rendered or output on screen, the pixels that make up the image of the textured message is more or less the the rendered object. This alone isn't very taxing but its a lot more demanding then AI which just follows a set of specified instructions.
Now, take that rendered object and muliply that for every single object on screen. We haven't even covered lighting, shading(which are different), or even physics yet, these objects don't even move, the more complicated the textures the more information the computer needs to store and modify each mesh with. This is starting to get taxing. Now render it at 60 hz, the AI can work at a much slower speed maybe 5 hz. Now we start talking about optimization methods including, backface culling, view frustum culling, the works.
Point is, if a developers scripting is more technically demanding then Rendering, then they have shit programmers.
Enclosed areas allow better optimisation, period. When a developer knows exactly what the user is doing at any given time, they can script events instead of having them happen in real time, giving the illusion of graphical prowess. When an entire level is able to be loaded at once, it's much easier to deal with rendering other details, rather than having to render dynamically depending on what the user does.
Rendering happens everytime the screen updates, which is at least the display resolution of the game. The difference between dynamic and static objects is that dynamics objects have meshes that changes so it must be recomputed, while a static mesh can be loaded in and reused. Eventing is irrelevant. Furthermore, this is a design choice and has nothing to do with linearity of a game.
