Fractured Foundations

Realizing something or finding out hours were spent developing something minor or irrelevant seem to be a common trend when working on research projects.  I’ve got a few pictures and some updates to talk about that I’ve gotten done since the last update but those will be put off a little but as the last few days have really altered my perspective on this project.

The first step in getting this whole issue straight is to identify just what I’d been focusing on and the areas I thought would be most important.  Specifically this area was giving artists and designers an easy to user interface to create generation procedures.  This really focused on the interface and how the artists used it to do new things and create content in new ways.

This original intention is very broad but also doesn’t really put into perspective the projects goals.  The way I outlined it was really this radical new  way of interacting with users and making the underlying technology a minor player in the whole thing.  In my head I had that as the appropriate prioritization of the project.  However as I’ve progressed it’s been far more obvious that my true intentions were to make a middleware type library that was capable of loading user created graphs and generating assets for use in a game engine.

You may now be asking: “Woah there, that’s the same thing really isn’t it?” To which my answer is: yes on the surface and at either end of the pipeline it sort of is.  However when it comes to scope and being able to say what’s “new” about my project it really brings the obvious answers to the surface.  My use of node graph and visual programming style interfaces aren’t new, they’re directly inspired by existing paradigms and even specific tools.  The state of the art would point out that these are infact very succesful ways of doing things and why I wanted to use them.  At the other end of the spectrum using procedurally generated content in game isn’t new at all either.  There are plenty of examples of assets being generated in external applications to be imported into games, there are also examples of features within game using procedural methods to create elements that they will use.  My real contribution is this middle ware library that takes as it’s input a formatted generation description that it then parses and runs to provide a defined output that is an asset a game can understand and use.

So, where’s the huge change?  Well it feels a bit like designing the first ever car and slapping a body together, popping a comfy seat and a steering wheel in for the driver, assuming the engine will go up front and the putting shiny wheels on it.  I’ve been praising the wheels, both steering and rolling, designing them as being the important feature to it, no wheels, no rolling, no control, no car.  However the fact of the matter is I just assumed mechanical details and that the engine would just happen.  Taking a step back I can see the engine itself is the crucial piece of technical detail.  It’s the true heart of the car, the steering wheel may allow the driver to control the car and the wheels on the road may let it travel about but both of those have been done before, it’s the combustion engine that drives it all.  The pistols firing away turning the crank to push power to the drive wheels to make it go and the throttle pedal giving the driver control over just how much power the engine should put out.

The analogy is rough around the edges, but the point is there.  What I want to do is really delve into the specifics of how my “PrEditor Engine” will work, define the inputs and outputs so the Editors can control the procedures and the games know what they’re getting.  I had intended the Engine to be an implementation detail, mostly ignored with the “usability” factor being the key selling point.  Well that’s turned out to be jumping the gun hugely.  Yes a node based editor is really cool and I’m not ditching that, as well as the demo frame work it’s hanging about, it’s just I’m going to have to REALLY put a lot of effort in to make up the lost time on the Engine.  It’s where I’ve wanted to be, it’s not something to be thought up after the Interface is created.  It’s got to be the key stone in all of this.

I wanted to try and approach this as a Rapid Application Development but the very thing I was trying to avoid was the most important detail.  I don’t have a system in place that needs to accessed, I don’t have a team of artists waiting for an easier way to create procedural content, I’m on the very tip of the technical side trying to create a reusable and expandable library that can be used to do all that with.

So, back on track, not all the old work lost, but certainly not what I am going to focus on as my key development goals.  They are ultimately just a way of facilitating generation of and rendering the outputs from the core engine.  From here on out the PrEditor Engine might need a new name, so it’s a Procedural Generator rather than a Procedural Editor, the editor is merely part of the toolkit used to create the inputs to the system.

This means for this week I’m going to try and wrap up to some degree my work on the editor and demos and really have to get to the drawing board with this engine implementation.  What was a fairly straight forward and thrown together system to create the means to an end will have to be come a strongly defined process.  By the end of the week I hope to have the structure of the input data, the parsing and graph generation process, the node definitions, the graph execution and the setting of input data and retrival of output data atleast in the research phases if not early definitions outlined.  I plan on sticking to the avoidance of over engineering and keeping it straight forward but I also want to tackle head on the crucial points I’ve uncovered about where and how to define data types that will be extensible but still be able to run as part of a generalised node graph.