• Advertisement
Sign in to follow this  

Terminology: "Runtime Component" (Game Engine Architecture, Jason Gregory)

This topic is 466 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everybody,

 

I'm currently reading a lot of stuff about game engines and game engine architecture. Jason Gregory's book "Game Engine Architecture" is one of my prefered sources and I guess a few of you might have peeked in it too. Gregory states that a game engine generally consists of two parts: a tool suite and a runtime component. The term "runtime component" leaves me puzzled. How would you define what the runtime component of a game engine is? My current understanding ist, that the runtime component makes a game executable (within development and by the enduser) independent from game-specific stuff (assets, rules). Is this completely wrong? I would appreciate if you would share your opinion... :)

 

Best regards

koS

Share this post


Link to post
Share on other sites
Advertisement
A runtime component is one that is active while the game is being played (when the game is running, AKA "at runtime").

He's basically saying that:

- There are tools you use to make the game, but those aren't part of the game when it's being played.
- There's the game itself (or the "runtime component"), which understands how to use the data that you made using those tools.

- The game itself consists of stuff that came with the engine (the "runtime component" of the engine) and everything else you might have added or customized it with. That's why there's a distinction between "runtime component" and "game". Edited by Nypyren

Share this post


Link to post
Share on other sites

First of all: Thank you very much for your answer! :)

 

- There's the game itself (or the "runtime component"), which understands how to use the data that you made using those tools.
 

 

Here you actually mean "game engine", don't you? He makes the destinction (even if he says it's often blurry) between "runtime component" and "game" where "game-specific subsystems" come into play. Latter are (for my understanding) what you mean with "data made using tools" (ie. models, textures, audio and scripts for player-mechanics, -health, AI, ...). So by "understanding how to use the data made with tools" the "runtime component" of the game engine makes a game executable may the game-specific stuff be whatever (that's what I meant with "independent from game-specifc stuff"). Better? :/

Share this post


Link to post
Share on other sites

Two creative attempts for you guys to judge... ;)

1. ) "The runtime component of a game engine consists of components / subsystems which are required while a game is executed but do not determine a game's specifics."

2. ) "The runtime component of a game engine assembles all non-gamespecific components / subsystems required while a game is executed."

Share this post


Link to post
Share on other sites
#1 is mostly correct; "required" is not necessary; A game *can* use everything the engine provides, but it might not need to use some systems.

Share this post


Link to post
Share on other sites

I actually borrowed "required" from some scientific paper I read but I'm with you!  :)

 

I now wrote "contains components / subsystems for realization of non-gamespecific tasks (abstraction of hardware and generic, gamerelated tasks) during game-runtime" as definition for "runtime-component of a game-engine" into my imaginary diary. It feels like a definition that's to broad and vague to be wrong... :rolleyes:

Share this post


Link to post
Share on other sites

Without addressing the specific thing that the author was saying, since I'm not familiar with the book, usually "runtime component" just means any code that runs when the game is running, or is compiled into the game.  "Runtime" is different from anything like asset baking "bake time" or code compilation "compile time", etc.

Share this post


Link to post
Share on other sites

Thanks, 0r0d. I think my confusion is pretty much gone because of you guys. I'm pretty new to the topic and more in to pragmatic than theoretic stuff. But when I recently sat there and started asking myself about the more runtime'ish and tool'ish parts of the Unity-editor I got pretty confused...  :wink:

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement