Aeon Branch Development Thread

This'll be the development thread for discussion of upcoming progress on aeon-branch, which is the effort to add, finally, a stable and powerful form of scripting to the Eternity Engine, courtesy of the SpiderMonkey ECMAScript virtual machine.

Current goals for Aeon include the following:

  • "Code Anywhere" - Anywhere a string can go, Aeon can go. This will include inside EDF (using heredocs), where it can be used to define action functions inline with the objects that call them (similar to QuakeC or Duke3D CON), and inside properties of UDMF objects.
  • Object-oriented prototype hierarchy that will present a clean structured interface to the internals of the DOOM engine. This will include the ability to refer to actors via ECMAScript references and not only by numeric TIDs.
  • Backwards "API" compatibility with ACS via a global ACS interpreter object that offers access to all ACS functions as well as the ability to start/stop ACS scripts.
  • High-level interfaces to systems like the HUD (similar to that previously available in Small) which save the scripter from essentially writing their own game engine just to put graphics on screen.
  • Canvas objects for dynamic graphics and programmatic textures.
This is just a very small subset of what I hope to accomplish. I cannot say how long it will take to achieve all of these things, probably a good while. Part of it will depend on how fast we can develop the basic object model, and also on whether or not we get any help making this thing build on Linux-alikes.

Share this post


Link to post

This really does sound incredible. Even relatively early on in its development, before most of the stuff you're thinking of is implemented, I can see this already being a huge deal. Can't wait to see what kinds of magic can be made :)

Share this post


Link to post

Sounds fancy! Looking forward to hearing more news about this.

Share this post


Link to post

Awesome. An overused word, I know, but in this case I really mean it. Just imagine all the great things one could do with it ...

Share this post


Link to post
Quasar said:

and inside properties of UDMF objects.

This means scripts embedded right in the map? No more need for a separate lump... But will you have to deviate from the UDMF standard and support HEREDOCs there?

EDIT: whatever. UDMF doesn't limit itself to TEXTMAP, it can have other lumps too...

Share this post


Link to post

Zomg! I think I code for this port! I'm so excited!

Share this post


Link to post
SoM said:

Zomg! I think I code for this port! I'm so excited!

If you still code for EE, count me in as excited, too :P

Share this post


Link to post
printz said:

This means scripts embedded right in the map? No more need for a separate lump... But will you have to deviate from the UDMF standard and support HEREDOCs there?

EDIT: whatever. UDMF doesn't limit itself to TEXTMAP, it can have other lumps too...



You can store scripts as strings with '\n' for line breaks. When this topic came up we had a lengthy discussion about adding Heredoc syntax but aside from Quasar nobody wanted it since the same result can already be achieved by other means.

Since handling of such data is the editor's business this should be of no consequence to the mapper.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now