Resurrection

In my last post, I focused primarily on the long-dead game engine Finality, outlining its strengths, weaknesses, and eventual demise.  I mentioned its successor, the Resurrection engine, only briefly, because it deserves an independent beginning.  Without further ado, I give you the official announcement.

Ladies and gentlemen of the internet, I hereby formally announce the birth of a new project:

The Resurrection Game Engine

Technical Details and Direction
Resurrection will be written primarily in C# .NET 4.0, with F# and IronPython interspersed where appropriate.  Development will progress in phases, with each phase presenting a fully functional set of features designed to be extended in the next release.  The project will not be rushed, so results may not be immediately forthcoming.  That said, I am quite confident it will not take the better part of a decade to produce something enjoyable.

Central to the engine's design is separation of concepts from details.  The process behind movement, for example, will be indifferent to the source, target, and destination of the move, meaning it will happily move a Realm into a Treasure Chest--provided the realm is configured to be movable in game space and/or to treasure chests.  At the same time, neither the realm or the treasure chest is expected to provide such a configuration.  It will be accessed however many times it is present, and memory allocation will follow the same pattern.

- It is safe to stop here if you hate long posts -

The bulk of such configurations will be created dynamically and stored alongside normal state information; however, certain internal associations may be compiled into the engine if they are immutable by design.  For example, it is known that all objects managed by the engine will need to be grouped and categorized in several ways, not the least of which is determining if, when, and how an object will be persisted.  Movement will handle moving all objects between these groups, and this particular use will be compiled into the engine's core, providing enhanced performance and an assurance that the feature will be available; however, because it is handled by the same code that moves players through doorways, the potential exists for such radical extensions as creating an in-game key that locks and unlocks persistence groups, or a bag that contains any objects (realms and all) which are configured to save to a certain XML file.

Beyond such esoteric implementations, this design creates many opportunities to combine existing functionality in new ways.  More importantly, it does this without requiring recompilation or the possibility of creating new bugs, though a new use may make an existing bug more apparent.  In such a situation, resolution is fairly straight-forward, as any bugs involving movement of any sort will invariably reside in the movement process--a single block of code.  Similarly, if it is decided that movement must be optimized for efficiency, only one block of code must be changed to improve the engine's overall performance.

The benefits of this approach extend well beyond flexibility and maintenance of a derivative work, providing substantial benefits to the engine at the most basic level.  Because each game process is inherently static and predictable, it's easier to use multi-processor hardware to its fullest potential.  Each process declares what type of data it will access, how it will access it, and if necessary, what forms of concurrent access are acceptable.  For example, it goes without saying that the movement process will only ever write to locations, and it will only ever read locations, location spaces, movement blockers & enablers, and movement modifiers.  Further, it's simple to say that any process that cannot read or modify location data for the object being moved can safely share read/write access to the locations data segment, meaning 99% of moves may safely be run in parallel under a common resource lock, should the scheduler determine it would be beneficial.  On the other hand, processes attempting to read the contents of any object will be blocked during this process, because it is not known which objects will be returned.  As a result, a server with 20 cores could potentially process 20 moves and 20 look-ups in barely more time than it would take to process 1 move and 1 look-up on a single core machine, plus the cost of managing it all.

The approach also paves the way for a combination of consistency and diversity for players and developers alike.  All reused functionality will have the same basic characteristics, creating a sense of order and familiarity for players, if only on a subconscious level.  That same consistency can be leveraged by developers to create more complicated, compound features, secure in the knowledge that what they create cannot easily break the core of the game.  Each component process will know everything it needs to know to do its job properly, leaving the developer to focus on what matters: creating something that adds to the player experience.

That's all the explanatory energy I have for tonight, and this is as good a place as any to stop.  There's just one last thing before I go:  I want to make it clear that I intend to greet all comments, suggestions, and criticisms with open arms and honest consideration.  No project can succeed without quality community feedback, and I encourage all readers to participate.