Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 May 2005
Offline Last Active Aug 22 2016 12:02 PM

#5304540 Multithreaded Game Engine Architecture With Data Oriented Design

Posted by on 07 August 2016 - 04:32 PM

Since the topic is so complex, I'll just put some very high-level notes while not even trying to formulate a complete answer to the actual question.


1) For cache-friendliness, try to ensure each operation's required memory is in a continuous memory region, and preferably accessed linearly from start to end. For example updating a particle system or an animated skeleton. Avoid "jumping" from heap object to another through pointers. A well-structured entity-component system is possibly a good match here, at least if the systems don't need accessing each other's data a lot.


2) A typical approach nowadays is to structure the execution of a frame into a task graph, and the tasks are executed on any available cores by worker threads. Data from each task or operation flows to the next, for example physics simulation & animation together produce the final positions of game objects, which go to culling, from which a visible object list goes to render command generation, which is finally submitted to the graphics API. When the culling / render stage for the current frame is running, you can already be calculating the logic for the next frame.


For both points 1 & 2 it's probably best to keep scripting for low-volume, high-level operations (e.g. ask pathfinding to start moving this object toward position x) or configuration (stats of game objects, list of render passes and postprocess effects for the actual rendering code). For such infrequent use even a singlethreaded script VM could be fine.


Here's Naughty Dog talking about their engine's multithreading & memory allocation: http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine


Also old Bitsquid development blog entries may be interesting reading: http://bitsquid.blogspot.com/

#5303015 Cross Platform Library Question

Posted by on 28 July 2016 - 05:24 PM

