Level Editor Design

If you're reading this, it means I was able to transcribe the design in my head into a human readable form. I'da probably scrapped this entry if I found it not coming together very well. With the level editor, I started out at first not thinking too much about design and just cowboy coding it up, shooting from the hip as I went, but soon my MainForm.cs collapsed under its own massive bodice. So on to refactoring, that's a healthy activity right? I'll check that out. I discovered C# has the idea of partial classes, you can split the implementation of classes over multiple files. I'm not sure what the proper use case for that is, but I'm guessing it was not so you can still cram all your logic into one massive class yet still not lose yourself inside a single file. I finally broke down and realized even though I was using a language that yielded fairly quick results, quick results are very different from genuine progress, and some design thinking would be required up front.

What exactly is a level editor? At a pretty high level of abstraction, it is a tool that creates and maintains a file with certain data, written out in such a format that it can be read in by another application. In short, data manipulation. Thinking about data being at the core of the application, one component of the application emerges, a data store. The data store is the program's internal representation of what data is needed to render a 3d scene. This data can be in the form of an array of height data to create a terrain, a map of bits to use for an image to texture a tree, all of the plain old raw data that makes up objects in a 3d world. Data from the store is also all we want to persist to disk since it is so non-specific and therefore most flexible. Using data from the store, a render system should be able to build and render these 3d objects. So there is another component, the render system. The renderer will need to convert the data from its store format into a format that can be easily passed off to the graphics API for rendering.

Something's missing however. With just these two components there's kind of a chicken-or-the-egg thing going on here. There needs to be a component to manage and control actions on the data in the data store. At a high level it has to support the basic add, remove, and edit functions to be carried out on pieces of data in the store.

We still need a place for the user to interact with the application. So a final component which is related to the renderer in that it presents state to the user would be the GUI. The GUI's main function is to translate user input into actions the action component can understand and carry out on the store. The GUI and the renderer are kind of blurred together in that they both will present information from the store changes back to the user, obviously the scene itself for the renderer, and maybe a tree to visually represent the heirarchy of objects in the level. They can also both accept inputs, the obvious case being clicking buttons in the GUI, but maybe not so obvious is interacting directly with the scene, selecting and moving objects in realtime, painting terrain, you get the idea.

Hopefully if you've stuck this entry out this long you recognize this as a slightly modified model view controller pattern. The store is the model, the action component is similar to a controller, and the combination of the renderer and the GUI make up the view component.

My goal with this project is to be able to implement skeleton components solidly and abstractly enough such that adding new features to them only requires minimal augmenting of existing classes and mainly extending/overriding existing classes.

I have partially succeeded in at least the data store area, which I'll have to save for my next entry.