sure,

I'm using the C3 runtime with the stable channel.

I'm exporting through Cordova using the C3 export options. All export options off, hide status bar on, and min version +5.0 (Lollipop) which is by default, though I don't get good performance on old phones using that OS so will probably restrict to newer OSes before proper release.

Using signed APK which is a requirement of the Play Store, though prior to that was getting the same performance with debug APKs.

I mainly just followed the guide on the Construct main page for building mobile APKs.

Added a timer. Currently set to off by default.

Also had another look at the jump/attack button collision boxes. Turns out they were overlapping by a couple of pixels, which may have caused the wrong button to be tapped if it was right in that zone. Have separated them a bit further so hopefully that will help.

Cheers

Hi Artpunk

You posted as I was typing a reply to Plinkie, so I missed this at first. Thanks for the feedback.

Some of the music is pretty bad, I agree with you there. The songs are a bit placeholderish until I can get something better in there.

Plinkie also mentioned the collision boxes for the buttons so clearly I need to get back and see about this. The collision boxes are currently bigger than the buttons, but now I'm wondering if they're too close to each other which is causing the wrong button to accidentally be pressed (the pitfalls of making a platformer on a touch device I guess). I'll look into it.

I mentioned the timer as being an option in the other post, looks like this'll happen. Now that I think about it, I like the idea of not showing the timer unless the level has been completed at least once. This way the player won't feel rushed on the first play of a level while on a replay they'll have the timer there. Still have an option to turn it on or off as well.

Can I ask what type of device you're on, your experience with these types of games and how you found the difficulty?

Cheers

Hi —

Thanks for the feedback.

The whole speedrun/clearing out levels was meant as a way to go back and replay the levels and earn extra stars. It's not actually possible to speedrun a level plus clear it out in the same run, nor can you speedrun a level until you know how to beat it as you wouldn't know where to go. Once you get a star for a level, it gets saved and you can't lose it. I can see how this might be confusing when a lot of mobile games require certain conditions to be met in a single run before handing out 3 stars. Clearly, I need to emphasize this more, I will add something in the tutorial about this, plus something in the first couple of levels. My intention with this style was always to encourage the player to take their time on the first run, then come back later if they want to really challenge themselves.

I did have a timer there for a bit, but removed it for the sake of having less clutter on the screen. I may consider an option that toggles it on or off.

I hear you on the bats, they were actually more powerful before :D I'm thinking I'll take them out of the first bunch of levels until players get a better feel for the controls. Will replace them with one of the easier first world enemies such as the skeletons. I also plan to add a variable jump control which will hopefully address your point on the jumps being hard to control - so basically a quick tap for small jump, long press for larger one.

I'm still playing around with the best way to represent the shop. I like the idea of having some items available to look at right away, so I think this is a good idea. Regarding the whole Metroidvania thing you mention, the first purchase was designed to teach players how to use the shop, so progress is only blocked for as long as the player doesn't go into the shop and buy the first sword. Once you get that first weapon there are no more blockers, meaning you can beat the rest of the game with just the iron sword (not recommended). Still, I hear you, and will look at opening up some more purchases early on.

Can I ask what you're background is when it comes to these types of games and what type of device you're playing on?

Cheers

well, looks like it wasn't the FL Studio audio files causing the issue.

I think I'm going to leave this for now, running without preload sounds on seems to be doing the trick anyway.

Ashley running the stable channel.

Nepeo I'll have a look at that stuff when I get home from work today. I do have some small sounds files in there at 3-4kb, however, they're all .wav files.

I was thinking about this this morning though. I use a few different programs to generate sounds. One of those programs is FL Studio. I don't think I was having this issue until I imported some sounds made in this (because I imported a whole bunch from different sounds generators at once, I didn't see the link). I'm wondering if I delete the sounds made in FL Studio whether my load times will vanish again. I will try this when I get home as well.

So removing all the sounds in my project made it load instantly. The loading bar did flick on for a frame before going straight to the first screen before the bar even had a chance to animate, so essentially instant.

Likewise, setting the project to not preload sounds has the same effect.

I'm wondering if I screwed up the encoding with one of my .wav files. This didn't happen until I loaded in my second set of sound files, so maybe I have one in there that's not playing along.

For now, I think I'll just leave preload sounds off.

Thanks for the reply. Not sure it's possible to test the log in APK is it? Never had this issue launching from pc.

Having said that, I also noticed that sjrya says this: '-After some trial and error, I converted all my audio files (Sounds) back to .m4a from .webm and that seems to have solved my problem.'

Which makes me wonder if this is somehow related to my issue, which only started after I added some sounds. In fact, I didn't even get the loading bar prior to importing the sounds, it would load instantly into the game.

Going to do make a test version of my game with all the sounds removed and see what happens.

Hi

So I kind of feel like the manual is a bit lacking with regards to the persist behaviour, but I thought I would do some tests and see if this is something that I could use instead of my current system.

Anyway, I have chests that only spawn the first time a specific level is beaten and they hold an upgrade for the player. If the player has already beaten that level, the game goes straight to the next screen.

I thought I would have been able to add a persist state to the chest and have a boolean that lists if it's been opened or not, then check each time that level gets beaten.

It works as long as I leave the program running, but as soon as I close the program down and re-launch it, the chest reverts to its original state.

So I'm wondering, is there a way to make a persist instance save its state even after a program relaunch?

Ta