The engine team has been hard at work for the last couple of weeks. As you might have concluded from last week's post about graphics, the engine is now up and running on both PC and PS4.

We had some bumps in the road due to teams being dependent on the systems from day one. To get this resolved as soon as possible initial versions of all supporting systems have been created including the entity component system. This gave us some much needed breathing room.

After this was in place we could start working on the core systems of the engine. Improving the initial version of the ECS (Entity Component System) which was quite barebones and start work on the job system.

A rushed start

Initially we planned to work on the foundation of the engine during the initial week. It did not go as planned when graphics was dependent on the ECS on day one. This was a minor issue and was fixed by quickly getting up the ECS so that the graphics was no longer blocked.

However, this meant that it would require some changes later on to fix up the rushed parts. It also meant that the logging and memory allocation would be delayed. For a next time it would be a good idea to have the dependencies cleared out before the start of the project so that things like this won’t happen.

Fixing up

Now that most high priority tasks are done it is time to fix up the rushed ECS. We’re currently in the progress of adding doxygen to the project so this is also a good opportunity to look at the classes and see what needs to be improved or refactored. For the ECS it mainly came down to:

• Implementing missing functionalities
• Refactoring duplicate code
• Moving the data to Structures of Arrays and Arrays of Structures

Job system

Work was also started on the job system. The goal here was to get the job system implemented to the point where the API is stable and it could be used by the systems in our engine.

The job system works by exposing a job graph during initialization. New jobs can be defined and added to the graph to schedule work to be done during the frame.

During the frame the job graph gets processed and turned into a set of tasks. These tasks are then scheduled for execution by our thread pool (which is single threaded for now).

Splitting the definition and execution like this gives us a couple of advantages. It adheres to single responsibility, making the code easier to read. And since we know the job graph will not change after initialization we only have to check for overlap between the data access by different jobs once.

That’s all we have been up to so far with the development of the engine. Check back after the holidays for our next status update. And on behalf of the team behind Project Sulphur we would like to wish you wonderful holiday and a happy new year!

Editor note: Since no pictures were provided by the team here is an image of a cute otter.

Image source: Snow Cap by Eric Kilby