[Suggestion] Partial export modes

0 favourites
  • 11 posts
From the Asset Store
Collection of security plugins for web/html5 export on construct 3
  • So I have this issue since the beginning, and it's a pretty important one to me...

    When exporting big projects, it can take ages to recompress the graphics and compile the script. And because sometimes previews are not enough, I often need to export after small changes to test a feature in-context, for network-related constraints or other things.

    For the moment I've been using a workaround, but I'm a bit tired of it

    Before each export I need to set the PNG recompression to "none", and because 8bit PNGs are not affected by this setting, I set everything in the project to 32bit, then manually some of them back to jpeg, then back to the export window...

    (Not to mention the mess with the exported pngs that I have to remember to recompress later)

    Now how about PARTIAL export, where you can choose what you need to export

    to speed up the whole process

    <img src="http://i.imgur.com/GTMtXxs.png" border="0">

    I the case mentioned above, I generally just make changes to the event sheet, so why would Construct have to re-export the images every single time?

    Here you can choose the standard "Full export", or export your "Script only" if you just changed that.

    With the "Automatic" mode (which I don't need as urgently!), C2 would register each time the image editor is accessed and add that sprite to the list of media to export, along with the script if it was modified

  • Intriguing, but probably somehting that could be done automatically actually. Store the last compile date somewhere, compare that to the date-last-modified of the images, and if it hasn't been since the last compile then you don't have to recompress. I'd be very surprised if Ashley hasn't already thought of this, and it's just a matter of implementation.

  • Well, you're not supposed to use export like that, it's what preview is for. What's wrong with preview-over-wifi? It seems it would be better to resolve any issues you have with that rather than try to make exporting more like previewing.

  • I'm not developing for mobiles just the standard hmtl5 to server stuff

    Most of the times I'm using the preview for the game mechanics for sure, it's just the communication/network features that concern me

    For example how do you deal with projects that rely heavily on external sources when you're stuck in the preview with cross-domain restrictions?

    I had that project where the player avatar itself and its animations had to be loaded externally and I never found a way to do it with the preview.

    And that also concerns corrections for small bugs that happens from time to time when the game is live, after a player report, where you would just want to export the script with that tiny piece of event you changed, instead of the whole graphic pack

    Anyway, I tend to consider html5 games not like finished boxed games, but rather like websites, constantly evolving where you can just update a piece if you like, and where you can deploy a change just as fast

    I don't know if everyone else export their games a single-time-once-and-for-all, but if they don't for whatever purpose, as long as the export may happen several times, there's still room for optimization IMO when some part can be exported only once instead of every time

  • For example how do you deal with projects that rely heavily on external sources when you're stuck in the preview with cross-domain restrictions?

    [...]

    Anyway, I tend to consider html5 games not like finished boxed games, but rather like websites, constantly evolving where you can just update a piece if you like, and where you can deploy a change just as fast

    AJAX manual entry has an interesting tip concerning cross-domain, and it works on a local server (you shouldn't be working on a production website).

  • I read that page a few times already

    The resources are not located on my own server

    so I can't change the Access-Control-Allow-Origin

    (I'm totally allowed to load them though)

  • I think this is an awesome idea!

    I export to CocconJS and life would be good if I could just quickly export a script, drop it into the previously made zip file and voila!

  • I'll see if I can add an option for this. (Perhaps if the PNG recompression option 'None' really did nothing it would be fast enough anyway.) Although the cross-domain stuff would work with the HTTP header. If it doesn't work cross-domain to localhost, then it wouldn't work cross-domain to your live website either, so I'm not sure I understand how it works for you.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Thx for considering the option Ashley!

    About the cross-domain stuff, I'm using a php proxy script hosted on my domain, to which I'm making request to access external data. Now this would probably work locally if I could set an Access-Control-Allow-Origin to my domain and the proxy itself, but I'm using a free hosting for this project, and unless I missed something, I doubt they allow to change the setting somewhere

  • This would be a great feature, I export for CocoonJS and for Windows 8, sometimes I need to debug as an actual windows 8 application, and every time I need to change something Im forced to export the whole thing. It would be great just to export the script, replacing it and quoting mcdan: Voila! Ca est superb!

  • Its possible to just export the script ? I dont have this option O.o

    This is amazing, this will save much time.

    I work also on a dev server with another developer. So I could never work local.

    EDIT: "Sry I saw now that this is just a Suggestion :D"

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)