Before I get into the code behind the game editor, I wanted to post some information about how it works. I want to do this both to keep the actual tutorial shorter (because it’s looonnnnggggg right now), and to help you better understand what we are doing when we write the code itself.

The editor is meant to be used simultaneously with Visual Studio. Content, references, components, and code will be built with Visual Studio, which will then rebuilt the project. When this occurs, the editor detects the change and synchronizes with the new project. This gives us the benefit of letting us use the same IDE we are used to, and we don’t have to do things like building content and compiling code ourselves.

In the main form (window) of the editor is a visualization panel, and a panel with several tabs on it for the following subjects: Project, Scene, Toolbox, and Properties. Before I get into each of these things, I will first talk about how the editor works with a game. Basically, the editor “links” to a game project, which is just a standard Visual Studio .csproj project file. Using the projects we’ve been working with, it would be TestEnvironment.csproj. Now, when I say “link”, I don’t mean that we are modifying the game’s project or anything. Basically when we “link” to the project, we are just looking over the project and some of the directories in the project to set the editor up to work properly with that game.

Let’s start with the “Project” tab. This tab contains a tree with three main sections: Scenes, Content, and References. These things are all we need to work with a game. When we link to a game, which is done by selecting the project from a file dialog, we first look through the .csproj file, and extract the references used by the project. These are the same references that you modify with Visual Studio. For each reference we find, we load it and scan over each type it contains. If the type derives from Component, we mark the assembly as containing components and make a list of the types in it that are components. Then we add the reference to the “References” part of the project tree. Note that we will only be able to view the references from the editor, not modify or add to them, because the project will need to be modified to add new references. This is bad, because if the project is changing all the time, Visual Studio and the editor will get out of sync.

Once we scan for the references, any assemblies containing components are added to the Toolbox’s tree, with the components they contain as the children of the assembly’s tree node. Now that we have a list of available components, we can create one by double clicking on it from the toolbox. This will cause the “Scene” tab, which contains another tree. This one has GameScreens and their components organized into a tree structure. This lets us visualize the scene, and also allows us to remove components from the scene and change what screen they are on. When a component is double clicked on from the “Scene” tab, the “Properties” tab opens, with a PropertyGrid (which is the control you would see if you were to look at the “Properties” tab in Visual Studio) that is set to the selected component. This allows us to modify the component’s properties from the editor instead of having to do it through code. Later on, we will add modifiers that allow us to change the properties of components that inherit from  Component2D and Component3D, like the movement, rotation, and scale tools you would find in a 3D modeling program.

Let’s backtrack now to when a game is linked. After we find references with components, we scan for content that has been built for the game. We will not be able to add content here, this has to be done through Visual Studio for the same reasons as references, but also because it would be a waste of time to write a content builder when Visual Studio can do it for us. All the content we find will be added to the “Content” node in the project tree. We also use this for the properties tab; we will have a custom drop down menu for the property grid that will allow us to select content that is in the game’s bin/x86/Debug/Content directory, for properties that are content types, like Model, Texture2D, etc.

The final thing we do is look for scenes that are in the game’s bin/x86/Debug/Scenes directory. If this directory does not exist, we create it for use later on. If we find any scenes, we add them to the “Scene” node in the project tree. By double clicking on a scene from this area, we will open it up for editing. It should be noted that a scene is an XML export of the engine state, the system for which we built in the last tutorial. To save the scene, we just use the corresponding method in the Engine class. The same goes for loading a scene. We can do this part without Visual Studio because the scene files will never be included in the project file, so it doesn’t need to be rebuilt when we work on a scene.

A final note: We will be able to move the camera around inside the viewport using the mouse and keyboard. It will be based around the “S” key, however. Holding down “S” and the left mouse button, then moving the mouse around will pan the scene. Doing the same with the right mouse button will rotate the camera. Finally, with the middle mouse button and “S”, we can zoom the camera in and out by moving the mouse up and down, and rotate the camera around the Z axis by movind it left and right. If you’ve ever used XSI mod tool, this will all feel familiar. Of course, you could lay it out differently, but because I use XSI for modeling most of the time, I am trying to keep the camera control the same to make moving back and forth between it and the editor more easily.

This design for an editor is good for us. It means that we can rely on Visual Studio for most of the work with code and project management, and all we have to worry about is basically rendering the scene on a form and letting users modify, add, and remove components in, to, and from the scene. We will not cover all of this in the first editor tutorial, and probably not even in the second or third. So, the next several tutorials will be based on the editor.

As a final note, some of the components will need some modifications to work with both the editor and serialization engine. I will make the modifications and post the new versions, and probably go back and update the older chapters too.

Also, before I go, I’m wondering, what kind of computer do you have? I’m curious… I myself am working with a computer I built about a year and a half ago. It has two 8800gt Nvidia cards, an Intel Core 2 Duo E6750 @ 2.66 GHz, 4 Gb of ram (it’s just a generic brand, I don’t remember which one), a 500 Gb hard drive (whose brand I also forget). I am running the Windows 7 Beta, but I also have Vista and XP installed. Let me know what you’re working with in the comments!