Epoch R10 Scheming and Plotting
In my last little blurb here I mentioned I'm rewriting the entire project, more or less from scratch. The vast bulk of existing logic has been scrapped, and the architecture is changing very heavily.
Before I dig too deep into the details of the architectural shift, I'd like to clarify the actual intention of the Release 10 rewrite, as it wasn't really all that clear in the last post.
From a conceptual point of view, the R10 plan is to transform Epoch into a meta-programming language. In fact, the core Epoch tools will not actually specify a language. Rather, they will specify a set of meta-programming rules which can be used to construct a language. The Epoch standard library will contain a definition of the Epoch language itself, which will permit easy reflection on Epoch code and some other nifty tricks.
It is important to note that I'm not trying to build a family of languages here. The use of Epoch's meta-programming facilities to define the language itself is mostly for the purpose of consistency: I want user-defined meta-programming entities to behave just like the first-class entities that define the Epoch language itself. In other words, meta-programming code that you write (as an Epoch programmer) will have the exact same power and flexibility as meta-programming code I write (as the language implementer).
The motivation for this shift is largely based on opinions I gathered at GDC'10. A significant number of programmers are looking for a tool that they can use both for their low-level engine/systems programming work and for higher level things like gameplay scripting and so on. Right now this is typically handled by blending multiple languages, but that can become unwieldy very quickly for complicated systems. There are many benefits to working in a single, uniform language from top to bottom; the goal of the R10 restructuring is to deliver a language that can promise those benefits with no loss in flexibility, expressibility, and power.
In a nutshell, the idea here is that software can be built by defining increasingly abstract "layers" of domain-specific languages. This approach delivers a huge amount of control over the nature of each layer. In particular, in Epoch, each layer can sport its own user-defined syntactic extensions, and actually restrict access to other layers via a system I'm personally referring to as "access control lists." Each layer can be defined as a self-contained unit, with well-defined and strictly enforced interface ties to other units in the system.
This encourages rigorous decoupling of unrelated modules, which is obviously a good thing. The other promising aspect of developing in this style is that each module's programming language can be carefully tailored for its target audience. Don't want your AI scripters being able to mess with the graphics engine? Define your AI module behind a closed interface, and use ACLs to block off the graphics modules. Need something that mission/quest implementers can use to write really terse specifications for a mission? Define a set of syntax extensions, so that the code physically looks like the kind of specification needed.
Additionally, this style of development can be used to do some serious blurring of the line between code and data. If you really wanted to, you could do things like define syntax that creates a 3D polygon mesh; write your exporter so that it takes an artist's model and converts it directly into the given blob of code. Executing the model "data" can then actually load the model into memory and prepare it for rendering directly in the engine.
Unlike developing with multiple languages, using meta-programming to define embedded "mini-languages" like this enables you to use a single toolchain for the entire development process. Having a problem with your embedded scripting language? Use the existing Epoch IDE and debugger tools to trace it down. Getting bugs from a highly abstract piece of code that you can't quite track? Use the reflective capabilities of the language/tools and expand that code into exactly what it looks like to the compiler, and debug the expanded version.
To summarize, Epoch is intended to make a major change in the way that we can work on complex software systems. The real bonus, though, is that there's no rule mandating that you have to write software that way in Epoch. You can learn the syntax in a day, tie into existing C/C++ code trivially, interface with basically any C-style APIs available, and code in any mixture of procedural, object-oriented, or functional styles. You won't pay for features you don't use, which means the transition to Epoch should be smooth and comfortable for anyone with the (minimal) requisite programming skills. Best of all, all the powerful goodies of the language will be waiting right under the surface, ready for when you become comfortable enough with the language to start exploiting them.