top of page

Custom Level  Editor

Introduction

As a tools programmer its my job to improve the workflow of others. One of my most used tools is the Level Editor. It was created by working through multiple iterations and close communication with the users. It is essentially a collection of tools working together to create levels that my team and I ended up using in our games.

My Experience

My work with the level editor as a concept has been very iterative. What started out as a simple way of altering shapes during a Linear Algebra assignment turned into the solid system that was used in the Arinn Editor.

Lin Alg - The Test Phase

In the earliest stages of the editor, it was only for my usage. I wanted to learn the "Dear ImGui" API and to get a feeling for tools development by placing and editing components in real-time without the need to recompile all of my code. Looking back this version was very barebone and I still see similarities in my now.

Arinn 1.0 - Initial Version of Arinn

When the group projects started during my second year at TGA, we as a group decided on building an inhouse editor for our custom Arinn Engine. This iterationI implemented the Widget System with the intention of making the editor very dynamic, modular and at the same time easy to maintain.​

​​

​Since all of our designers were already familiar with the engine Unity and their editor, it made sense to use Unity as a reference for layout and workflow. This initial version of the editor provided essential functionality, allowing designers to manipulate objects within the scene and modify their component properties.

​​

This version editor was used for the entirety of one projekt before upgraded to Arinn 2.0.

​​

Arinn 2.0 - Currently Version of Arinn

When our second project as a group started during year two of TGA, we decided to clean up the code in the engine a bit.​  The cleanuped version engine had a much bigger focus on our components and so did our editor. 

​

​A bunch of new features were added with the intent of making the components as intuative as possible for our level designers. The new version of the editor was way more optimized and much nicer to work with.

 

LinAlg Verision
1QJpVj-MOv_uNSknNmdc0KyabZxc8YXOZxwTzq5wJYE0.gif
1DFUnZ8qM0K_0rDQzdAYxI6KnfbIv3g6m7mFh_z4OC84.gif
Arinn 1.0
16pbC5JrhJQdG7yHJAqcfihzO3zeVKcc5ZQQAunUhgO4.png
Arinn 2.0
Editor_Debug_EKxWhMliuY.png

Summary of My Experiance

​Looking back at where I started with the LinAlg editor I can see a clear improvement in my work. My strive to help my colleagues has pushed me to improve my skills and by extension the editor. It is doing things like this that makes me want to work with tools and engine development.

 

Editor Highlights

There are some aspects of the editor that I think deserve to be highlighted, specific pieces of code that defines the workflow and how the editor is used. These implementations are all modular and intuative to work with. Below I'll showcase and display these features.

​

widget.png
editor_widget_usage.png

Widget

​The Widget System is a modular ImGui based window system that can serilize information to suit diffrent needs. I developed the early version of this system in the early stages of Arinn 1.0. The idea was to make a system that was extremely modular since at the time I didn't know how the engine would end up working with the editor.

 

The widget itself was a base class that held a virtual function for rendering the window. This function was then called
while iterating through a list of all the widgets to create all our custom layouts that fit our needs. This made the Widgets very easy to build on and very intuative to work with.

​

It ended up being a solid system that became the core of our editor.

Asset Browser

The asset browser is a widget that displays files from the computer using std::filesystem. It scans through the current directory to register and display asset packages containing metadata such as file type, relative path, absolute path and an assigned texture for visualization.

​

The assigned texture depends on the file type of the asset:

  • Images are displayed using their own texture.

  • FBX files are rendered using a mini scene to snapshot a preview of the model.

  • Other file types (folders, documents, .etc) are set using a predefined texture.​

​​

As an added utility, assets can be dragged and dropped into various widgets to trigger events such as placing a model in the viewport, changing it's texture and so much more. ​This improved the workflow and made the editor feel like the real deal.

bottom of page