Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 May 2005
Offline Last Active Yesterday, 02:24 PM

Posts I've Made

In Topic: Why are there no AAA games targeted towards the young adult audience?

17 February 2016 - 07:19 AM

hypester nails a lot of points I was thinking of as well. Though the popular YA series still do include physical combat, so I wouldn't see a reason to exclude it entirely. The production cost of choices and branching storylines vs. the expected sales could be a big hurdle, until there's some major evolutionary step in storytelling technology smile.png


If a game is heavily focused on interpersonal relationships, and these tie into the game mechanics, they could become somewhat cheapened once players manage to dig up the formulas used to guide the story / relationships (compare to the Mass Effect 2 Suicide Mission flowchart). Though that's just my gut feeling.


In Topic: Any alternatives to automatic class instantiation via macro?

06 February 2016 - 01:13 PM

It's possible it's not documented strongly enough that it's a helper only. And it's also extensively used by all the included samples :)


But anyway, there's the Engine class that does that actual work (and which is simply instantiated by Application, which you could also do yourself.) Even that isn't strictly mandatory, if you know what you're doing you can instantiate only the subsystems you need, but then we're deep in "advanced use" territory.

In Topic: Any alternatives to automatic class instantiation via macro?

06 February 2016 - 11:13 AM

Just a minor Urho-related correction: the Application class is an optional helper, not the "core of the engine". The most useful thing it does, for simple applications which don't need more sophisticated control, is to abstract away how the platform wants the main loop to be run, which differs on iOS and Emscripten ("run one frame when requested" instead of "run in a loop forever until exited"), but you're not forced to use it.

In Topic: Game Engine Modules/Projects

12 January 2016 - 10:45 AM

Strictly speaking you can also live dangerously and take the approach that the engine DLL and the game simply need to be compiled with the same C++ compiler, and therefore allow working through C++ ABI directly instead of making a proper C API (C4 engine, and some graphics libraries like Ogre work this way.)


But I agree that dynamic libraries are a complication and the OP likely doesn't need them right now.

In Topic: Modern OpenGL Transforms, HOW?

12 January 2016 - 07:42 AM

AAA engines don't necessarily use the most modern strategies out there, but just something that works well enough for the target platform(s) + the game they're running.


Typically the most amount of geometry comes from static world geometry, which can be batched together (offline, not runtime) into bigger chunks to reduce draw calls.


Something like trees and foliage would just be rendered instanced. When far away, sprite impostors can be used for even lower performance impact.


One particle effect with all its particles is usually one draw call, and its vertex buffer is typically completely rewritten each frame when it's visible and updating. Most of the math can be done in vertex shader so that the CPU-side calculations for the update stay light.


On modern desktops you can get quite high with the draw call count (a few thousand should be no problem) but on high resolutions and less beefy GPU's the shading would easily become the bottleneck instead.


One thing to consider is that AAA games on Windows usually use D3D, which can have better optimized drivers. If you have bad luck with OpenGL drivers (Intel?) and an older card the driver may be doing work on CPU which should really be done on GPU. Using VBO's and a good driver, over a thousand draw calls should not be a problem on either D3D or OpenGL.