Speculation and Request: External Event Sheets

We currently have tons of great tools for using outside scripting in our construct projects, but why not consider another? External event sheets, used at runtime. Here's why.

Construct's event sheets are already incredibly modular. The only limitation I can see so far is that they are internal-only. I'm no developer, so I don't know how deep of a hole I'm digging here... but I ask, how easy would it be to load and integrate external event sheets in compiled executables?

I would speculate there would be some limitations. I can't imagine doing it on the fly, but what about before a new layout is loaded? This would greatly open up expandability without the need for prior experience in python scripting. Want to let your users create custom levels? Define your major functions in the original event structure and allow them to be called through variables externally. Because construct's event system is easy to understand - even in pure text form - all you'd need to do is create an example expansion file for a user to modify.

This all comes on the heels of a discussion between me and Deadeye in the Help/Tech forum. Are we on to something, or is this simply impossible?

I like the idea. I think it would be great to be able to reference other sheets or load them on the fly, for user content. That would be awesome- great idea.

We are probably on something useless? becouse i dont get why would you want transfer? to another application/game, whats the point? Every app got his events that it needs so why?

Custom levels, or add-ons later if a major version change is not necessary. But really, I'd be excited about user content. So long as I build functions within my game to support it, I wouldn't mind allowing the player to load his own "encounters" into a blank level, complete with enemies, dialog, and a small amount of predetermined layout options.

Or how about this argument, Doppel: Why NOT have this functionality? No need to stifle creative potential for the sake of it being useless to your specific needs.

I have to say this is an exceptionally good idea. I like the line of thinking when it comes to expansions etc... but even patching your own game with updates and fixes. If an existing "script module" already exists, then it would be overwritten with the new one, if say making a patch for example. This would save major rebuilds and distributions of large games, particularly once you start getting into the 100's of Mbs for a game (like CarKill will likely end up being).

Consider this signed by me.

Let's not get our hopes up just yet. Until we have word from Ashley on the feasibility of any of this, it's just a nice dream.

I see a couple of problems with external event sheets. Internal event sheets in Construct are compiled before running (built into an .exe). If you were to have an external event sheet, either you'd be compiling it at runtime (which would be beside the point of having external event sheets in the first place, and would require a "Construct Lite" type of compiler to be embedded in your game), or you'd be loading it into memory and interpreting it on the fly (which could slow your game down drastically).

Personally I think all of this user-content stuff could be made easily with better support for .ini and .dat type files. If you made an editor for your game to save level info as a separate file, you could just release the editor with the game.

And if you wanted total modability for your game you could store your graphics as external files and AI sequences and such as .ini's.

With .ini type files that information just gets loaded into variables and run by the code already compiled in your exe. It would be way lighter and faster than interpreting Construct-like commands from an external event file.

I hate to be the naysayer, but it just seems like a lot of work for something that could be solved more simply and efficiently.

Or how about this argument, Doppel: Why NOT have this functionality? No need to stifle creative potential for the sake of it being useless to your specific needs.

I just dont know why do you want to make "Game Creator" in Construct, custom levels are ok, but importing AI can be done without CiC (Construct in Construct) so i dont see the point of having it at all, its my opinion and im not a king here.

or you'd be loading it into memory and interpreting it on the fly (which could slow your game down drastically)

Events are already loaded in to memory and interpreted on the fly, so no big problems there.

All in all it's a fairly good idea, but I think its a post-1.0 type of idea, considering weighing up benefits and workload. It wouldn't be particularly easy to code, since you'd have to deal with situations like someone saving an event sheet for their platform game and trying to import it to someone's RTS game.

The main use I see for it is quick patching - if all your events are exported as external files, you can do bugfixes and distribute the small event files as the patch update. Writing mods with this system is trickier since you'd basically need the source .cap to generate a valid event sheet (with the right object names in the right order with the right behaviors and effects etc), which kind of defeats the point - Python would be much better for mods. This patching method also has a number of drawbacks:

• It's not that far off redistributing the main .EXE for a patch, which isn't too difficult usually.

• If you want to ADD an object or something, it's useless - go for a normal patch again.

• If you want to change any of the graphics, effects, behaviors etc, again it's not effective.

• Even with a 200mb EXE with events-only changes that you want to patch... existing patching tools save differences between files only, so chances are good you'd have a tiny patcher still. And this method of patching has none of the above drawbacks.

Nice idea, but I think it needs careful design to get around some of these issues.

A simple unique program ID would solve importability. Load event sheet / ini, check ID against internal ID.

And although this COULD be used for patching, I'm really thinking more of a level editor thing. Like Smash Bros Brawl, where users can use existing objects with a small choice of backgrounds and place them how they please. Or in my case, much the same with a little more flexibility within my own custom encounter scripting. No objects or textures need be added.

After all, you're right about patching tools. And yes you're right that python is better for mods... but I'm aiming for the end user, not the master modder. Construct event structure is far easier to understand and incorporate into an existing project.

I'm not sure but I think im missing some points here, if you want users to be able to design their own levels would it not be easiest to create a level editor in game and be able to export and import them? This way would be a lot more user friendly as well.

if you want users to be able to design their own levels would it not be easiest to create a level editor in game and be able to export and import them?

I think he also wants to let users modify how the game acts, not just where objects are.

but I'm aiming for the end user, not the master modder. Construct event structure is far easier to understand and incorporate into an existing project.

Couldn't you just make a frontend that mimics the construct eventing style and exports into python scripts that your game would understand? Like how a savegame editor presents the user with a nice little environment with help boxes and information for something that would just show up as "Level=10" in the INI file?

That' a good idea, but I myself have no experience working with scripts, much less exporting and reintegrating them later. I was thinking I'd wait until the wiki had more information before I began exploring that.

Another way I've considered is through INI files, although that's much more like translating from a translation.