Ashley's Forum Posts

  • change all my asset and variable names to the plugins name, game id etc

    Most of that information - such as all object and variable names - is stripped out from exported projects. So going through your projects renaming things is a waste of time, because all that information is removed.

    Also if you enable "minify script", the resulting obfuscation is pretty strong protection against anybody reverse-engineering the logic of your project.

    Anyways, this is pretty confusing and I can't seem to pin down what people want. There's discussion of obfuscating the project data - which is already done pretty strongly on export! - or even asking for less obfuscation (you can turn off "minify script" if you want but that doesn't make your project easy to mod).

    What exactly are people after here? I'm not going to start writing a feature until I have a clear answer that makes sense about what people want and why.

  • Okay, but that's very different to the Cordova project saying that

    As I said before, slower and working is better than fast and broken.

    Also, I strongly suspect the performance is simply GPU blacklisting, in which case the performance difference is likely far smaller.

  • So I was thinking about this some more, and I guess something we could do with hopefully minimal performance impact is something simple like XOR encrypt the project name over the content of all asset files. If it's reversed at the point of loading hopefully there won't be too much delay (although this remains to be seen), and it stops you "just opening" any asset files.

    The thing is this is basically homeopathy for security. It is not remotely secure in any meaningful way. XOR encryption is the type of thing treated as a joke by professionals (but it's quick and simple, which is the main reason I consider it). But - if you find the file you can't immediately open it until you figure out how to at least run the reverse XOR process. So this will function well enough to stop people idly browsing around your assets. But it won't pose much of a barrier to anyone with common technical skills. We could choose some really tough encryption, but then crackers will fall back to other tactics like scraping from RAM while your game startup time needlessly suffers.

    My main objection is what does this really solve? I feel like people want to tick a box on a checklist that says "encryption" and get a warm fuzzy feeling that their work is at last safe, but that is not at all the case, even with some supposedly strong encryption. If someone wants to rip your music and sell it online, they can find a way. By far the more effective way to counter this is copyright law.

    We're also a small team and I'm keen to spend time where it matters. Lots of people want exciting new features like modularity in events. I want to do that a lot more than I want to sit around fine-tuning the performance of a placebo algorithm.

    So, is this really what people want? Do you really think this will make a material difference to anything?

  • Where did the Cordova project say that? I didn't think they'd recommend a competing company's proprietary technology...

    If there is really that big a difference (20fps vs. 60fps) are you sure you're not on a GPU-blacklisted system or getting dropped back to canvas2d rendering? That's exactly the performance difference you'd see if that was happening. In which case really you're testing hardware-accelerated vs. software rendering, which is an unfair comparison.

  • There's no limit, but you'll quickly run in to bandwidth constraints. The multiplayer tutorial talks about that a bit.

  • There's so many different icon sizes it's kind of ridiculous to try and get C2 to cover them all. To add a new icon size should simply be a matter of adding a PNG file with a new size to the zip, and editing config.xml to use it.

  • How exactly do you imagine this feature working?

    I wouldn't want to implement all the rendering of the dialog boxes automatically, since that is getting too close to "cookie-cutter" engine features. It should also be reasonable to do with your own events, but that doesn't mean we can't add features to make that easier. The question is exactly what features you want and a detailed description of how they work.

  • 2) this would add ambiguous results to the just-announced find all references feature ... so most likely it will have to add that "create by name" result in to every "find references" result list - or never add it. Either way, it makes the feature less useful.

    But why? Obviously, if i'm interested in "Unit" object, i have to see event\action that spawns it.

    The editor doesn't know what the values will be at runtime. Another example is letting the user type in a name, and creating something based off that. The editor can't possibly anticipate what the results will be, so it has to either always show the unknown cases, or never show them.

  • This has been regularly suggested for C2 for a while now, but my main concerns are:

    1) lots of users are worried about their projects getting reverse-engineered, and to make this harder currently we strip out all object names from the project. To support this, we'd need to add them back in.

    2) this would add ambiguous results to the just-announced find all references feature. If you create an object from a string in a CSV file, for example, C3 can't know for sure if that will or won't reference a particular object. So most likely it will have to add that "create by name" result in to every "find references" result list - or never add it. Either way, it makes the feature less useful.

    It's also relatively straightforward to work around in events (e.g. using a function call) without affecting either of those points.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You do not have permission to view this post

  • Most common causes are listed in Performance tips.

    However if you can spot a big difference like that after making a change, you know it must be the change that caused it. Narrowing down what that is can be tricky, which is why it's important to check regularly.

  • This is why I always liked the idea of publishing to the web: it costs nothing, you get all the revenue, and there is no gatekeeper who can deny you access if they don't like what you're doing for some reason.

    Of course the downside is less visibility (Steam provides lots of gamer eyeballs) and payments are more difficult (they handle transactions for you). I often think about what could be done to try and make the web a better publishing platform for Steam-like games. I think there's a few companies out there thinking about it too, like Mozilla who are doing a lot to promote 3D WebAssembly/WebGL games.

  • You do not have permission to view this post

  • Please file a bug report following all the guidelines if you want us to investigate this. It's impossible to comment with such little information.

  • Any build system producing a webview app will likely perform identically. The build systems are just different ways of producing the same result. Since it's the browser engine powering the webview that determines runtime performance, and there is nothing different about that, it's likely the same. The only exceptions are if you change the webview (e.g. UIWebView/WKWebView, but all build systems now support WKWebView).

    Canvas+ on the other hand is not a real browser engine, and not officially supported. We dropped support for it a long time ago because it had loads of problems. It is missing tons of features and had basic problems like being unable to manage memory so even medium-sized games crashed. For a small number of people their games could navigate these problems and more or less by luck they kept working, and they wonder why we don't support it, but it's totally a no-brainer from our point of view - it's not worth supporting at all.

    Also, even if it's faster, in my opinion that doesn't matter. With Construct Classic we learned an important lesson: slower and working is better than faster and broken. We did loads of crazy optimisations for another 5% speedup and it got so complex and difficult with all these internal performance hacks that it just totally broke some games. Someone whose game runs 10% faster is a bit happier, but someone whose game does not work at all is extremely unhappy. So making something that works robustly is more important, even if it's not as fast as possible. So basically in my opinion it doesn't matter if Canvas+ is faster: it's so badly broken it doesn't matter.