Ashley's Forum Posts

  • Interesting thoughts all, but I have to say, for us the more we add to the free edition, the fewer sales we get. Open-source projects use a different model where most of the product is free, the titans of the industry like Unreal can rely on revenue from royalties of major commercial titles, and some other tools are backed by billion-dollar corporations who don't necessarily care about running things at a loss. I think we're actually relatively unique in being an independently run, small/medium-scale commercial business with subscriptions, and making a success of it. However we also have to make sure that's sustainable, and in its current form, it is. Unity are losing about a billion dollars a year at the moment so clearly they're thinking "this is unsustainable, we need more revenue fast", and look where that's ended up, and I think that's a good reminder of the importance of having a sustainable business.

  • Thanks for the feedback! Sounds like it's working out OK so far.

    Ashley - do you expect to create a template for a companion app, or should we roll our own (I am not in a rush.)

    I thought about making a separate SDK, but I think it only needs a small modification from the stock wrapper extension in the addon SDK. There's some instructions here on how to do it, which basically amounts to creating a new wrapper extension and adding the Steam-specific include stuff from framework.h. It's true I haven't fully tried this yet, but I think that's all it will take - if it seems harder let me know and I'll see what it takes to get it working (and make a separate companion SDK if necessary).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Most of the time changes will only be in the www folder. However some project changes may affect the Xcode project too, such as changing project settings, changing export settings, or adding/changing/removing third-party addons that use Cordova plugins. So for basic changes updating the www folder is probably fine; if you're not sure, a diff tool can easily show the difference between two folders of files to compare two exports, e.g. WinMerge on Windows which I use myself sometimes (although I'm not sure what macOS equivalents there are).

    Remote Preview is designed to let you quickly test on mobile without needing to export every time. Is there a reason you're not previewing with that for faster iterations?

    On a side note, upon searching, it seems like most documentation on Construct -> iOS is about 5+ years old.

    AFIAK the process for exporting to iOS hasn't changed substantially over the past few years, so the existing documentation should still apply. If anything is out of date then let us know.

  • Please file an issue, since we're always very busy and will otherwise probably forget about this forum post.

  • I kind of agree with your point, but I don't necessarily agree it's down to our poor marketing - it's mainly that there's a contradiction in the messaging. Our main feature has always been that you don't need to know programming and can use event blocks as an alternative to coding, but by saying how easy it is, some people assume it's not an advanced tool, even though it is. If we say how advanced a tool it is, some people will assume it's not an easy-to-use tool, which would affect our core appeal. So we tend to focus on highlighting the easy-to-use aspect.

    We do try to get this all across though - take a look at our features page: it highlights "No programming required", but does also allude to its power:

    Construct lets you have it both ways: beginner friendly blocks, all the way up to a full coding editor.

    Under the hood is an incredibly powerful and versatile engine with outstanding performance. It’s perfectly capable of running vast and intensive games smoothly and efficiently.

    Packed with tools ... There are genuinely too many features in Construct to reasonably list here. Here’s just a few more things Construct has and there's a lot more to discover on your journey.

    We also emphasize that JavaScript is an industry-standard language that you can get a job in - IMO a huge advantage over using tool-specific languages like GML or GDScript:

    Other engines use proprietary programming languages that lock you into their ecosystems. Construct uses Javascript which is one of the most popular programming languages in the world.

    Learn real-world transferable skills and level yourself up with Javascript.

    I think possibly another thing working against us is people don't take browser-based software that seriously, even though it can far outperform competitors. One of our goals is to change that perspective!

    I guess we could do more to emphasize the advanced capabilities of Construct, especially now there's things like the C++ extension SDK for advanced desktop integration. But I fear that the more we do that, the more we might scare off beginners. I'm sure there's a balance to be found, but it's tricky to get it just right.

  • Yep, a QR code can contain any URL including hashes.

  • I'd recommend using the Hash expression of the Browser object. For example you could set it up so if someone visits example.com/index.html#settings, it goes directly to the Settings screen rather than the usual title screen.

  • The new C++ extension system is specifically designed for integrating other C/C++ SDKs like this. However I doubt we'll do it ourselves - we just don't have the resources to integrate every possible third-party service out there, which is exactly why we're (about to) publish the SDK so third-party developers can do it themselves without having to wait for us.

  • Chrome, Opera and Edge all use the same browser engine (Chromium). Again, this is categorically a problem with ANGLE, the Chromium browser engine or graphics drivers, and the only way progress will be made is if it is reported to Google.

  • In short, the code sent to the minify service does not include any personal information, does not include much information about your project, and is not permanently stored. I believe it to be fully compliant with our existing privacy policy.

    Here's a few more details about precisely what it does and how it works. If you export a project with minify disabled, you'll find a lot of engine code in the files c3runtime.js and main.js. When you minify your project these files are sent to the minify service, which runs Closure Compiler on them, and then sends them back again.

    These files contain the stock Construct engine code used for all Construct projects. Why don't we just ship minified engine code with Construct itself? The problem with that is for efficiency, Construct only exports code from the plugins, behaviors and effects your project actually uses. That can also include code from third-party addons too. So the engine code does end up changing, but only because it's a combination of different pre-defined components to suit your project. Further, the engine code does also include any JavaScript code you write in your project, either in event sheets or script files. So the code sent to the minify server does include your project's JavaScript, and strictly speaking implicitly contains the list of addons used by your project. However this is not enough information to reverse-engineer your project. For this reason I used the phrase "does not include much information about your project" rather than "does not include any information about your project".

    To be clear, the actual information describing your main Construct project is not sent to the minify server. The main project-specific data is stored in data.json, and in all the other assets as image files, sound files etc; none of that is sent to the minify server.

    The code that is sent to the minify server is encrypted in transit in both directions. It is decrypted for the purposes of performing minification, and then as soon as the minified result has been transmitted back to the client, all files are promptly deleted. So decrypted engine code will remain on the server for perhaps a couple of minutes before deletion. There are also various failsafes to make sure that in the event of an error, or even a server crash, the working files will be deleted. In the event the minify server was compromised and the information leaked, it would potentially expose any JavaScript code written in your project. If that is for any reason a problem for you, there is the option of manually minifying your code locally: export from Construct with no minification, and then use a third-party tool to minify the code in c3runtime.js and main.js.

    Hopefully that helps clear up any concerns about what it does and how it works.

  • Storing the encryption key on the client is fundamentally insecure - it will always be possible for someone to find it, no matter how it's obfuscated. If an attacker can't find the key in plaintext in the game files, then the next step would be to intercept it at the point it is used with developer tools, which means it will have already been de-obfuscated and appear in plaintext again in the developer tool.

    Therefore if you are happy with a fundamentally insecure system which is only designed to make casual tampering a bit harder, I'd say you may as well just use a simple obfuscation scheme - some kind of string manipulation would do. The only significant thing you can do is avoid the key appearing in plaintext in the game files, and beyond that the particular kind of obfuscation you use doesn't really matter, as it won't affect how hard it is to bypass.

  • It all seems to be working fine for me and I haven't seen anyone else having issues. Try disabling any browser extensions you have installed in case one of them is interfering with Construct. It might be worth updating Chrome as well in case a recent Chrome bug that was affecting Construct was causing problems for you as well.

  • You should definitely go through the full Learn JavaScript in Construct tutorial series. Your code makes mistakes that are explained by that guide.

  • Have you filed an issue with Google? That is the only way this will get solved. It is categorically a problem with ANGLE or the graphics driver. There's nothing much we can do about the underlying issue, and so if you keep posting here expecting me to do something, it won't get fixed.

  • File an issue anyway - it's the best way for me to review the situation. If it comes down to a browser issue usually I end up filing an issue with the browser maker.