Ashley's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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

  • It's not currently supported but we're planning on implementing this suggestion which should cover it.

  • I would expect Google, Microsoft and Mozilla will be working on getting their browser engines ported to iOS ASAP for this - but I think they can only publish their browser apps in the EU, so for now at least it has limited reach. However the ability to use real Chrome on iOS, rather than just a Safari-wrapper, means there is at least the option to use a better browser engine on iOS. It should provide options for more features and provide a way to avoid bugs and limitations in Safari (including possibly using a higher refresh rate).

    iOS apps will continue to use WKWebView which is based on Safari, but that's normal - on other platforms we use the system webview for apps. It's only web browsing that this will help.

  • There is only one signalling server, and both URLs (multiplayer.scirra.com and multiplayer.construct.net) point to the same server.

    I'd recommend updating any existing projects to refer to multiplayer.construct.net. While we intend to keep the multiplayer.scirra.com URL alive for backwards compatibility purposes, we cannot guarantee it will continue to be running in the long term, as our long term goal is to move over everything to run on the construct.net domain.

  • Getting an item from Local Storage is asynchronous, which means it takes a moment to complete. You need to use Wait for previous actions complete after it to make sure the data has finished loading in to the Binary Data object before you attempt to play audio from the Binary Data object.

  • OK thanks - I see the problem now.

    Ultimately this comes down to the fact runtime.objects.Monster has a static type of IObjectType<InstanceType.Monster>, which refers to the base class rather than the instance subclass. That base class is ultimately propagated to all its event handlers.

    It's difficult to static type this correctly as from the perspective of TypeScript, setInstanceClass is a runtime method and so can't be used to affect static typing.

    I think this is just one of those cases you have to override TypeScript's types as you know more than TypeScript does. There's a couple of ways around it. Probably the most straightforward is you can just use as to cast it to the right type, e.g.: 

    runtime.objects.Monster.addEventListener("instancecreate", e => DoMonsterSpawnedFunction4(e.instance as MonsterInstance));

// ...

const DoMonsterSpawnedFunction4 = (inst: MonsterInstance) => {
 inst.OnCreated();
};

    I'd recommend the above approach, but another possible approach is to make your own reference to the object type with the correct type IObjectType<MonsterInstance> - and then using addEventListener will propagate the type MonsterInstance down to the event handler, e.g.: 

    const MonsterInstanceType = runtime.objects.Monster as IObjectType<MonsterInstance>;
MonsterInstanceType.addEventListener("instancecreate", DoMonsterSpawnedFunction2);

    So yeah, basically just override the type for this case.

  • It's possible but comes with a lot of complications. Off the top of my head:

    • Most texture compression formats are lossy, so they will affect how the artwork appears. Often this doesn't matter in 3D games, as perspective and texture styles make it less noticable.
    • It looks like not all texture compression formats support alpha, or if they do it has to be via a separate texture, which is either a major limitation for 2D games (again not as relevant for 3D games) or a major complication for the engine
    • The file size compression isn't very good, so you'd still want to export PNG/JPEG/WebP for smallest download size. That means compressing textures on-the-fly at runtime, which could substantially increase loading times (possibly with a slow/high quality to fast/low quality tradeoff)
    • I think some texture compression formats are patented and shipping encoders could incur fees, much like some patent-encumbered video formats, which more or less rules out using them at all as it makes them uneconomical, unless there's some other encoding system used beforehand and you ship your game with pre-encoded textures, which would then have a much larger download size
    • Not all platforms support the same compressed texture formats, so you might have to support encoding to multiple formats (making some of the previous points even worse)

    I wouldn't be surprised if there were further complications I haven't realised yet. Compressed textures look like a feature best suited to large-scale 3D games with gigabyte-size downloads or dedicated installers. It seems to me like they are much less suitable for 2D indie games.

    Meanwhile I've heard GPUs can use lossless texture compression automatically - but if they do that it's undetectable to the app and doesn't need anything special to be done. So sometimes that might help anyway. But Construct doesn't know about that - its texture memory usage is based basically on just the number of pixels in the image.