Load the default values from hashtable, ini or other data object into global variable. Sorted.

So, where is "game development software/program/kit" etc?

Behaviors aren't broken, Construct just recalculates positions before using them. But if you want the actual game to use actual coordinates, you just use actual numbers - the relative stuff is mostly needed for graphical interface, such as menus and sidebars, that have to always be on certain location on screen.

In that case you have to set it up to keep running until it's made 64 pixels. Make an event that is run whenever a private variable contains the right value.

Like this (assuming you have a private variable 'Status'):

//triggering event
+Right Arrow is pressed
+Player('Status') = "Idle"                           // Only move the player if it is not already moving
Player('Status') = "MoveRight"                // Tell it to start moving

//actual moving event
+Player('Status') = "MoveRight"                   //check if the player is set to move right
+Player.X < Player('OldPositionX')+64            //Keep moving until the goal is reached
Player.X = Player.X + Player('Speed') * TimeDelta
++Player.X > Player('OldPositionX')+64          //Whoops, a little over the goal; it means it has reached it
Player.X = Player('OldPositionX') + 64          //This is to round the player's position up
Player('Status') = "Idle"                //Tell it to stop moving

There is no better way to learn than prototyping in Construct. Just think of a simple concept, prototype it, when you get stuck, ask around or browse forums/wiki and eventually you'll know Construct better than its own creators.

Oh yeah, zooming was the other trick I forgot to mention! A certain layer - where you have the GUI - can be zoomed, but I'm not sure if that would leave other layers intact.

Since this is more of a theoretical rant than anything else, I consider it to be a tutorial, thus I am placing it here. It is useful to see an example of progressive brainstorming.

So. You've no doubt tried fiddling with various screen sizes, be they 320x200, 640x480, 800x600 or higher. But when you change resolution, all the objects are thrown off proportions or positions.

If we want objects to maintain relative sizes and positions, then we have to use a couple tricks.

First, we don't use absolute coordinates anymore. Instead we use abstract coordinates. How? Well, here is how:

• there are system expressions, DisplayWidth and DisplayHeight, that return the size of screen (window or fullscreen)
• now, we have an object we want to always be positioned smack middle of screen. In a 800x600 layout, we'd place it at coordinates of 400x300. But if we change resolution to 640x480, the object is now closer to bottom right corner! Thus we have to use relative position. How?
• We take DisplayWidth and DisplayHeight and with simple math modify them to obtain the correct coordinates. In our case, we simply divide both into half. DisplayWidth/2 = 400 and DisplayHeight/2 = 300 for 800x600 or 240 for 640x480, respectively. If we want to place an object at 10% of height (from top) and 90% of width (from left), thus in top right corner, we use DisplayWidth*0.1 (1/10) and DisplayWidth*0.9 (9/10). If we want to use precise coordinates, we just use precise multipliers.
• We can modify the size in same way! Say, we need to define the default resolution and come up with some multipliers for object resizing: DisplayWidth/'DefaultWidth' and DisplayHeight/'DefaultHeight' are your size multipliers. So, to resize an object at resolution change we just need to set Height to 'OriginalHeight'*(DisplayHeight/'DefaultHeight') and Width to 'OriginalWidth'*(DisplayWidth/'DefaultWidth'). Obviously OriginalHeight and OriginalWidth are private variables as well that store the original size.
• Voila! Scaling GUI!

The gameplay is a bit dull; perhaps if you had to match colors by nudging balls toward each other, it'd be more engaging! Also, mouse nudging seems to be a bit rough.

It does look nice, though!

Use TimeDelta system expression.

It is basically time between two frames. If you multiply your speed variable, say, PlayerSpeed, with TimeDelta, the player will move by the amount of pixels he would have made in that time (frame).

Move at Player.Angle for Player.Value('Speed')*TimeDelta

Try it out.

Intending stuff is not enough to tell nested events apart. It would be easier to recognize nested events by using different frame colors (in contrast to parent events). Like this:

Hi, I am busy parent that never comes to kid's shows!

+ Hello, I am the kid that pees onto your lawn!

++ Woof! I'm the kid's puppy!

+++ And I am a flea on the puppy's tail.

+ Hi, I am the girl that likes to turn music to the max!

++ Yawn... I'm the girl's deaf cat.

Just an idea.

[quote:38qxyah2]Note: These statistics were gathered from visitors to a website dedicated to web technologies, so there may be an over-representation of both higher resolution monitors and lower resolution handheld devices. Updated to January 2009 results.

I don't think casual gamers frequent web guru sites.

For portability you'd want to stay around 640x480 or so, most computers nowadays are still between 800x600 and 1024x768 resolution... higher resolution are the vocal minority.

But don't quote me on that. I just suggest to make everything windowable.