Ashley's Recent Forum Activity

  • Our feature request guidelines have a section titled "Please do not try to claim your idea is simple or easy to do". Even much simpler features can end up proving surprisingly difficult. There are parts of Construct that look lovely and simple and straightforward, but internally it is dealing with a great deal of complexity. That's really Construct's job - it often does a lot of heavy lifting internally to provide a simple and straightforward interface. Even we struggle to work out what will be easy and what will be hard, and on the outside it is even harder to properly understand what a feature would entail. Claiming something is easy to do is not helpful and will probably just make people get more frustrated.

    We don't know for sure how easy something will be until we do it, customers use the finished version, and decide it is suitable. Before that point we have to rely on our many years experience developing a complex piece of software, using our familiarity with the codebase, to make an educated guess what it would be like to develop. On this I must agree with DiegoM - template layers sounds like a nightmare to implement. The "sort-of-like-a-normal-layer-but-not-quite" approach actually causes no end of difficulty and complications, as it violates long-standing assumptions in thousands of lines of code distributed across the codebase, which is more or less the same reason why global layers proved to be a nightmare. It probably gets even worse if you want things like a template layer to be an override of a global layer - that sounds like the kind of thing that ends up so messy and complicated it ends in development hell and we basically never get it right, then users end up abandoning the feature because it never works properly. So I think there's a real risk your dream of a nice simple template layers feature actually turns in to a nightmare.

    Batch changes to a project sounds a lot easier though. It basically amounts to repeating a manual operation across multiple layouts. It would be much more straightforward to implement and is much more likely to just work in a predictable way. So this is one of the times where our experience developing Construct is leading us to suggest a different feature that should still do the job, but is much easier for us to develop and support, and more likely to actually turn out to be a success.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • This doesn't make sense - it's like asking for a Construct project without the Construct engine. Construct always uses its engine, it's a key part of the product.

  • I'm afraid if you cannot share your project, it is extremely difficult to offer any useful help. Your next best bet would be to try to reproduce the issue in a new empty project and file an issue with that. It would also be useful if you could identify the specific release number that the problem first started in, including beta releases, and also share the full text of the error message, but those are just potentially helpful details - we usually need more than that to be able to help.

  • I think this is an interesting discussion and there are lots of good points being made all round - however I would remind folk to review the Forum & Community guidelines and make sure the discussion is respectful at all times, even when you strongly disagree.

    In my view Construct is primarily a tool for human creativity and expression. I am not personally particularly interested in AI-generated games or content. Other tools can do that and people can use them if they want, but I don't think it's something we should do with Construct. Using an AI assistant to help solve problems, sort of like an in-app support advisor, is probably a more reasonable idea to discuss.

    I think that the intense hype around AI makes this harder to evaluate. I suspect many companies are cramming their products full of AI not because it's been proven to work well and be useful, but because they have investors or shareholders to impress, and they benefit from the AI hype. We are an independently owned company and we have no need for such things. On the other hand, AI is proving to be genuinely useful in some areas and it probably is here to stay and will significantly disrupt some things. I still don't think it's clear though what things are going to change and to what extent. Were it to become the case that customers expected all software to have AI assistants and tools that didn't became irrelevant and ultimately failed, then I think we would be forced to add some kind of AI assistant to stay in business. I don't personally see that point having arrived though, and we can act on it if or when it becomes the case. I think there is still significant risk around whether the big AI companies will prove to be economically viable (there may be a big crash on the horizon); risk the pricing for AI services ends up increasing massively; risk that lots of existing AI integrations end up being removed due to being expensive/ineffective/unwanted, etc. So I'm personally still in a bit of a "wait and see" mode.

    Even if we did want to do some kind of AI assistant, there are some difficult problems to deal with. Probably the biggest is where does the training data come from? Using customer projects is totally off the cards - there is no way we would ever do that. 500 or so example projects built in to Construct is a start, but while I'm not an AI expert by any means, I get the impression that is probably far too little to train an AI on. However much data we need to answer beginner questions, I suspect we'd also need 10-100x as much to answer intermediate questions, and 10-100x as much to answer expert questions. If it's even capable of answering expert questions - my experience of using AI for coding purposes as someone with ~20 years experience is they constantly come up short, so in the end I don't use them much. One recent example is I asked a question about WebGL 2 and ChatGPT fabricated a quote from the specification which did not really exist. It similarly makes things up too frequently for me to consider it a reliable resource. I've tried all the other ones and they all have similar problems. What if we add an AI assistant and it ends up giving bad advice frequently enough that it's not worth using? Perhaps even after all that work, for all its flaws ChatGPT still gets you a better answer.

    Specifically on the point of documenting the file format, that is actually probably a difficult thing to do. At the moment we treat it as an internal detail and that gives us flexibility to change anything at any time. If it was documented and things depend on the specific details, then it makes it harder to change. Besides the way I thought AI works (again, not an expert) was it learned mostly from vast amounts of examples, and it doesn't necessarily need a specification. Nobody feeds AI models a specification of how English works, and yet they can use it fluently. AI models probably don't need access to the C++ specification to generate C++ code so long as they have enough training data. So it may be something that puts quite a big burden on us and yet does little to help AI tools.

    What would really help AI tools? We already have hundreds of thousands of forum posts, 1000+ pages worth of documentation in the manual, and 1000+ user-submitted tutorials, which I think is a decent body of knowledge. If you really want to help AI understand Construct, I think probably the best thing is to contribute material about how Construct works in places AI will find it: post to the forum rather than using chat rooms, share your knowledge in tutorials, and upload interesting Construct examples to the web (GitHub is probably a good place for that). And best of all, that will all be useful for humans as well!

    Other than that I think we could write a tutorial outlining an overview of how the Construct project file format works in broad terms, which might help LLMs understand projects, despite not being a full specification. We could also put a file like llm-context.md in every Construct project with a similar overview to help AI tools understand the Construct projects they do come across, rather than possibly seeing them as just a random collection of files. Perhaps that's not too controversial a thing to do?

  • I Google Translated your post to English - please see the Forum & Community guidelines, we currently require English on this forum. See also tips for using this forum.

  • If you want to run the Multiplayer chat room example outside of the editor, export it to the web and host the files somewhere.

  • I'd love to do every single feature request that is asked of us, but we have to deal with the real-world constraints of available time and resources. I also prefer not to make specific promises about features and schedules - there is just too much uncertainty, and I prefer not to promise things we may not deliver on (under-promising and over-delivering is better than over-promising and under-delivering). Having said that, I do appreciate the need for this and I'd like to see if something can be prototyped soon.

    If project-wide changes based solely on the layer name with no ability to select specific layouts was acceptable, that would be a quicker and easier update and therefore more likely and possible to come sooner. If you don't think it would be useful unless there was some UI to choose which layouts to update, then as anything involving UI - even a small amount of UI - is a great deal of work, that would make it a bigger update and less likely to come sooner. Uncertainty about which we really need also makes it harder to justify scheduling sooner rather than later, as it is a real pain if we think we can do a small simple thing, but then after it comes out, everyone decides it's not actually sufficient and we have to do the bigger thing.

    This is a small window in to the decision making for every feature request. The art of the realistic feature request is to work out the bare minimum you can live with, ask for that, and then once that is implemented, move on to your next bare minimum improvement, and so on. That also mitigates the risk that we end up doing a great deal of work that turns out to have been the wrong approach once it makes a beta release.

  • It's a problem with Steam as it cannot properly see the content of content displayed in browser engines. We worked around it for screenshots, but it doesn't look possible to work around for video. You should be able to still use the Video Recorder plugin to record a video, and perhaps there is some way to use the resulting video with Steam. It would be best to contact Valve for further support on that as the way the game recording works is up to them.

  • No offense taken, just making the case for Construct 3!

  • This has been discussed to death already, but in short we're not planning to change Construct's pricing model at this time. I do however want to point out that Construct's pricing is not too expensive, in the ballpark of a Netflix subscription in most places, and so should be acceptable to hobbyists. Thousands of people are willing to pay the subscription to get Construct because it's worth it to get a quality tool stuffed with countless features and has performance, usability and reliability that beats many other options.

    Developing software is expensive, and ensuring the tool is economically sustainable is important for people who work on long-term projects. There are some tools out there that I'm interested to see if they can actually sustain themselves over the next few years as they may well be running at a loss, and I wonder what will happen to customer's work if a tool developer goes under. Sustainability is also important to avoid the need for drastic business changes like Unity's runtime fee debacle. In an alternate universe it's possible we stuck to Construct 2's model, sales petered out, and then we were forced to close the business and go do something else, even though there were lots of people still using Construct - and that would suck for them and their work. I can assure you we're a long way from that scenario, and the subscription model is a good way to avoid that ever happening.

    I'd also add that there are significant issues with Construct 2 - by now I think none of the mobile exporters work out of the box, the desktop exports are well out of date, it doesn't properly support high-DPI displays, it has likely thousands of bugs that were fixed during Construct 3's development, if you run in to any problem there will be no support provided, as the technology ages more and more things will probably stop working, and meanwhile Construct 3 has absolutely tons of new features and improvements allowing for much greater flexibility and creative expression (many of which are listed here, but even that is quite out of date now) - not least the latest support for 3D models. Perhaps some people don't care about any of that. However I would say much of that is important to a lot of people, and there are years and years of hard work that go in to developing a product that is actively supported and continuing to advance in features.

  • As we're probably going to be supporting this workaround for a while, there are a couple more changes in r473 to try to make gamepad support work better in Windows WebView2 exports. There's a new 'Export for Steam' setting for the Windows WebView2 exporter. This does the following:

    • Unchecked (default): sets "allow-host-input-processing": false in package.json. Gamepad input should work normally (using browser-provided gamepad input).
    • Checked: sets "allow-host-input-processing": true for compatibility with the Steam Overlay, and then includes the GameInput wrapper extension to work around the WebView2 bug that stops the browser-provided gamepad input working in this mode.

    The GameInput wrapper extension is also updated in r473 to support multiple gamepads as Microsoft were able to fix the GameInput bug that was preventing us supporting that. Note however as per the previous post, haptics (rumble) are still not supported with GameInput, and you must still install the GameInput redistributable installer to ensure support is available (be sure to use at least v3.2.138 as that has the fix allowing for multiple gamepads).

  • It looks like it should work. It is always difficult to provide much help unless you share your project file though. Maybe take a look at the Screen recording example and see how that does things.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,761,853 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
  • x125
    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