[request] headless exporter

Ashley

I would humbly request a headless exporter so we can do stuff similar but not limited to:

node c2runtime.js[/code:jvizve0i] 
 
without all the sugar required to simulate DOM and canvas please? It would open up a vast new field for C2 and even help with multiplayer games. 
 
Cheers!

I'd love something like that, so consider this post a "+1" to the idea. This is similar to Clickteam Fusion's "No display surface" feature available in the developer edition.

This request is very simple to explain, but I'll elaborate a bit more. Since Ashley likes use cases for this sort of stuff, here are a few:

• multiplayer. It would be great to reuse game logic in the server, but ignore display for performance reasons (since rendering is usually the bottleneck).
• App development. If construct manages to get into this (I'd love to try it), especially with construct 3's new IDE features, it would be cool to have a canvasless script (frontend or backend, doesn't matter) that could handle logic.
• Workers/widgets. This is akin to "sub-layouts", that is, layouts that run inside one another. This is especially useful for handling UI screens and similar. When that feature arrives (it's desperately needed), people will want to spawn certain layouts as "workers". This is a bit complicated so I'll elaborate more. Think about this: you have a strategy game like risk, and each battle is a mini-game. You could have the option to "auto-resolve battle", and the engine would just run the minigame without a display surface (to save processing and make it go faster, while simultaneously sparing the developer from making a displayless/event-only version of the mini-game) and report back the results.

yup, just logic, no display.

to add a few

npm modules written in C2 for node

controllers for our new robotic overlords

any other logic imaginable

Agree that, only +1 here.

If your main use case is to run in node, then there would need to be a huge set of new features to access all of node's features from the event system (such as hosting servers, opening sockets, accessing databases etc). Without that you pretty much just have an interactive game with no interactivity, which isn't very useful. So this sounds like a pretty huge feature request - almost another product by the sound of it.

Without that you pretty much just have an interactive game with no interactivity, which isn't very useful.

Where one man sees a desert, other sees a bunch of sand. Also, if an entity has no interactivity, it is not interactive anymore.

The idea behind the headless export is in removing stuff from the engine, not adding. It would allow to use c2 projects as any other JavaScript library, it can expose that api over any available channel per wish of a designer/developer. For something to be interactive it does not have to have a gui. it can be interacted with over sockets, functions, databases, etc...

Regarding the functionality, the SDK is a perfectly suitable tool to implement any API that is in the mind of a game designer, no need to have that implemented just for a headless exporter. Actually, i vote for a totally different approach; the logic is one part, the renderer other, the sdk with plugins the third, and by skimming the source of the c2 engine for the last two years, it doesn't seem impossible.

It's cool, a close approximation of a headless exporter is achieved with exporting through nw, hiding a window and using it as a silent exe/other format, and communicating with it with any kind of preferred way. Some of the multiplayer stuff i did is hosted that way and it works, a working http/socket.io/udp server written in c2 is already deployed an live and accessible through a public ip/url . But it's hacky, we have to have all of the nw juice to get it running and it makes scaling a lot more difficult and a lot of computing resources for stuff not required.

I'm kinda sad you don't seem to see a wider picture here, games are not just what a player sees, games are multiple systems behind the game. Having c2 exporting pure logic will be beneficial for all kinds of aspect for a game dev. Also, i must say i'm making this request as a game dev, not a software guy trying to do non-gaming stuff with c2.

Although, again, i'm surprised you don't see benefits of a headless exporter would bring to the gaming aspect of developing possibilities with c2.

tl:dr; this is not a priority request, and is doable with current stack, but...

If your main use case is to run in node, then there would need to be a huge set of new features to access all of node's features from the event system (such as hosting servers, opening sockets, accessing databases etc).

What? We just want to be able to skip draw calls so we can get 100K objects or something similar without having to recode the entire thing. Like I said, this is especially useful for multiplayer projects using the authoritative server model. There's no need to expose node's APIs, we can do that ourselves with extensions.

If you can cut off the DOM as well (which is another source of slowdowns), we'd be able to run it inside webworkers, further extending this usecase.

Without that you pretty much just have an interactive game with no interactivity, which isn't very useful.

You have an easy, hassle free multiplayer server that you can keep running without wasting CPU/GPU time with drawcalls that no one wants anyways.

So this sounds like a pretty huge feature request - almost another product by the sound of it.

While I'd love a corporate version of construct geared towards app development, and might pitch that idea sometime in the future, I don't think this is that idea. What we're proposing is just ripping the canvas off, nothing needs to be added.

If you run the C2 engine in a browser tab, and set all layers to invisible, and you don't use any form controls, you already have an authoritative server that has no rendering overhead or use of the DOM.

has no rendering overhead or use of the DOM.

Thank you for your input, but with all due respect this is false.

So basically you want something like a server without a gui?

> has no rendering overhead or use of the DOM.

>

Thank you for your input, but with all due respect this is false.

Can you expand on this please?

> has no rendering overhead or use of the DOM.

>

Thank you for your input, but with all due respect this is false.

Why? It will spend no CPU time in draw calls, and the only DOM usage will be an unchanging canvas element. Maybe there will be a bit of memory overhead, but most machines have gigabytes of memory these days.

Ashley

It is not possible in my knowledge to use the generated javascript without the accompanying index.html and some canvas object in it. With canvas and html comes an overhead of chromium or some other wizardry like jsDOM to make it execute. Although the renderer is idle, and the DOM is probably not used in any active way, the utter existence of them in your process and memory provides an overhead. Sure, that can be avoided by throwing more resources to it, but is that the right approach? I dunno, that's why i'm here to talk.

It could be possible to make an plugin and/or introduce some settings to the editor to make the "nw headless" exporter easier maybe, and provide some communication channel to the headless instance?

So basically you want something like a server without a gui?

Yes, I tried to find a way to deploy JavaScript application made by C2 on heroku server (node.js) before.

A way to program node.js like we do in C2 would be interesting.

Especially considering all the existing npm's.

Of course I doubt those would be used easily by C2's runtime.