— - I may be wrong about this, but wouldn't that mess up the simulation in behaviours?

With point sampling, the object position still has sub-pixel resolution and only the display is rounded. If you round the actual position you will introduce errors in calculations for velocity, friction, gravity, etc. which could result in inconsistent movement. It also means you add an extra ACE to the event sheet which will be calculated every step.

You need to set the renderer to use point sampling, so that pixels will be drawn to the nearest whole number, rather than interpolated.

Click on your layout, then in the properties panel click on Application: Properties. Go do to Runtime Properties and set Sampling to 'Point'.

Put your dummy object into a container with your enemy tank. Each tank will have their own dummy object, and picking in events should use the correct dummy. The events might get fiddly but they should work.

Add an event after the add waypoint event -

+ System: While

+ Waypoint: Waypoint overlaps Wall

-> Waypoint: Set X to Random(DisplayWidth)

-> Waypoint: Set Y to Random(DisplayHeight)

So it will keep randomising the position until it no longer overlaps with a wall.

Totally untested, but I think it should work. I've used a similar technique in other software, in the past.

EDIT: Just looked a little deeper and realised your waypoint is not actually an object, but is an option on the RTS behaviour (which I've never used), so my solution above won't work. However, I'm confident the concept will work with a little tweaking - just use a 'while' to relocate the waypoint until a usable position is found. I'll see if I can come up with a proper solution.

Hopefully this image explains it a little better:

<img src="http://i39.tinypic.com/9zm4no.jpg">

• 1. Draw the sprite so it is facing to the right
• 2. If you drop an instance on the workspace it will look the same as in the editor
• 3. But you can still rotate instances to face any angle in the editor
• 4. The selected instance in this image has been rotated to 90deg - pointing downward
• 5. For pivoting objects like this, you only need one animation angle:- 0deg, Right

You can add event code to an object like this to make it point towards the mouse, like so:

+ System: Always (every tick)
-> Sprite: Set angle towards (MouseX, MouseY)
[/code:279fk2e9]

This will set the angle to the direction of the mouse pointer, so if you put the mouse on the right of the sprite it will set the angle to 0. This is why you should always draw rotatable sprites in such a way that they point to the right.
Hope this helps.

TimeDelta is the amount of time that has passed during the previous loop of the game engine.

• For one second in game time, the sum of the TimeDeltas from all of the frames in that second will equal 1.
• If your game was running at a consistent 50fps, TimeDelta for one of those frames would be 0.02 (1/50).
• Anything time based (movement, rotation, etc.) should be set to the amount you want it to change per second. For example, 200 pixels per second would be a nice number for movement speed.
• When you multiply that by TimeDelta, you end up with the correct change per frame, regardless of the actual frame rate.

So, at 50fps TimeDelta would be 0.02, each frame the object would move 200pixels*0.02 = 4 pixels. However, if the game was running at 100fps then TimeDelta would be 0.01 (1s/100f); 200*0.01 = 2 pixels. This table shows how TimeDelta keeps things like movement consistent:

fps    TD    Speed (pps)    Distance per frame    Distance per second
25    0.04      200         200 * 0.04 = 8        8*25 = 200
50    0.02      200         200 * 0.02 = 4        4*50 = 200
100   0.01      200         200 * 0.01 = 2        2*100 = 200[/code:133jkltd]

Frame rates won't always be consistent, but TimeDelta will always represent the relative time taken by each frame, so the results will always be consistent. 

Just remember- if it is changing over time, use the amount you want it to change in one second and multiply it by TimeDelta.

I'd love to see cap files replaced with something along the lines of an IDE style project folder. The general project info would be in an XML file (settings, lists of objects & plugins, etc.). Everything else would be pushed out into sub-folders (images, music, data, layouts, events, scripts, etc.).

C2 could then have a function to bundle entire project folders into zip based caps for sharing, but still giving teams the ability to collaborate on project using CVS systems. Event sheets, layouts, object settings and families could all be created using XML files, meaning you could even make small changes to projects using notepad.

Unity3D has something like this, whereby dropping a file into a project folder immediately makes it available in the IDE. A really nice system, IMHO.

If you're talking about free 3D game creators, then maybe somebody should mention Unity and ShiVa.

I've been moonlighting as a Stencyl beta tester for a couple of months now, when time allows (I'm a busy guy). I just want to say a couple of things, hopefully without breaching the NDA in the process:

• The programming system, strange though it looks, is probably the closest thing I've experienced to proper programming in a drag and drop system.
• The games they have demoed are not the only ones in existence, are they are still in development. There are many more in the beta community, including one of mine.
• The engine is Java based (pulpcore) and the games play in the browser, which means no hardware acceleration. It's a trade off of power vs. cross platform compatibility.
• The big selling point for Stencyl is the collaboration. There is a real emphasis on sharing resources and creating reusable assets, so that devs don't have to reinvent the wheel all the time.

Overall, it's a decent game making system, and like all such systems it all depends on the talents of the people using it. There is enough flexibility in the software for someone talented to do some impressive work. I wouldn't necessarily say that it is competing with Construct - they have an entirely different set of objectives.

Just to clarify, for my own sake (I still struggle with picking)...

• The condition "if sprite is visible" will run once and add all visible sprites to the SOL
• The condition "for each sprite" will loop through all of the sprites in the SOL
• Actions under this event will be executed on each sprite in the SOL as the loop is iterated

Is this correct?

So, "for each sprite, if sprite is visible" will produce the exact same result as "if sprite is visible, for each sprite", however the later is more efficient because the SOL has been cut down before the loop.

I think it's another example of the need to unlearn some of the conventions of traditional programming when working with eventing. Normally, I would do it like so (psuedocode):

for (sprite in sprites) {
    if(sprite.visible == true) {
        do stuff
    }
}
[/code:1cv9a7p5]
But with eventing you have to think a little differently.

If your animation appears to be sliding, then you just need to adjust the values between movement speed and animation speed so that they match up. Either slow down or speed up you object, or lengthen/shorten your animation frames.

Look at how many pixels your character's foot moves in a single loop, and make sure that your character moves roughly the same amount in the same timeframe. The simplest way to do this is through trial and error - test different values until you find one that works. To save compilation time, you could tie the movement speed to some keys and adjust it on the fly, then input your final values after testing.

Of course, if your character has acceleration and deceleration, there will always be a point when the feet don't match the motion. In game maker I would fix this by tying the animation speed to the movement speed, but I'm not sure if that's possible in Construct. You could fake it by having two animations - run and walk - and switch between them when you hit a certain speed.

Currently just a mockup, although I have a little of the engine done. First ever try at pixel art.

Normal size 8X8 sprites

<img src="http://i19.photobucket.com/albums/b170/mr_flibble_hhah/pixrick-2.png">

Blown up X4.

<img src="http://i19.photobucket.com/albums/b170/mr_flibble_hhah/pixrick.png">

Those look brilliant, Minor. Do you mind if I give you a little suggestion though -

Try to establish a common light source in the tiles. Your rock walls have light coming from several directions. If you were to set up a consist light source with your highlights and shadows, the tiles will read much better.