Speculation and Request: External Event Sheets

New releases and general discussions.

Post » Tue Apr 15, 2008 2:24 am

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?
B
3
S
2
G
4
Posts: 310
Reputation: 2,120

Post » Tue Apr 15, 2008 2:26 am

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.
B
2
S
1
G
5
Posts: 54
Reputation: 1,508

Post » Tue Apr 15, 2008 7:17 am

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?
B
4
S
2
G
4
Posts: 719
Reputation: 2,938

Post » Tue Apr 15, 2008 7:38 am

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.
B
3
S
2
G
4
Posts: 310
Reputation: 2,120

Post » Tue Apr 15, 2008 7:58 am

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.
Tired of crappy file hosts that are crappy? Get DROPBOX - https://db.tt/uwjysXJF
Moderator
B
45
S
17
G
37
Posts: 2,853
Reputation: 25,966

Post » Tue Apr 15, 2008 9:04 am

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.
B
3
S
2
G
4
Posts: 310
Reputation: 2,120

Post » Tue Apr 15, 2008 10:09 am

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.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Tue Apr 15, 2008 11:30 am

[quote="CaptainOblivious":39zfofvd]
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.[/quote:39zfofvd]

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.
B
4
S
2
G
4
Posts: 719
Reputation: 2,938

Post » Tue Apr 15, 2008 1:32 pm

[quote="deadeye":14wv1a06]or you'd be loading it into memory and interpreting it on the fly (which could slow your game down drastically)[/quote:14wv1a06]

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,478

Post » Tue Apr 15, 2008 5:01 pm

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.
B
3
S
2
G
4
Posts: 310
Reputation: 2,120

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 2 guests