Ashley's Forum Posts

  • We don't have the resources to integrate all possible third-party services. The other companies they mentioned are bigger and it's probably much easier for them to justify the developer time, but we're a tiny company and just can't afford to do that. To work around this problem, we have created a third-party addon SDK for other developers to intergate their services themselves. The Spine developers should use this. What they said about performance isn't right and looks like a way for them to try to get us to do their work for them - unfortunately we just cannot do that. Meanwhile Spriter have used our SDK to write their own integration and we got positive feedback from the developer, so I think we have everything set up well and with the full performance capabilities of the engine. We worked with Spriter to fill in any gaps in the SDK to ensure everything works well (although there are still some nice-to-have requests we have on our todo list); I am prepared to do the same with the Spine developers to fill any gaps and ensure they can implement a fully capable integration, but we cannot do it all for them. So long as there is no Spine integration I would recommend to use Spriter instead.

  • I can't comment without an example project to look at. Otherwise all I can say is: I guess that shouldn't happen.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Why not just try it and compare?

    It means you only need to do an export over local files instead of having to upload to Facebook and publish, which should be quicker. Note you should still use the Instant Games export, not the HTML5 export.

  • Fengist - I think you missed the bit where I wrote this:

    ...I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

  • BTW let me know if you do file an issue - I'd be happy to follow it and explain any Construct-specific details that come up (if any).

  • I think this idea in general is fairly close to something workable, but I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

  • Couldn't you do this mapping in events? Kinda of how you map strings to function you can map dom element events to c3 functions. You would just need a bit more information such as the element ID and the event you want to map?

    How would you access event parameters like the button or key that was clicked/pressed? I wouldn't want to have to try to cover every kind of possible event and event parameter that exists in JS, that's a lot of work just reimplementing what JavaScript already does.

  • I'm not convinced it's a good idea to have "solved" tags. If someone asks a question, gets a bad answer, and then marks it "solved", that would discourage anyone else coming along and offering an alternative - and possibly better - answer.

  • Check for an error in the browser console. Also some emulators are buggy and broken - try testing on a real device, it may actually work there.

  • But isn´t iframe a weird approach for this? How would you create something like this?

    [/img]

    Well, I was thinking you'd generate a string of HTML representing that layout, and set that in the iframe. I'm not sure why you were talking about making a whole website.

    Inevitably with either an iframe or a HTML element you will need JavaScript to be able to link events to DOM elements. Given your example, presumably you'd want some kind of capability like attaching a click event to an <a> element inside a <div> representing the third column of the fourth row, and have an event that triggers from that. It's not clear to me how that could be solved in events alone - you could use <a onclick="...">Link</a>, but what would you put in the onclick? And by that point you're writing JavaScript anyway. This makes me think the JavaScript feature is probably a more appropriate place to address this. You can use the standard DOM APIs to find elements, use elem.addEventListener("click", callback), use the callback to call event functions, and so on.

  • The games run smoothly on the mobile phone app and the desktop version as well. The lag only appears when it is hosted on a test server on Facebook development servers.

    This is pretty good evidence the issue is with the Facebook Instant Games platform and not Construct. That means there's not much we can do about it if you report it to us. You can report issues directly to Facebook here: https://developers.facebook.com/support/bugs/

  • I don't have teaching experience myself, but I imagined that the best way to move from blocks to scripting would be to use scripts in actions. This lets you start with blocks, and then add just a single line of code, e.g. alert("Hello world!");. Using these you could then expand out to variables, loops and so on. However as I said I've not tested that in a classroom, so I think it's up to you as the teacher how to best approach it.

    Regarding comparing events to JS, it seems difficult and potentially more confusing, because the way blocks work is very high level and quite far removed from the type of idiomatic code you'd write in JS. Just off the top of my head, one example of that is how "On collision" in the event sheet runs upon two objects colliding, but in scripting you'd instead have a "tick" callback (equivalent to "Every tick"), two nested for loops iterating all the instances (equivalent to the internal picking of conditions), an overlap test (to identify collision), and then some kind of memory to discard repeat overlaps so it only runs code upon the first overlap (equivalent to the internal memory that "On collision" uses to make sure it only runs upon the first overlap, and not repeatedly afterwards). Explaining all of this seems pretty complicated, and I'd have imagined an easier approach would simply be to explain what the "On collision" event does (rather like outlining a specification), how to replicate that in JavaScript, and then just finish with "and that's what the "On collision" block does internally". What do you think?

  • See the official documentation's section on Testing the game from a local server.

  • Your JS code uses $, which is jQuery. Construct 2 uses jQuery, but Construct 3 does not, since it's no longer necessary. Assuming the CORS configuration etc. is correct, you just need to swap that for fetch.

    BTW it's helpful to post any error messages that appear, since that should have had some kind of error involving the fact $ is undefined.

  • My issue with the dom, and html elements is that they are always on top, and not rendered at the same time.

    We need a webgl equivalent.

    This is inconceivable - form controls are actually incredibly sophisticated and have many deep integrations with the browser and OS (e.g. IME inputs for non-English languages). Rebuilding the form controls themselves in WebGL amounts to writing a significant portion of a browser engine. There's no way that's a feasible approach.

    You mention opportunity cost and the small size of C3's team a lot. Have you considered expanding your team?

    We already did. Moving to the subscription model for C3 allowed us to sustainably expand from just one developer (it was only ever me working on C2) to three, and that's helped us get way more done. Right now we don't have the resources to go further. I think "just hire more people!" is just another case of the "they should just do XYZ!" problem I mentioned in the first place.

    Just a layout mechanism for placing different elements... nothing else.

    Well, that's pretty much what the iframe object can already do, but securely by default. Is there any particular reason that doesn't do what you need?

    3) Java-script is a huge issue for Construct. We haven't seen anyone creating anything special for the time being with Java-script.

    Construct 3 was released in 2017, two years ago, and we only just announced the widespread availability of the JavaScript coding feature 3 weeks ago. The only reason nobody's created much with it yet is because it's still very much a new feature that was only just released! It may well be a good avenue for implementing better GUIs and I think that should be explored - but it's too soon to draw conclusions already.