This engine is made as part of the Kohi Game Engine series on YouTube (now live-streamed on Twitch), where we make a game engine from the ground up using C and Vulkan.
The name Kohi (コーヒー, pronounced "koh-hee") is a simplification of the Japanese word for "coffee", which makes sense given how much I love the stuff.
The original YouTube series is located here: https://www.youtube.com/watch?v=dHPuU-DJoBM&list=PLv8Ddw9K0JPg1BEO-RS-0MYs423cvLVtj.
The Twitch stream happens here: https://twitch.tv/travisvroman.
Kohi has been a 3D engine from the start, with most of it built from scratch. There will be many explanations and explorations along the way. The series starts off as more of a tutorial to get up and running, with explanations becoming higher level as things progress to keep the pacing up. We eventually transition to live-streaming on Twitch, with most coding being done on stream with some offline work that is less interesting being done offline.
Windows, Linux and macOS are all officially supported. Android and iOS runtime support may also be added down the road.
While the highest effort is made to reduce dependencies, each platform has things that must be installed for this to work.
Install these via package manager:
git
make
libx11-dev
libxkbcommon-x11-dev
libx11-xcb-dev
Install these via homebrew or other package manager:
git
make
You will need to have Clang 13+ and the Vulkan SDK installed:
The audio plugin requires an installatiion of OpenAL.
sudo apt install openal
for Ubuntu or sudo pacman -S openal
on Arch)brew install openal-soft
. Note on M1 macs this installs to /opt/homebrew/opt/openal-soft/
, where the include
, lib
, and 'bin
directories can be found. The build-all.sh
script accounts for this version of the install.To get started, get all of the prerequisites for your current platform (see above). After this, clone the repository: git clone https://github.com/travisvroman/kohi
.
Note that you are free to use other compilers (such as gcc), but they are not officially supported at this time (although it shouldn't be much work to get them setup).
See the setup videos in the series for Windows or Linux for details. macOS setup happens significantly later in the series at video 76, when support is officially added for that platform.
There are 2 build types available, Debug and Release. Debug includes debug symbols and is optimal for development and exploration, while Release is ideal for performance. There is also a "clean" available to clean out the built files, which is useful when switching between Debug/Release, or when strange linking errors occur because of missing files (i.e. switching branches).
Open up a command prompt or Powershell instance and run the build-debug.bat
file for a debug build, or build-release.bat
for a release build. There is also a clean.bat
available.
Open up a terminal and run the build-debug.sh
file for a debug build, or build-release.sh
for a release build. There is also a clean.sh
available.
At the moment, "Testbed" is the executable that uses Kohi. It should be run with the working directory of /bin
. In command prompt/Powershell in Windows, or a terminal in Linux/macOS, cd bin
to get into the bin folder, then run testbed.exe
on Windows or just testbed
for Linux/macOS.
This structure breakdown is based on the root folder of the repository. Some files/folders are omitted from this description as they aren't important to the overall picture.
kohi.core
- Shared library/.dll. Contains types, containers, string lib, math lib, utils, etc. as well as the platform layer (Win32, Linux, macOS).kohi.core.tests
- A small collection of unit tests for the core library. Needs to be expanded.kohi.runtime
- Shared library/.dll. Contains the core engine logic as well as many of the core engine systems.kohi.plugin.audio.openal
- Shared library/.dll. Contains the audio plugin which uses OpenAL as the audio backend.kohi.plugin.renderer.vulkan
- Shared library/.dll. Contains the Vulkan renderer plugin, which serves as the renderer backend to the engine for Vulkan.kohi.plugin.ui.standard
- Shared library/.dll. Contains the Kohi Standard UI, which contains a general-use collection of controls such as buttons, labels, textboxes, etc. This is a retained-mode UI.testbed.assets
- Contains all assets to be loaded by the testbed application.testbed.kapp
- Application/.exe. The consuming application executable, loads up testbed.klib, configures/uses plugins and other Kohi libraries.testbed.klib
= Shared library/.dll. Contains the application code (or "game code") specific to the application. Hot-reloadable.kohi.tools.versiongen
- Application/.exe. A small utility which generates a version using passed-in major and minor version numbers, and auto-generated build and revision numbers based on date and time. Used to version builds of Kohi and plugins.kohi.tools
- A collection of command-line tools. Mostly empty at the moment, but will be expended when editor development begins..vscode
A folder containing VS Code-specific project setup.See here.
The goal here is simple, to provide a resource that I wish I had when learning game development; a complete guide on building a game engine from scratch, including not only design decisions, but why those decisions were made. It should also be noted that, while this is a way of building a game engine, it is not the only way to build one.
Of course, there is also the goal of having a game engine capable of making games. Once the project is far enough along, making a game will be done as a series on my YouTube channel as well.
It is important to note that this engine is not, and will not be for quite a while, production-ready. It is a learning tool and as such is not yet optimized for use in production-quality products. This will eventually change, but for now it is not production-ready.
As the project progresses, community contributions are welcome via Pull Requests on GitHub.
Features should be contributed via a branch name in the format of feature/<feature name>
where <feature name>
is replaced with either the name of a feature or, ideally, the number of a reported feature issue (ex: feature/80
or feature/terrain
).
Bug fixes must be contributed via a branch name in the format of bugfix/<issue#>
where <issue#>
is replaced with the number of a reported feature issue (ex: bugfix/80
). Bug fixes therefore must have an associated issue created on GitHub.
Code should match the general style of the code in the repo. A code style guide will be published here at some point in the near future.
All contributions are subject to review and may or may not be accepted, or have change requests made before being accepted.
I am developing Kohi in my spare time. I don't have any sponsors at the moment. If you like my work, please feel free to support me in these places:
I would also greatly appreciate follows/subscriptions on YouTube and Twitch. Please spread the word!
Your support is greatly appreciated and will be re-invested back into the project.