To allow easy debugging of Open Sea at runtime, you need a good debug GUI. One of the most important requirements is for it to be easy to expand. You don’t want the debug GUI to be a substantial part of development of a new module. To that end I have decided to use Dear ImGui. It is an immediate mode GUI that I first saw in a GDC talk. Module integrating this library with Open Sea is contained in open_sea::imgui (omitted from identifiers below). The relevant pull request can be found here.

Another new module for Open Sea is the Input module. It builds on top of GLFW’s input using the Boost.Signals2 library. It allows easy access to signals for input of the global window defined in the Window module. This module is contained in the open_sea::inut namespace (omitted from identifiers below). The relevant pull request can be found here.

Recently I finished a new module for Open Sea, the Window module. This module is an abstraction over the GLFW library and is contained in the open_sea::window namespace (omitted from identifiers below). The relevant pull request is available here.

First part of Open Sea is the logging module, which is a layer of abstraction over the Boost.Log library. It sets up easy logging into a file with a fallback being the console. The whole module is contained in the open_sea::log namespace.

Over the past few months, I have been seeing my lack of experience with C++ as more and more of a problem. I realised that in order to do what interests me properly, I need to learn that language and get as good as possible with it. I like Java but it has some big disadvantages. Mainly less possible optimisation which results in worse performance, and the requirement for everything to be object oriented, which causes some overhead when implementing concepts that don’t necessarily need to be objects.

During the implementation of the Entity Component System, some things had to be changed from the design described in the previous post. In this post I will summarise these changes and the reasons for them. A lot of the reasons stem from my desire to keep the code simple and modular. As this article goes out, the changes will be merged from their feature branch into the master branch of that project repository.

As I have described in the Components post, I have decided to completly redesign the current entity system. The new solution will follow the Entity Component System pattern. As this is an extensive change to the code which will also be the base for a lot of future code, it needs to be planned out first. In planning this, I will use various articles, books, and talks available online. Any significant sources are linked at the end of the post.

I am already using a simple entity system in the project. Currently this is done by inheritance. As I am working on adding animation to the current implementation of sprites, I am starting to see that I need more flexibility. From what I’ve seen in other engines, this kind of flexibility could be provided by using a component system instead of inheritance. As this would be a big and involved change, I want to first explore how I can best implement it.

Open Desert is my OpenGL sandbox. It is written in Java and uses the LWJGL 3 for bingings to the native libraries. The aim of the project is to create a functioning game engine. Currently it is strictly 2D, with the plan to add 3D capabilities at some point in the future.