Thanks for the catch there! I changed the line, and now it's fixed :D

Having some issues with this, so any help would be appreciated. Currently, no tooltip appears at all and I'm not quite sure why.

<img src="http://i.imgur.com/pmP5fTL.png" border="0">

BoardGame.capx

Arima is correct. If targeting a specific platform, it's best to ship sprites that are optimized for that resolution. If targeting a browser, in which screen sizes may vary, I tend to account for larger screens (resolutions are increasing over the years anyway) and scale down for smaller screens.

The path between the nodes? When I run the .capx, I see multiple possible paths, which would create problems as the path taken would determine how long the path actually is.

One thing you can try is to create an invisible sprite that pathfinds from node to node and track its travel distance in some sort of variable.

I'm a huge fan of scaling down instead of scaling up.

It looks like you could accomplish this by having a giant level and a ScrollTo behavior attached to the main character.

Definitely is possible - I'm working on one right now. Keep in mind that most of the 'is it possible in Construct' questions are less 'is it possible' and more 'are you capable of doing it'.

Not sure what you mean by goodly amount of text.

<img src="http://i.imgur.com/cFNHm2I.png" border="0">

Basically the first set of terrain generated seems to have multiple generations of terrain overlapping, while the second set of terrain generated seems 'fine' but has gaps in it.

<img src="http://i.imgur.com/hJcx1Pm.png" border="0">

Can someone take a look and help pinpoint where the trouble spots are?

TankRunner.capx

Gave this a whirl. Definitely gets challenging later on, but the difficulty ramp doesn't feel off at all.

Great graphics and sound effects.

Export to HTML5 and you can open the Javascript code.

Ah, so instead of using accelerations and decelerations, use orbits?

This could work. I could have an invisible object in the center for the player ship to 'orbit' around to keep it from going off-screen too much.

This sounds pretty good in theory. I'll keep you guys updated as I test this out.

I guess I'll explain a bit more in detail what the 'fluidity' I'm seeing is, and why I'm not sure how to implement it.

Right now the player ship and enemy ships are powered by accelerations. When the player ship gets within some distance of an enemy ship, it reverses acceleration to give the impression of strafing. However, this looks very 'controlled' and after some time, it just looks like the ship is just being repetitive.

The SPAZ main menu features ships that rapidly accelerate and decelerate to the point where it looks like some of them are stopping and then changing direction, in addition to the 'strafing' I have already implemented. This creates a dynamic feel to the main menu where the ships seem to move in very dynamic and fluid motions.

It could just be that I need to increase the rate of acceleration and deceleration of what I already have, but then comes the issue of having an invisible boundary to prevent the player ship from being off-screen for too long.