|
Komodo Engine
C PROJECT_LOGO=
|
Komodo was spawned out of a desire to learn popular game engine design, like composition over inheritance and ECS. Komodo is an attempt at making an engine that places the developer first, providing simple control over 2D and 3D game development.
The recommended way to start with Komodo is by using a project template found in the Komodo.Templates package.
The project layout generally consists of two or more projects.
<Platform> projects (such as DesktopGL) which consists of platform-specific and creation of starting entities.Common project where all major game logic should reside.A Komodo project also will need a Content directory in the top-level directory of the project for placing assets and the MonoGame mgcb file. Komodo users will need to use the MonoGame Content Pipeline for compiling assets. Releases can be found here and a tutorial can be found here. Ignore the sections detailing the code needed to load in the asset files, as Komodo will do this for you given a path to an applicable asset for SpriteComponent, TextComponent, Drawable3DComponent, and SoundComponent.
In each platform project, a Game instance needs to be created. Once Game.Run() is called, control will not come back to the Startup class, so make sure at least one Entity with a BehaviorComponent.
A suggested pattern involves creating a Game instance, setting up platform-specific default inputs, and creating a root Entity with a root BehaviorComponent that will generate all the starting entities and their components.
If a Common project is being used, the <Platform> project should rarely be more complicated than this. Consider including graphics configuration code to the <Platform> project, selecting a resolution, whether or not to display fullscreen, etc.
The Common project is where the majority of the game will be created through BehaviorComponents.
BehaviorComponents generally will initialize the content for an Entity, loading the content from disk or generating the assets programatically.
Once initialized, a BehaviorComponents will continue to receive Update(GameTime gametime) calls unless disabled, allowing the BehaviorComponent to continue interacting with other entities and components.
Here is an example BehaviorComponent which creates an FPS counter as a TextComponent. This example assumes a CameraComponent and a Render2DSystem are also a part of the parent Entity of the FPSCounterBehavior.
All Entity objects which have components which can be rendered must have either a Render2DSystem or Render3DSystem referenced by them.
If an Entity will have a TextComponent, it will also need a Render2DSystem.
If an Entity will have a Drawable3DComponent, it will also need a Render3DSystem.
If an Entity has both a TextComponent and a Drawable3DComponent, it would need both a Render2DSystem and a Render3DSystem.
Each Render2DSystem or Render3DSystem renders using a single CameraComponent. A CameraComponent is set as the active camera for it's parent Entity by calling CameraComponent.SetActive(). This member method will set the CameraComponent as the active camera for the Entity's Render2DSystem and Render3DSystem.
It is not necessary to create a CameraComponent for each Entity, as sharing the Render2DSystem and Render3DSystem between Entity objects will cause them to render with the same CameraComponent.
By having the flexibility to use a different CameraComponent per entity, UIs can be easily drawn without relation to the CameraComponent folowing a player.
This setup will render the FPS counter without regard for the position of the entities with the perspectiveCamera. Using multiple render systems allows for segmented management of how Entity objects should be individually rendered.