Kigs framework a lightweight, fast, scalable framework that was ported to different platforms. Kigs is a basement framework for rapid application development and for educational / experimental development. We used it as a base to build professional projects from Nintendo DSi games to industrial robots simulator. This entry is a basic introduction of the series which will go over: Core Features, Prerequisites, Creating a new project, and how to build and run the new project.

Table of Contents
Kigs is a basement framework for rapid application development. It gives access to high-level architecture and functionalities ( modules, serialization, reflection, instances factory, upgradors, aggregates... ) while maintaining low-level control (optimizations, platform-specific customization, easy C/C++ extern libraries usage ...).
Today, it is possible to develop 2D or 3D mobile applications, multi-platform games ... quite simply thanks to commercial (Unreal, Unity ...) or open source (OpenSceneGraph, Ogre3D ...) 3D engines.
These engines obviously have all their advantages, but also their disadvantages:
- Some are not free.
- Some are black boxes and you only have access to exposed functionality.
- Some are very scene graph/rendering oriented and not really multi-purpose.
We developed the Kigs framework because we wanted a lightweight, fast, scalable framework that we could port to different platforms (that's why we used C++, available on almost all platforms), and we could use as a basement to build all our projects from Nintendo DSi games:

to industrial robots simulator (have a look here: https://kigs-framework.org/Projects). We also wanted to remain totally independent, and keep full control over all our projects code.
We decided some weeks ago to open source (MIT license) the main modules of our framework for Windows (x86, x64, for OpenGL and D3D, WUP D3D), and HTML5/Web Assembly (Emscripten) platforms. A functional (not anymore, we did not had the time to maintain it, and would be happy to get some help for this) Android version and an unmaintained iOS version are now also available. Here is the GitHub repository:
We spent some times during the last few months to refactor the framework:
- Removed some useless/buggy/deprecated code (There are probably some left !).
- Added some namespaces: Kigs as a general one, then one for each module.
- Added a new way to manage CoreModifiable attributes (mapping existing member variables).
- Used more modern C++ to manage attributes (less copy/paste code).
- ...
- You are a C++ developer and want to have access to high-level functionality such as serialization, instance factory, signals/slots management, scenegraph/rendering, Lua scripting ...
- You want to learn game development using C++ and Lua scripting.
- You want to experiment with new ideas without starting from scratch.
- You are curious to see how we implemented this or that feature and perhaps want to help improve the framework.
We would be happy if others take over our framework, improve it and adapt it to their desires and their needs.
The Kigs framework is divided into different modules, each grouping functionalities in a particular domain (Input, Rendering, GUI...). There are two main module types: Generic and Specific.
A generic module defines API/SDK/System independent classes, and/or base classes (interface) for API/SDK/System dependent classes.
Of course, specific modules do the exact opposite: they define API/SDK/System dependent classes, often inheriting from generic classes.
The main modules are Core
, FileManager
, Timer
, XML
. Then Input
(with specific InputWindows
, InputWUP
...), GUI
(GuiWindows
, GUIWUP
...), SceneGraph
, Renderer
(RendererOpenGL3
, RendererDirectX11
)...
Core features are mainly supported by KigsCore
and CoreModifiable
classes.
Classes with CoreModifiable
inheritance can be registered to instance factory. Ask KigsCore
to create a new instance of the wanted class is then easy:
CMSP localtimer = KigsCore::GetInstanceOf("localtimer", "Timer");
Here localtimer is returned as a CMSP (CoreModifiable SmartPointer). If no more reference are retained, the localtimer instance will be deleted when code exits localtimer scope.
CoreModifiable
instances can be organized in parent/sons trees like this:
addItem(localtimer);
addItem
adds a reference to the reference count of the instance. localtimer
instance will be destroyed when its references count reach 0
, so in our case when parent class is destroyed.
CoreModifiable
should be initialized before use:
localtimer->Init();
Then localtimer
can then be retrieved in another part of the code with different kind of research functions:
Timer* localtimer=GetFirstSonByName("Timer", "localtimer")->as<Timer>();
or:
CMSP localtimer = GetFirstInstanceByName("Timer", "localtimer");
All instances of a given type can also be retrieved in one call:
std::vector<CMSP> alltimers = GetInstances("Timer");
CoreModifiable
can have "compile-time" attributes that can be get or set by their names:
int _value;
testInstance->getValue("Sample1Value", _value);
_value = 4 * _value - 12;
testInstance->setValue("Sample1Value", _value);
Attributes can also be added or removed at runtime:
localtimer->AddDynamicAttribute(ATTRIBUTE_TYPE::FLOAT, "floatValue", 12.0f);
float timervalue=localtimer->getValue<float>("floatValue");
localtimer->setValue("floatValue","24");
CoreModifiable
trees with all their attributes can be exported in XML files:
CoreModifiable::Export("Sample1.xml", this, true);
And of course, import CoreModifiable
trees from an XML file is also possible:
CMSP imported=CoreModifiable::Import("Sample1.xml");
Methods can be added to CoreModifiable
and then accessed at runtime only by their names (without knowing the exact type of the instance the method is called on).
The easy way to call such a method is:
float result = simpleclass->SimpleCall<float>("AddValue", 10, 12.0f);
printf("result of calling AddValue = %f\n", result);
Find all the sample code from this introduction in the "Sample1" project on GitHub (browse the code).
We will focus on the main development platform we have used: Windows.
Our scripts need Visual Studio C++ 2022 (Community edition is OK).
A recent version of CMake (3.15.5 is set up in our case).
After cloning the repository, go to the kigs\projects folder.
Launch one of the two present scripts: CreateNewConsoleProject.vbs (for a command-line type project) or CreateNewDDProject.vbs (for a graphical data-driven project).
Enter a name for the project: a new folder with this name will be created. For example "SimpleTest
" and press OK.
Now open "kigs\projects\CMakeLists.txt" file in a text editor and add the line:
add_subdirectory(MyProjectName)
replacing "MyProjectName
" by the name of the project (SimpleTest
in our example).
Save and close "CMakeLists.txt" file.
Then go to kigs\scripts folder and launch one of the following scripts:
- generateWinCMake.bat for a win32 (opengl) application
- generateWinCMake64.bat for a win64 (opengl) application
- generateWinD3DCMake.bat for a win32 (D3D) application
- generateWinD3DCMake64.bat for a win64 (D3D) application
- generateWUPD3DCMake.bat for a Universal Windows Platform D3D application (only for graphical data driven project)
A new Build\[solutionType] folder is created at the same level as kigs folder.
Browse in this folder to reach Build\[solutionType]\kigs\projects\"MyProjectName" and choose "MyProjectName
".sln to open it in Visual Studio.
Once the solution is loaded in Visual Studio, set "MyProjectName
" as your startup project, choose the build configuration you want: StaticDebug
(for a compilation with full debug info), StaticReleaseTools
(for a compilation with optimization, but keeping all the export functionalities), StaticRelease
(for full optimization but no export functionality).
Build, launch. That's it!
In the next articles of this series, we will explore the advanced features of the framework:
- CoreModifiable class details
CoreModifiable
attributes CoreModifiable
methods CoreItem
- Signal / slot / notification
- Lua binding
- Data-driven application
- ...
Already Published in this Series
- Kigs Framework Introduction (1/8) - Overview
- Kigs Framework Introduction (2/8) - CoreModifiable
- Kigs Framework Introduction (3/8) - Attributes
- Kigs Framework Introduction (4/8) - Methods
- Kigs Framework Introduction (5/8) - CoreItem
- Kigs Framework Introduction (6/8) - Signal, Slot, Notification
- Kigs Framework Introduction (7/8) - Lua Binding
- Kigs Framework Introduction (8/8) - Data Driven Application
- 24th January, 2020: Initial version
- 29th January, 2020: Added Table of Contents
- 1st February, 2020: Added Already Published in this Series
- 7th February, 2020: Article (3/8) added to the series
- 8th February, 2020: Added screenshot from Rollway Puzzle and fixed link to Projects page
- 14th February, 2020: Article (4/8) added to the series
- 21st February, 2020: Article (5/8) added to the series and small bug fix in code
- 2nd March, 2020: Article (6/8) added to the series
- 6th March, 2020: New Android/iOS platforms released and article (7/8) added to the series
- 19th March, 2020: all GetInstances methods now returns CMSP or std::vector<CMSP>
- 1st May, 2020 : GitHub repository moved.
- 17th June, 2020 : Added final article of the series
- 19th June, 2020 : Changed introduction to make it clearer
- 1st March, 2023 : Update articles after framework refactory.