I am engaged on a C++ sport engine for my very own tasks. It is divided into two components: one which handles primary performance like logging, cross-platform abstractions, filesystem utilities, and so on., and one other which is used particularly as a sport growth library. The sport growth (“core”) library is designed for use like this:
- Create a category which extends
bwGame
- Create a
most important
operate that creates an occasion of this sport (which from this level on behaves like a singleton) after which namerun
on it - Override the
init
operate of the sport class- Create a
bwStage
or an occasion of a category which extendsbwStage
, then set it as the sport’s present stage utilizing theenterStage
technique - Create a
bwCamera
(a kind ofbwActor
), spawn it on the stage, then set it as the present digital camera by means of thebwRenderer
pointer saved within the sport singleton - Create all the wanted actors, set their properties, then spawn them on the
bwStage
(a few of these actors might come from stage knowledge and be mechanically spawned upon coming into the stage)
- Create a
- Set the sport state to a
bwGameState
-type object, which handles logic for various components of the sport
Numerous that is topic to vary, however that is the overall concept.
Internally, bwGame
-type objects are singletons, which keep tips that could the render supervisor (bwRenderer
), the present sport state (bwGameState
), and the present stage bwStage
. The bwRenderer
accommodates the foundation node of a bwSceneGraph
(which is itself inherits from bwGraphNode
), a easy graph-like construction that does not help reparenting logic, discovering particular kids/ancestors/descendants, or something like that, because the expectation is that the scene graph will probably be constructed as soon as and by no means modified till it’s deleted and a brand new one is constructed. On the sport logic facet, nevertheless, bwStage
s keep a listing of bwActor
s, which wouldn’t have dad and mom and youngsters as a result of that kind of construction is not needed for many sport logic.
The primary query right here, although, is whether or not or not I ought to keep a separate scene graph particularly for rendering, or I ought to simply combine graphics-related metadata and knowledge constructions into the bwStage
and bwActor
s, like having some actors lengthen a Drawable
class or interface and having them present their very own drawing data like meshes and supplies, possibly even having a Drawable
object separate from the actor however referenced by it, and having absolutely featured parenting and scene tree help in bwStage
. It is a very tough query for me to reply contemplating the design of my challenge, so I would like some assist figuring it out given my circumstances.