Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 May 2005
Offline Last Active Yesterday, 01:23 PM

Posts I've Made

In Topic: Multithreaded Game Engine Architecture With Data Oriented Design

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/

In Topic: Cross Platform Library Question

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.

In Topic: Should video game mechanics be scripted?

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..)

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.