To take the window creation and management as an example, SDL implements it separately (using the relevant OS-level API's) for each OS / platform it supports. Same for e.g. audio, joystick etc.

#5296989 Should video game mechanics be scripted?

Posted by on 17 June 2016 - 12:11 PM

Consider also debugger support. If you program game logic directly in native C / C++, you can debug using your compiler's tools. With a scripting system, you'll have to implement debugging yourself if you want the same level of access. The script VM may help in this by providing hooks for breakpoints, single-stepping etc.


Though, once you have script debugging in place, you can go above and beyond of what gdb or Visual Studio could provide by tying it into your game engine systems (e.g. editing the game object properties while the game is running, selectively suspending or restarting specific scripts..)

#5276120 Why are there no AAA games targeted towards the young adult audience?

Posted by on 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.


#5274669 Any alternatives to automatic class instantiation via macro?

Posted by on 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.

#5257971 Game Engine Creation: What are the biggest challenges faced?

Posted by on 19 October 2015 - 02:23 PM

Will echo what many have already said.


The engine runtime is the fun part, and also mostly easy, unless you go for challenging state-of-the-art tech, or try to maximize performance. Creating the scene management, rendering and lighting, physics integration, possible multithreading etc. This can still take a lot of time (easily a man-year) depending on your expertise and how much features you're going to add.


After you've got the runtime done, the rest is to make the system usable for actual game creation. Up to this point you probably haven't needed to make any concrete decisions on how the game projects made with the engine are structured, how assets are imported and cooked into a build, how the game logic or rules are inserted and how they interact with the runtime, how the world data is represented for processes like precalculated lighting or navigation data creation, and how to make all the workflows usable for the creators. Now you're going to have to make a lot of decisions which influence what kind of games you can make with the system, and how usable it turns out in the end.


It helps if you can handle 3D modelling yourself so you can continuously test from a content creator's point. In reality working on the runtime & tools / workflow will very likely intertwine, I just separated them to illustrate the difference.


You can also decide to limit yourself to just creating a coder-oriented runtime library (compare e.g. to Cocos2D or Ogre), rather than a full-blown game engine (like Unity). It will still be a worthwhile learning experience, but probably not something that's directly useful as a game creation tool. Getting to the full-blown stage will certainly take man-years.

#5256690 How to handle skipped animation frames (skeletal animation)

Posted by on 11 October 2015 - 10:33 AM

The typical approach is to just sample the animation at the time position to which it has advanced to, according to the time step between previous frame and current. If this leads to skipped keyframes, then so be it. Your idea to preserve the "dominant" movement of an animation even in low FPS conditions is noble, but I don't know any engines that actually go to such trouble. At low FPS the gameplay feel will be poor anyway, so usually the engineering effort goes to ensuring that the FPS preferably never goes unplayably low.


Of course, if you know that you will never render faster than e.g. 30 FPS, it will be a waste of memory to store animations with higher keyframe frequency than that, in which case you could just re-export the animations with a suitable frequency.

#5255959 What's the best system on which to learn ASM?

Posted by on 07 October 2015 - 01:40 AM

The 68k is a very clean instruction set; you have a number of data registers, which all work the same, and address registers. There are nice instructions for math, including integer division / multiplication.


If your eventual goal is Megadrive and as you have previous C/C++ experience it doesn't seem like a stretch to go directly for the 68k.


However, there may be some difficulty in setting up a development toolchain so you can compile and run Megadrive programs, and also you would be learning the hardware features at the same time (to e.g. learn what addresses you need to poke to get something to show up on the screen). There are reverse-engineered / leaked resources for this, but not as abundant as for retro computers. When an 8/16bit console boots up and starts executing your program, it typically starts from almost nothing, on the other hand a computer typically has the screen already displaying some sensible data (like text), and has ROM operating system routines to help you.


Therefore, for the quickest, hassle-free introduction into the retro/asm programming mindset with minimal setup and immediately visible effects I'd recommend the C64 as well. For example with the VICE emulator, you can break into the built-in debugger/monitor and write & run simple asm programs directly; no toolchain setup needed. The C64 CPU instruction set is extremely limited though, you have three primary registers (A,X,Y) which all are used differently and you can forget about more complex functions like multiplication - they don't exist and must be written manually using bit-shifting arithmetic.


If you don't feel overwhelmed by the prospect of learning the hardware and having to set its state up from scratch, you'll waste less time going directly for your target platform though.

#5250567 Extending Unity editor and new UI

Posted by on 04 September 2015 - 08:15 AM

If you want to use the GameObject / Component based new UI for tool functionality, then the tools need to be actually running inside your Unity application. In that case you could look into any Unity new UI tutorials, but you are limited by what the Unity runtime API allows you to do.


However if you want to extend the editor itself, and create new windows or inspectors for it, you still need to use the old-style UI functions, as per Unity's documentation: http://docs.unity3d.com/Manual/editor-EditorWindows.html

#5247988 Reducing CPU usage in Enet thread

Posted by on 21 August 2015 - 01:14 AM

When I used to use Enet, I did just as hplus0603 suggested, run & update Enet in the main thread as part of the rest of the frame loop.


If I was also rendering, the rendering would naturally limit the framerate & CPU usage, especially if vsync was used.


In case of a headless server, the main loop could sleep to avoid spinning at 100% rate, when it doesn't have simulation work to do. Getting the sleep accurate may be a problem depending on the OS.

#5240042 Unity or C++?

Posted by on 13 July 2015 - 04:06 AM

Note that C++ programming in terms of Unity is used for plugins to extend Unity's functionality, for example making a custom movie recording functionality. Using it for gameplay purposes will be cumbersome, as you'll have to write all data marshalling (for example the positions of scene objects) between C++ / Mono yourself; Unity doesn't come with built-in C++ scene access.

#5235453 Is OpenGL enough or should I also support DirectX?

Posted by on 18 June 2015 - 06:12 AM

If you're fine with fairly old rendering techniques (no constant buffers, just shader uniforms, no VAO's) I wouldn't call OpenGL 2.0 or 2.1 bad. It has a fairly straightforward mapping to OpenGL ES 2.0, meaning your rendering code won't differ that much between desktop & mobile, and because it's older, it's better guaranteed to work with older drivers. You'll just need to be strict with obeying even the "stupid" parts of the specs, like for example if you use multiple render targets with a FBO, make sure they are the same color format.

#5235439 Is OpenGL enough or should I also support DirectX?

Posted by on 18 June 2015 - 05:01 AM

On Windows, do you want to support machines that probably never had a GPU driver update installed, and whose users don't even know how to update drivers? If the answer is yes, you pretty much need to default to DirectX on Windows.

#5235262 rendering system design

Posted by on 17 June 2015 - 04:28 AM

Or if the materials need a different shader, build instance queues/buckets on the CPU before rendering so that the queue key is a combination of the mesh pointer and the material pointer.


e.g. queue 1 contains instances of mesh A with material A, these will be rendered with one instanced draw call

queue 2 contains mesh A with material B, another draw call for them



I'd only put a "default material" pointer to the actual mesh resource, and allow the mesh scene nodes (instances) to override that.

#5233191 glGenBuffers is null in GLEW?

Posted by on 06 June 2015 - 12:38 PM

On Windows, SDL doesn't fail even if doesn't get the requested OpenGL version, in this case 2.1, but instead initializes the highest version it can. The "GDI Generic" renderer name points to the computer not having an up-to-date Nvidia graphic driver installed, in which case it's using the Windows default OpenGL drivers which support only OpenGL 1.1.