Listening to episode 2 now. Nice going guys! I'm looking forward to hearing more of these.

Hah, yes they take some practise Once you're comfortable then I'm sure you'll appreciate them. I only use spritefonts in my projects now - no text objects for anything but debugging. They're especially useful for games that require vibrant text (like games for children), because you can add all of your effects to the spritefont file before-hand, then just import the finished product with zero impact on performance, as opposed to using post-processing effects to give the text more character.

Your best bet is to make your own using BlackHornet's Sprite Font Generator. Download the example file to learn how to properly implement character spacing.

I suggest that you render your spritefont image to a size larger than what you need. That way you can scale it freely without losing quality. Just try to keep the size to 1024x1024 as a maximum, to avoid excessive memory usage.

Yes, if you sign in Intel XDK then that's all you need. You can submit to Google Play just like that. I'm not 100% sure if that's an issue for you or not (it would be if you previously built with a different system, like CocoonJS).

To disable signing, go to your build settings in Intel XDK (click Projects at the top-left, then select your game/app), select Android-Crosswalk, then scroll down to a checkbox that says "Signed". Uncheck that.

I like it. Very classic kind of gameplay. Reminds me of a lot of old Atari and Commodore games!

The level design is good, although I feel like the areas are a bit too open. Maybe that's just because it's the early levels while the player is still learning the ropes, so I don't think it's really an issue - just something to take into account later on.

My biggest gripe is the controls, though. They feel very stodgy, like the player is moving through mud. This could be improved by massively increasing both the acceleration and deceleration of the player, for a more deliberate and predictable type of movement. Precise controls are essential in a puzzle game like this. I also recommend that you look at reshaping the player collision polygon to something less round. Using angular corners on the poly will help reduce some of that "hitching" that happens when the player tries to walk around a corner in the game.

I've attached a super quick example of my suggestions.

Otherwise, good going! I think this kind of game works very well on mobile so I hope to see something soon

Did you already sign the apk in Intel XDK? If you did, then I found resigning it afterwards breaks thing. Either sign with the XDK, or export an unsigned apk and sign it manually.

I'm not sure what I mean by making a y coordinate infinite, but there's an infinite jumping template that come with Construct that might help you get started. You can find it by creating a new project and scrolling down the list to find Template: Infinite Jumping.

I thought this would be an interesting challenge, so I made an example for you!

The logic might seem a little tricky if you're not too familiar with loops in Construct, but essentially it works like this:

1) Create individual sprite font objects, one for each word. (I've included two options for this: automatically or one word at a time, depending on what you need).

2) Ensure that each of those objects lines up correctly after the previous object, or wraps down to the next line if necessary.

Once you've got the individual sprite fonts set up, creating highlights is easy. Just step through each one consecutively, creating a highlight object and positioning it accordingly.

I wrote a tutorial a while ago that covers this: https://www.scirra.com/tutorials/443/bu ... our/page-3

But it doesn't solve your ideal requirement: curved paths. this has been asked for a million times but I'm in support of it so I'll rally behind your request (for what it's worth, which is practically nothing). There are some plugins that do this, more-or-less, but there's nothing quite ideal that I've seen, and unfortunately I lack the maths skills to help you with figuring out a custom solution.

But, hey, my method will at least set you on the right track.

Hello!

I've just released Zoomaze on Google Play. Zoomaze is a maze-solving game designed to appeal to those looking for either quick fixes or long play sessions. The current release has two game modes and more are planned. It's designed to be simple, quick to get into, and slightly nerve-racking

Get it here on Google Play.

Get it here on iTunes.

Marketing blurb!

Features:

• Infinite replayability!
• Two game modes!
• Nail-biting, maze-solving action!
• Completely free!
• Sarcastic in-game text!

Play through an infinite number of randomly generated mazes in two game modes. Classic Mode is fast and brutal - it'll make you flip-flop between self-loathing and loving everything. Career Mode is more sedate and a bit more forgiving (at first) - for those who have some time on their hands and want to compete for a top spot against other players.

The standard game is entirely free and supported by very discreet ads. As more game modes are made available in future, we may include in-app purchases, but the core of Zoomaze (Classic and Career modes) will always be free and will never be made unbalanced due to these IAPs!

Screenshots!

Planned features!

• Release on Windows Phone and Desktop
• New game mode: Adventure (extended Career mode with characters, combat and loot)
• New game mode: Blitz (features all sorts of crazy power-ups)
• Alternate maze skins
• Alternate player skins

Please feel free to comment, criticise or share any thoughts you may have on the game. And if you find any bugs or weird behaviours, I'd love to know about them.

Thanks!

I'm actually very glad that you brought this up - gave my a nudge to test this myself!

I remember Ashley making mention of something like this sometime ago with regards to someone's question about performance with individual rain drops as sprites. He suggested then that it'd be more efficient to move the rain drops to the top of the screen when they hit the ground, instead of destroying and recreating them.

I made a quick test to see this sort of problem in action, and, provided my testing methodology is accurate (I think it is), it's definitely more efficient to move objects than to destroy and recreate them. With this test, on my machine, I started to see frame-rate wobbles (or "pulses", as it appears in this test) around the mark of 3,500 instances with the destroy/create method, whereas with the move method, I could take the instance count up to 15,000 before the frame-rate dropped below 60 fps (once it got up to speed, that is). And even then the frame rate, when lower than 60, would be very stable up to about 35,000 instances.

Try out this demo yourself. You might need to adjust the repeat or sprite count checks, depending on your machine's hardware, to find the point at which the difference between the two techniques is the most noticeable.

Make sure that in the layer's properties, "Force own texture" is set to "Yes". Also make sure that the z-order of the sprites is correct based on your chosen blend mode.

No, the emulator runs horribly. Don't rely on it for anything but testing basic functionality. Build your game and install the APK that you receive - that's the only proper way to test performance.