BadMario's Forum Posts

  • So if I'm correct the RAM usage is MUCH higher than if every object type had its own spritesheet, as in C2. This is probably why the game is crashing all the time when exported with C3.

    From my recent experience I would say yes, that is exactly why it's crashing.

    I was lucky enough that some basic cleaning up/cropping of all images did the trick and reduced RAM usage enough so that Construct 2 export now works, as I was already in the process of trying to figure out how to split things over 2 layouts and halve RAM usage, and that would have been somewhere between pain in the ass to impossible.

    I don't know what your case is, maybe it is possible to split things over 2 layouts. Can't think of any other options.

    You know, move half of the stuff to another layout, and do the old school, fade when entering a door or a cave and switch to that layout, same when you go back. But without knowing what your game is I am kind of just guessing.

    That would solve the RAM issue, but not the total download issue you have.

  • My game started crashing on some iPhones after adding more players. Turned out it was due to RAM usage. As soon as I reduced that it worked again, so everything points to that.

    having said that there are some possible issues here:

    On a couple of my attempts, using Construct 3 to export this game ( game itself is 100% Construct 2 )

    it started crashing even on other phones, again because Construct 3's Spritesheets use more RAM.

    As for game/download size:

    I did use PNGoo to recompress images after export, because recompressing in Construct 3 did very little.

    With my method the final game was around 13 MB, using only Construct 2 or 3 compression it is at least double that size.

    So, having spriteshhet option to revert to Construct 2 way, seems like would definitely help in situations like this ( with RAM issues ), but unless I am missing something using externaal software to reduce download size still seems to be the only option

  • Yeah, exporting the same game with Construct 3 made it not work even on my Galaxy with 3GB of RAM, so I guess that export was using even more RAM, as suggested by that thread.

    In case anybody else runs into this, I solved it by going through all images and cropping them. Did save quite a bit and now it runs on iPhone 6 and 7, where it was crashing before.

    Just to clarify this is not the actual mobile app, this is HTML 5 export running on mobiles.

    So if your game is over 500 MB in RAM ( according to debugger ) and crashes on mobiles, check that first. Error you get doesn't really tell you anything other than the obvious which is that something went wrong

  • I would not worry about it unless it really becomes something one day.

    More likely you can add it here today. https://gcemetery.co/

  • Any thoughts/experience with RAM heavy games on mobiles. I have a few phones I can test on, but I am beginning to wonder since one of my latest games has actually reached 1GB ( 999mb to be precise ) according to Construct's estimate.

    Gameplay seems fine, but I notice a 2-3 second delay while it loads the main layout ( it should go from intro to main part in less than a second using fades ). I know it is the RAM issue, because I tried quite a few things to figure it out. But other than that no actual problems so far.

  • #1. You can already play HTML 5 games on any screen, so nothing new there.

    #2. It is never going to work, streaming games too unreliable, latency will be too much for games where timing matters

    #3. Simpler Construct 3 and Unity games may in fact be the only kinds of games that will work on this thing.

    #4 Demo they showed apparently was not even running on Stadia, so right now it is pure bullshit and would not be surprised if this is scrapped even before launch.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Well, I guess you have to get used to how Construct 2,3 do things.

    I've always been doing this by Comparing instance variables ( if I understand correctly what you are doing ).

    If Monster var = 10 Monster>play animation/do whatever, then when hits frame X, jump,fire a shot or whatever is supposed to happen, and it has always worked even inside a function

    I don't think I have ever used picking for anything and don't feel like I am missing out on anything.

    Then again I still use Construct 2 even though I have subscription to 3 running.

  • You can specify against which objects to enable/disable collisions so maybe that would work instead of completely enable/disable. You can hide a secondary platform behind the main one and have collisions against player disabled, so he can jump through while enemies could still stay on it. And do the opposite for the main platform.

    Assuming your enemies are like classic platformer enemies, just walking on a platform, not really doing the same thing as the player, it should work

  • Can't you just use 2 different platform objects? Then you can disable one without affecting the other.

    After that just a matter of designing levels so situations in your example only happen with top and bottom platform being these different objects, never the same ones.

  • change your code to Lives = or < than 2,1,0 instead of just = and it should work

  • Yeah, but it is possible to accidentally not select the right layer, or for some reason you click to select a layer, but it does not register thus not switching to that layer.

    As far as I remember in Flash it worked this way and was better ( the way we are suggesting ). In Photoshop, at least the version I have, you can paste things into locked layers, but then you cannot select them unless you unlock, which is stupid. If a layer is locked, then it is locked, meaning you should not be able to change anything on it.

    I know this is not a major issue, but not being able to paste objects into locked layers and automatically switching to the layer where selected object resides would improve things.

  • Yes. this is annoying. because this also makes it possible to paste objects into locked layers, which should not happen. If layers automatically switched to selected objects' layer it would not be possible because you cannot select something on a locked layer.

  • I do this all the time, so if I undrstand correctly what you want, this will work.

    Keep all animations in a single sprite and pin it to whatever....

    Add a number after each of your animations. Let;s say Wizard is 0 and has 3 animations, walk, run, jump.

    Add 0 so they are renamed walk0, run0, jump0. Elf animations will be walk1, run1, jump1

    Then use a global variable called selected. When you select the wizard set selected to 0 and in your events target animations like this: "walk"&selected , "run"&selected and so on

    If a different character is selected then variable would be set to 1, or 2, and do the same thing, adding those numbers to each animation's name.

    So that sprite will be pinned to your puppet sprite and the right animation will be playing depending on selected variable

  • I think your example is good enough, so I would not worry about it too much. Just polish it up and finish the game.

    All physics engines, although they help, have things missing. One of the most annoying things with box2D is if something moves too fast it will go through objects.

    Guess what happened the first time I used physics in Unity and threw a soccer ball a little faster. It went straight through the net and through ad boards behind the goal. If you ask a question about this, you will get an answer along the lines of: "you have to use raycasting, bla, bla, bla, code it yourself"

    Shouldn't that already be a part of the ^%$9ing physics engine, yeah it should, but look at the bright side, at least it allows you not to have to code all the other parts that actually do work.

  • Particles.

    Try this one deusx.com/swipe-kicker

    Starts snowing after the second or third kick and snows more and more as the game goes on.

    If that looks good to you I can post the exact particle settings