VideogamesI have been making videogames for over twenty years, and the process always seems to go something like this:
- Design game
- Create assets
- Write code
- Test game
- Repeat above in various combinations until done (ship or bust)
Some time ago I came to the conclusion that above a certain project size this model isn't very efficient for a variety of reasons. Firstly, because assets need to be worked on by multiple people, the friction associated with moving them around (conversion, source control, management, communication, builds, deployment, and loading) can mean lots of additional effort and add up to long and frustrating iteration times. Secondly, as projects have become more ambitious, with larger scopes and game-play areas where the work involved in creating them increases exponentially (with area/volume), the cost also ramps up this way because the work a team puts in can only, at best, grow linearly with size. In addition to this, a natural consequence of growing teams is the need for increasing communication, management, and support. All of these pressures usually mean compromises being made to the game's detail, richness, variety, polish, quality, or seemingly low priority support work is neglected, in order to get it to fit within the budget.
Pondering this problem for several years I have formed a vision of how I think we can improve this construction and authoring process, and what the technology and tools it requires would look like. I'm fed up with conventional approaches, the waste, the sluggish pace, the repetition, the tighter squeeze on the more fuzzy aspects of creativity like experimentation, play, fun, emergence, and instinct. I want to try working a different way, using novel and interesting techniques, powerful technology and tools, to empower smaller teams to create bigger things. I believe we can do better, and whilst it won't be everyone's cup of tea, it's something I believe passionately in.
"I'm fed up with conventional approaches, the waste, the sluggish pace, the repetition, the tighter squeeze on the more fuzzy aspects of creativity like experimentation, play, fun, emergence, and instinct."I've been working on this project in my spare time for around five years, with the original concept rolling around my brain for about five years before that. As I described in my previous post I am now in the fortunate position to be able to invest all my time in this project. So, what exactly is it I am proposing?
- Rich worlds full of the variety that parameterisation and procedural techniques can enable.
- Vast structures with intricate detail from highly scalable dynamic modelling.
- Endless continuous worlds with no loading and no transitions required.
- Don't repeat to save time, every instance can be unique in design and appearance.
- Instant feedback and fast iteration from rapid and responsive tools.
- The play and exploration that real-time control systems with live editing allows.
- Freedom from bulk assets and offline asset pipelines by going fully run-time procedural.
- Increasing the efficiency of creating content through asset modularity and easy reuse.
- Making extensive use of visual editing paradigms (data-flow, node-graph).
- Removing hard coded content, everything data driven.
- Small footprint applications yet with all the richness of today's larger titles.
"If we aspire to travel to new lands but the vehicles to do so do not exist, we must first build them."
What it isThis is an authoring environment in which to create your worlds, populate them, and bring them to life. The real-time synthesis engine uses procedural definitions, their input parameters, and the surrounding environment to dynamically fill out the world in more and more detail as you explore.
|Apparance Editor - Procedure graph for roof section of an old house|
The editor provides authoring and testing of the world through a visual flow based editing model (nodes and wires) to create the procedure definitions describing the geometry, texturing, effects, physics, behaviour, logic, and much, much more.
A standalone player application provides a non-editable view of world, for test, play, and release.
The underlying engine contains the technology driving both editor and game, using highly concurrent operation, with dynamic detail management, largely stateless data-flow control and AI systems, and all with live editing/monitoring during authoring and play.
What it is notIt is not a silver bullet and won't solve everyone's problems; Some games won't fit the development model and technology being created here. It may be that a game relies heavily on areas that are a particular weakness for this technology. Some games are based on very tightly controlled and designed environments and behaviours. But I believe that working toward its strengths and away from its weaknesses is no different to any existing games development, more so historically as hardware and software capabilities have applied their own unique constraints on possibility.
I don't see it as a plugin for other engines; using a lot of unique techniques to achieve its aims means it may not work well in more conventional engine scene graphs and rendering. The lack of scalability in many existing systems can cause problems too as non-scaling systems 'crowd-out' the scalable ones as a project grows. This is a disruptive technology, and relies a lot on the interaction between the various novel techniques at play.