Ashley's Forum Posts

  • I think one of the big lessons of the Unity runtime install fee debacle is that game developers need to think about the sustainability of their tools. If the development of the tool is not sustainable then it can suddenly run in to serious difficulty and have to radically change things, possibly to everyone else's detriment. It seems to me Unity went with a very generous offer for many years, ended up losing huge amounts of money, and then suddenly tried to impose install fees on everyone to try to get back to profitability. Obviously that didn't work out, a huge backlash forced them to reverse course, they've now made thousands of staff redundant, and a question mark still hangs over their long-term future. The tool cannot continue to exist in its current form if they can't find a way to make its development sustainable.

    I know not everyone likes the subscription model, but it does guarantee that we can keep going indefinitely. It's clearly a sustainable model.

  • It looks like the Android WebView v121+ also supports WebGPU. However Construct still sets WebGPU disabled for Android exports, but that will be changed to enabled for the next release cycle.

  • Try using 'Set stepping iterations' and increasing the iteration counts. That will help improve the precision of the physics simulation, although at the cost of higher CPU usage.

  • That doesn't look like valid JavaScript code.

    If you are new to JavaScript coding I'd recommend going through the Learn JavaScript in Construct tutorial series, which will help you get the basics right.

  • I think this is actually a bug in timeline playback. The timeline has keyframes every 1 second. If you add another action like "Every 1 second, rotate sprite", then it rotates on the keyframes at normal speed, but at a timescale of 0.5 it rotates twice for every keyframe. So the timeline really is playing at one-quarter speed at a timescale of 0.5 which is incorrect. DiegoM

  • Update: WebGPU is now supported in Chrome for Android from v121+, which is currently rolling out as a stable release.

    WebGPU is not yet enabled in Construct for Android exports, but we'll be enabling it for the next release cycle.

  • They probably also just throw some hurdles in the way to make it harder and so are still hackable, unless they have a full server-side approach. Having a server-side gameplay system is extremely complicated and would often require rearchitecting the entire game, as it works more like a multiplayer game (with the server being a host and the player just acting as a peer in a remotely-hosted game). That could well be more effort than making the game in the first place, so it can be difficult to justify.

    I'd say: who cares? If some people hack the game, let them. If you have a global hi-score board, yep, it'll get hacked. Often games just show scores for you and your friends, or other people with similar scores, rather than just the top scores, so obviously fake top scores never appear anyway. You can also moderate your scoreboard so obviously fake scores (e.g. 9999999999) get deleted.

  • Focusing on the skills you're learning might help persuade people it's worthwhile. First of all, the games industry is even bigger than the film industry now, so there really are good career opportunities in video games. But even if you don't go in to games, a tool like Construct helps teach you real computing skills. The event system includes concepts like variables, conditions, functions, loops, data structures like arrays, and so on, all of which are real computer science concepts. If you then start trying out coding with JavaScript and/or TypeScript, you are then directly learning a real-world professional programming language that you could literally get a job working with, even if not in the gaming world. So think of it like an educational tool!

  • There is no fundamental solution. A client-side game can always be hacked. All you can do is throw a few hurdles in the way to make it harder.

  • But I think, it would be better to prioritize code neatness as the first move, then performance

    Absolutely 100% that. Ignore performance until you have a measurable problem, and then use measurements to improve it. See the recently-updated Performance Tips guide for more.

  • .doc/.docx are extremely complicated formats designed for word processors and not data storage. It will be much, much easier to read data from a standard data format like JSON, XML or CSV. I'd personally recommend JSON as it's most widely used on the web for this kind of thing, but if you want a really simple format, then you could use CSV.

  • See the manual section on scripts in event sheets. You should use a script with the purpose "imports for events". (Alternatively you need to explicitly refer to the global scope with globalThis, but imports is a better-organised approach.)

  • I think it's theoretically possible to make a plugin for Construct that can run Python code, as it could use a WebAssembly build of the Python interpreter. However I don't believe anyone has attempted that yet, and it would be much more difficult to actually integrate that with the runtime, such as to use Python code to change a Construct object. Integrating all those API bindings would probably be the most challenging part, and without that it would be hard to do much useful with Python code. So I think the best approach is just to try to get to grips with JavaScript.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Internally it doesn't use setTimeout or coroutines, as the event system is complex and it has to do a lot more than meets the eye to implement the wait logic. So really it's a custom implementation I guess.