Interfaces and Polymorphism
One of the biggest concepts that have stuck hard in the new structure of the engine is strong use of Polymorphing topics and interfaces. This is extremely important for users who would plan to extend the engine and add objects without having to write crazy wrappers around my rendering and content systems. Almost every object in the engine implements an interface, and almost all of the internal systems use the interfaces and NOT the objects directly to handle core features. For example, all content reference objects are interface driven and apply specific rules that the rendering pipeline requires. So, the rendering pipeline only requires the interface and proper implementation. Therefore, this can be extended very easily so long as the interfaces are implemented correctly. The most recent IO systems are nearly 100% interface driven, and probably show the extensibility of RuneEngine at it’s peak. The physics system exposes no objects, only interfaces and attaches to physics engine wrappers, so to add a new custom engine is trivial(well as far as making it work with RuneEngine goes).
As you can see those are some major area’s and they are very simple to plug into the existing API. This makes my life especially easier, but other’s using the engine could gain the same benefit as these interfaces are not internal and can be used by anyone.
Key reasons for the high focus here are obviously for extensibility and generic behaviors. This benefits mostly programmers, but that high benefit could allow a team to do much more with RuneEngine than what I allow them to.
Internal Code Cleanup/Optimization
This is a huge reason I started restructuring the engine. My goals for what I wanted it to be changed a few times during the first structure so the internals were getting haggard and the calling conventions were inconsistent.
So what are the new guidelines and why? First a little history of what it kept shaping around originally. When I first started the engine it was designed to be built like C++, well I took that a little too seriously. So, I backed off that and went way the other direction for a while. The object oriented model has always been very important through development of this, but some pieces were being written poorly, and as the ideas changed the legacy code was not getting removed. This made the code base fairly hard to work in as there was a mix of all sorts of styles. Before I started the restructure I gained an even better handle over C++ development and stay well practiced with it building many prototypes first in C++. The C++ iteration was started for RuneEngine. This is when I saw how poorly they were going to correlate. Some parts would work fine while others would need full rewrites. Therefore, the engine began restructuring. I use the term restructuring because I have not rewritten much of the internal code, just optimized and sorted it better. Much of it has not changed aside from areas where the objects used were changed greatly.
Ok, so let’s focus more on what has happened internally now. Originally there were a lot of methods calling methods and deeper callstacks, well now unless completely necessary every method is completely self maintained and does not internally call upon another. I’ve made my method argument lists more appropriate for C++ porting. However, I have also added higher level overloads which do not look as much like C++. Naming conventions have been held true, and many fields are marked internal now. Using statements have been cleaned up(this can actually be a huge optimization). All of this has made the performance better and the cleanliness much greater.
Exposure of High Level and Low Level methods
Before I only really exposed high level methods to access features. Although, I did have internal methods to do much of the low level portion as well. The biggest change here is that the low-level methods are now public and cleaned up. This also gets back into extensibility of the engine. If I don’t expose these methods then users of the engine will still have to handle things the XNA way. My methods just make that process a little simpler, even the low level ones.
IO vs Content Pipeline
This is a big change more so than original design at all. Originally there was a high focus on the IO system to load files which were unique to RuneEngine. Well, to adhere better to XNA and what XNA developers are used to, I am extending the ContentPipeline for many proprietary formats. Of course the C++ iteration will need some major differences here, but it should be manageable. So, pretty much all Rune specific content types are extended in the pipeline. And therefore could be used without any feature in RuneEngine at all.
Compartmentalized Design
This has been the plan since day one. Each DLL has been designed to be completely self maintained and features are being better designed in this new structure to hold true that they can work without the rest of the engine. I do this by writing majority of the objects completely independent from the rest of the engine. I had made some mistakes in the original structure, primarily the content systems. The content was reliant on every other part there, and the Graphics wrappers I had built as well. Now they’re self maintained and as stated above can be loaded through the content pipeline and be used with normal XNA projects.
Platform Target considerations
This part is simple, I’ve focused towards XBOX360, because it has more restrictions than PC and it’s not a mobile device. Not to hark on mobile, but just because market studies show it as the better revenue stream doesn’t mean it’s my primary focus. I prefer to focus on maximum quality I’m capable for. I’m not going to downgrade the output by adhering to mobile. This is a personal stubbornness of mine and I admit that, but I am NOT ignoring mobile. Just I will build the engine focused against everything else and make a mobile build later. Adhering to 360 and REACH profiles are going to keep me closer to what mobile will expect, so I am genuinely not concerned.
Development Tools
There is a fairly large concern here as well, but none of this matters if the engine itself behind it is not backing it. So, I’ve rebuilt a lot of the editor and have a lot of plans for working new features into this side of the engine. There is also a strong feel for extensibility here.
That about wraps it all up, there is not much more to point out at this time. Of course there has been a lot of time spent some days determining what a method should be called, and where it should be located. I didn’t think any of that detail was that important ;-D. Anyways, until next time…
