Advertisement

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

Started by January 13, 2017 08:29 AM
6 comments, last by koSar. 7 years, 10 months ago

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

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".
Advertisement

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? :/

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

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

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:

Advertisement

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.

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:

This topic is closed to new replies.

Advertisement