WackyToaster's Forum Posts

  • Sometimes it's great to look at what other tools are cooking and I've recently got curious how the live2D stuff works and done some digging. I found some functionalities that I think could be really interesting for Construct so I made a wishlist.

    1. Mesh setup

    Meshes can be set initially without deforming the sprite. That allows the base-mesh to conform to the actual content of the sprite instead of always covering the entire sprite rectangle. From what I gathered this might give better results when deforming the sprite, in particular if the initial sprite has some curve to it. If the mesh follows that curve initially, deforming it should lead to cleaner deformation.

    They also have an automatic function to create this mesh. docs.live2d.com/en/cubism-editor-manual/mesh-edit which of course would be nice to have. But even being able to deform the initial mesh manually to fit the sprites texture would be a great starting point.

    2. Clipping mask

    It's super easy to create a clipping mask for any kind of masking purposes. Take the sprite you wanna clip, reference the sprite that should be used as clipping mask. Done.

    docs.live2d.com/en/cubism-editor-manual/clipping-mask

    docs.live2d.com/en/cubism-editor-manual/invert-mask

    In Construct we have to use blend modes (destination out etc.) which becomes increasingly complicated if you wanna have multiple objects that are cropped because the destination out applies to everything below. So when cropped objects overlap the clipping mask from the top sprite also crops the bottom sprite. Effectively you need to put every single pair of object and clipping mask on their own layer with force own texture.

    Mind you this is quite a highly requested feature already: github.com/Scirra/Construct-feature-requests/issues/726 although the solution skymen proposes is slightly different.

    3. Deform Path

    One can define deform paths which can be used to manipulate the underlying mesh. Instead of having to manipulate all the individual points of the mesh, this path works kinda like a classic bone/joint. It simplifies adjusting meshes a lot.

    docs.live2d.com/en/cubism-editor-manual/deformpath

    A similar application would be puppet warp which is available in various tools: tips.clip-studio.com/en-us/articles/10496

    These are already really useful during editing since right now you must drag mesh points 1 by 1, but I'd imagine these paths could be manipulated at runtime too, allowing much more convenient manipulation of meshes at runtime (which is currently easily the most cumbersome part).

    3.1 Soft selection

    On a sidenote for editing meshes, a soft selection option would be great. github.com/Scirra/Construct-feature-requests/issues/789

    4. Blendshapes

    docs.live2d.com/en/cubism-editor-manual/blend-shape

    The ability to blend between two (or more!) meshes. This is often used in 3D for facial expressions. You take a copy of your base-mesh, deform it to e.g. make the character smile and add that as a blendshape. Now you get a slider on your sprite which allows you to set how strong the deformation is applied and you can make your character smile between 0 and 100% (sometimes it even possible to extrapolate in either direction). Now you make another blendshape with mouth open, which allows you to mix the smile and the open mouth. Of course this can be used for all kinds of animation purposes, not just facial expressions.

    github.com/Scirra/Construct-feature-requests/issues/787

    While typing this timelines popped into my mind, which could maybe be used to set this up... except they don't appear to support/track mesh deformations. So there goes that. (Unless I'm mistaken)

    5. Deform Path physics

    This is kind of an optional thing but would be cool regardless. One can set up a physics calculation, which is then applied to a deform path. I'm assuming they are using some kind of verlet physics here.

    docs.live2d.com/en/cubism-editor-manual/physical-operation-setting

    This could be cool to make a character with a dynamically animated tail, cape or hair. Or really anything you can think of. I actually made a cape with this method before, where I used verlet physics to simulate a rope attached to the character and then used the IRenderer to render a mesh. But I couldn't get further than rendering a solid colored cape. I'm assuming it's possible to actually attach a texture if you actually know what you're doing (unlike me).

    If I had to prioritize:

    1. Clipping Mask ("simple" feature, big payoff)

    2. Mesh setup (I'm assuming the Deform path will not work as well without this so this has to come first)

    3. Mesh soft selection

    4. Deform path (Easier mesh manipulation both in the editor and runtime)

    5. Blendshapes (An alternate way of deforming meshes at runtime, probably a bit more niche than deform paths)

    6. Deform path physics

  • It sounds like what you are looking for is to disable the default controls (which are the arrow keys) for the enemies. So the player can be controlled with the arrow keys and the enemies aren't.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can do something like this.

    But yeah, 9-patch animations would be great in general.

  • If you make your own save system, it's also likely to run in to all sorts of bugs and issues that Construct's save system has already sorted. For example saving and loading the relationships between objects is particularly tricky. Take two instances A and B, with B being a child of A. If you load A and B doesn't exist yet, you can't set up the hierarchy; if you load B and A doesn't exist yet, you can't set up the hierarchy. You have to have a phased approach where you load A excluding hierarchy, load B excluding hierarchy, then afterwards when both exist, restore the hierarchy relationships.

    I agree that this is indeed a very tricky issue. But I feel like this is a rather rare, specific situation where you'd actually be required to save this in detail? Maybe I'm wrong? Extending this question to the others in the thread: Does your game need this, and why?

    Construct's savegame feature is actually specifically designed to handle this gracefully. Everything internally relies on fixed IDs (called SIDs - serialization IDs) that are robust even in the face of renaming or moving things.

    Interesting.

    If C3 would have some paid testers, they could be the ones to strip down the project on our behalf, the clients, in order to find bugs in C3.

    If you think stripping down a gigantic 7000 event project takes long... imagine doing that except you are entirely unfamiliar with the coding style and codebase. :D

  • Some recent stats I got from webGPU: ~5% of devices appear to be failing with "Error creating WebGPU renderer" (something along those lines). I'm not sure if this is a breaking error or if Construct falls back to WebGL if it happens. Data is from a couple thousand random players.

  • I've said that once before but I think this system would work better if it would be the other way around: save NOTHING by default until you start adding a "do save" behavior. Or maybe both, so you could pick which way is better suited for your project.

    Here's some reasons why I'd not want to use it:

    1. Updating the game and loading a savestate from an old version sounds extremely iffy, especially if the loaded objects have changed for whatever reason

    2. Savestates potentially save (and load) broken game states (e.g. a softlock)

    3. Savestates are extremely unwieldy and the only control I have over it is the no-save behavior.

    What I mean by unwieldy: This is what a savestate in my current game would look like:

    Mind you I ran it through a beautifier... 27000 lines of JSON? I wanted to paste all of it here for emphathis, but the forum doesn't allow this many lines of code. And sure, I could cut it down by starting to apply the nosave behavior, but still. And my game is super tiny compared to some of the behemoth projects I've seen floating around.

    Here's what I'm actually, manually saving in my game. 

    	globalThis.savegame = {
 "current_level": runtime.globalVars.current_level,
 "current_world": runtime.globalVars.current_world,
 "game_finished": runtime.globalVars.game_finished,
 "collected": globalThis.savegame.collected
 };

    Even big games don't need to save all that much. Think for example Super Mario Odyssey. It's probably saving coins, progression, unlocks, moons, where mario should spawn and some whatever data here or there. I just cannot fathom a game that needs or benefits from this excessive type of saving system.

    I do certainly believe that a functional out-of-the-box savesystem would be very convenient and obvously should exist... but I really can't justify using it in the current state. And on the flipside, making a basic save system is really not that complicated.

  • I don't have access to grok imagine but I can still get an image from the chatbot, in which case the image is always saved as a jpg. So I wonder if the file is simply saved in the wrong format for some reason, which is why renaming it to jpg works. Construct might get confused if the expected file format doesn't match which is why it doesn't load.

  • I know you don't wanna hear it but make your own save system...

    My personal opinion on the save feature is still that it is prone to random issues and not adequate for saving a game simply because it's a savestate and not an actual save file. It's neat for a beginner to not have to think about how saving a game works but that's about it. The save feature just saves EVERYTHING and anything you don't want saved needs a specific behavior attached and that's the only control you have over it.

    It's just infinitely better to create a clean save with some json and save/load that in a proper and controlled way. There's of course some extra work involved but that work is worth every second, and in the end it is not actually that hard to do.

    Just for a good example: Let's say you publish a game on steam using the save feature and it's a success... how do you actually create an update for your game without completely bricking every single save file? It sounds like an absolute nightmare to handle this.

    Of course for a game jam it's neat to be able to use this as a quick and dirty way, but it's clear how insanely complex it is to actually create these type of savestates without bugs. It's just more headache than it's worth.

  • I vaguely remember encountering something like that a while back and it was because "Player" was some reserved thing. But iirc it only happened on export.

    Maybe try 

    Player2 = runtime.objects.Player.getFirstInstance()

    Otherwise it's hard to say what's going on. Any errors in the console? Ideally you can post your project with everything removed that doesn't cause the bug.

  • They better not throttle to 60fps and make me angry. I have a 120hz screen and I want 120hz, at the very least when it comes to playing games. Also I thought my game runs terrible on mobile for some reason because I expected to hit 120fps as per usual but because it uses scripts the worker mode defaulted to "no". That's an easy fix but it took me a hot minute to figure out why it was happening in the first place. There should probably be some kind of opt-in from chromes side for games to get the full framerate or something...

  • Well I found the culprit after some digging. It's this flag in chrome.

  • Yeah I thought something like that might be it. A brief test showed that the issue does not appear in samsung internet. So it has to be something chrome-specific.

    If you want to check it out and add it to your infinite todo list I'll send you all the info you need.

  • I recently noticed an oddity regarding the worker mode setting and mobile performance.

    Worker on: Game runs at 120fps as it should

    Worker off: Game now runs at 60fps

    It doesn't even seem to be a hard-cap either as it sometimes spikes to 70fps. In unlimited mode the game runs at ~900fps regardless of worker mode setting.

    Is there a reason why it wouldn't run at vsync speed just because it's not in a worker? Is that a bug or some android/chrome/mobile nonsense?

    I used platformInfo tickspersecond to measure.

  • You don't need advanced random for that. You just made a small mistake and added the offsets when generating the room array so everything generated after the first room was added outside of the arrays bounds.

  • Maybe you could post a screenshot or two of your game here? Or at least a short description? It's hard to answer the questions without even knowing what the game looks like in the first place.

    Considering they say it's not unique enough it's probably not an issue of polishing. But polishing never hurts. I haven't done any app store stuff in a long time but I remember their approval process to be somewhat random, where my game was accepted, but an update with a few bugfixes was rejected for random reasons.

    Referring to their guidlines at 4.1

    developer.apple.com/app-store/review/guidelines

    1. Don't copy the latest hot app on the store

    2. Don't copy a UI/name with only minor tweaks (e.g. Flappy Birb)

    3. Don't make something that could be confused as impersonation of a different app

    4. Don't use someone elses brand/icons/etc.