Ashley's Recent Forum Activity

  • 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.

  • The problem with a scale expression is: if the object is twice as wide, and half as tall, what is the scale? There isn't one, there's only a scale for each axis. So we could probably add a XScale and YScale expression in future, but not a Scale expression.

    Handling backwards compatibility is a difficult question - so far we just try to choose names nobody uses...

  • You're all barking up the wrong tree and I already gave you the right solution:

    I think you might want to take a look at the section "controlling framing" in the tutorial Publishing to the web.

  • One of the problems with designing game-specific GUI features - particularly inventories - is every game does it differently and needs something customised to the particular game. This makes it really hard to design a general-purpose feature that covers it adequately. Even if we tried I am sure we would then be dragged in to a rabbit hole of endless customisation and extra bells and whistles that everyone would want for their game. GUIs are a vast and complex area just by themselves - enough so that there are entire companies out there whose sole product is a GUI library. It's easy to sit back and say "they should just do XYZ!" but I think this would really be a huge project with significant opportunity cost (displacing multiple other major features) and risk (what if after all that work it still doesn't do exactly what your game needs?).

    Construct's philosophy has always been to provide the building blocks to make your own games, and not just hand you "cookie cutter" features that are basically the only way you're allowed to do things. For example there isn't a "Turrent Defense Game" object that handles the entire game for you - instead there are a series of individual features (pathfinding, turret behavior, etc) that can be composed together to make a turret defense style game. This is a much more flexible and powerful approach.

    There are already several options for building GUIs, including using sprites/9-patches/etc on a GUI layer, using HTML in an iframe object, or using the new JavaScript feature. If these are inadequate I think the best approach would be to identify the kinds of building blocks necessary to make it easier to design your own GUIs. I do think it would be madness to try and invent custom layout systems in the Construct engine when HTML already has lots of mature and sophisticated options for doing that (e.g. flexbox, grid layout, tables etc). So maybe the focus should be on how to best integrate HTML with games for the purposes of GUI. I have to mention though one of the risks of the "show custom HTML" approaches is that you have to be very careful with handling user input otherwise you create an XSS vulnerability that allows attackers to hijack user's logins, private data etc. from your site/game. This is the main reason we focused on the iframe object for displaying custom HTML, since if you sandbox it it's safe to show untrusted user content in. As ever that shows there are many other aspects to think about and the obvious thing to do isn't always necessarily the best idea.

    There's also the feature suggestion platform where you can post ideas and see if they collect votes, which would indicate broad support amongst users and make it more likely we'd consider it. As far as I can see from a quick look there isn't anything highly voted there that already covers this. However I would emphasise that you need to consider all of the above when posting a suggestion - if you just post "make a GUI feature" that is far too vague and vast in scope to consider.

  • Why would you want to do that? The frame control options are better for that and more secure.

  • I think you might want to take a look at the section "controlling framing" in the tutorial Publishing to the web.

    • Post link icon

    makarone - that startup error is unrelated and is caused by a broken third-party addon.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • No. The fact they were editable caused nightmare compatibility problems. So they are intentionally not exposed or available. The documented Addon SDK covers the features available to addon developers with a stable API that we (generally) promise not to break.

  • I think both Android and iOS are slowly moving towards blocking insecure HTTP completely with no configuration options to side-step it. The current situation is probably a stepping stone to that point. So I'd recommend just using HTTPS as a future-proof solution - using the configuration may break again in a future version of Android since they're motivated to remove it.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,771,283 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs