the "get destination x/y" is only the final destination. such as where the mouse was clicked.

the algorithm used to find the rts path on the grid has to have mapped out a path for the object to travel, it just seems there has to be a way of referencing points along that path.

further more it wold be nice to be able to change certain grid locations values to make them more appealing to travel. such as a lower value for roads , or a higher value for mud.

i know you could make a custom A* search algorithm with nodes. but grabbing the info off of the rts movement wold be significantly easier.

Just to add to the RTS request, it would be nice to be able to get the next node X & Y Position in the RTS movement path.

http://rapidshare.com/files/445330713/Flash_light.cap

let me know if that worked any better for you.

http://www.mediafire.com/?qflvap6u1yketez

I'm sure someone else has made a better flashlight tutorial in the tutorial forums with bump mapping and all that jazz. oh well heres a simple one.

to explain whats going on:

-make a new layer

-make a gradient of black to black (or whatever)

-set the layer 2 opacity to 75 ( it just needs to not be 100%)

-make flash light sprite on layer 2

• set flash light effect to erase

fill free to use the flash light sprite.

_____________________________________________________________

As for your game. it seems like its basically the ghost shooter with different graphics and a crazy intro.

I'm sure your just starting out. so good job on the intro and picking up the gun.

I recommend you play with the rts movement for the "zombies" instead of the ghost charge thing. it looks a lot more organic and they wont fly threw the walls.

hope you stick around and improve your ability's. theres tons of helpful examples hidden in these forums, you just need to do some digging.

And if you have questions the people here are extremely helpful. so just ask. but try not to spam.

the offset is what i think is so cools about the Z Elevation thing as apposed to just changing the objects size.

as long as the camera is locked onto the object changing z elevations there don't seem to be any problems with the offset of the object.

check that. if anybody is having a similar problem:

Set (xy)Zoom: 100/((object.ZElevation+X)/100/5)

X= whatever hight you want the camera to be from the object.

100 is basically on top of the object

200 is further away ext...

it works fine.

thank you.

I'm trying to have the camera zoom out at the same rate as the object grows, thus making it look as if the objects not changing size.

I've never used ZElevation before. it looked like it could make things simpler

if it had a direct 1-pixel to 1-ZElevation ratio:Set (xy)Zoom: 100/(object.ZElevation+100)/100 would work.

but it sounds like the growth is relative to the camera location itself. if thats the case it looks like i need to make a custom z-elevation like thing..

Quick question:

At what rate dose an object change size as it changes z-elevation in construct?

as far as i know, i don't think you can have different animations of one object be different parts, i wish it was that way, it sure would clear a lot of the objects out of the library.

you can take whatever you want out of the code, as far as i'm concerned taking bits of code and re-writing them is the best way to learn how things work.

when i get some time, i wouldn't mind making something to show you how all that works.

there might already be a video on the bone movement somewhere, but i haven't looked.

if you don't have Photoshop, an idea on making all those pieces one object would be to put them together in construct, copy the screen(ctrl-prt scr) then past in paint, crop out what you don't like, then put the image back in construct as a single object.

( i'm sure you could also make a sprite making program using the canvas object.)

top-view shooters are without a doubt the easiest (graffix wise) games to make, you can get by without any animations, and worlds are generally just repeating textures with things placed on top.

pretty much the reason they're my game of choice to make to flesh out an idea.

but for the character, if your not to terribly great at drawing, i recommended using the bone moment, i sure you can draw simple shapes like circles and what not and with a little shading they can look pretty good.

textures for the ground you can just grab off the internet("free ground texture" Google)

objects and walls are probably your trickiest thing, but a birds eye view is kind-of an unusual way to look at the world, so you got a lot of room to mess up.

heres the beginning of a current TD-shooter i'm working on with the bone movement, to give you an idea of what i'm talking about.

wasd - move

lmb -fire

rmb- aim

esc- exit

shift- run

http://www.mediafire.com/?92khuc4at8nhk73

(there is a lag in animation when switching to and from running, and just ignore the missing sound files) it is what it is.

quadrant scrolling is an interesting solution.

i was thinking since the only tiles that have collisions are on the edges of the terrain. i could just have the edges persistent and have the rest kept in the array, drawing those when the screen is near, or draw them to a canvas.

wish i could just drop the tiles all together and just use the canvas, problem with that is there seems to be no efective way to save a canvas.

this is kind of what i was thinking of making:

if i just drew the tiles on screen, collision detection and path-finding wouldn't be able to happen else were.

and if you used the canvas object to paste tiles that change type, wouldn't you have to remake all the tiles and paste the current changes. I assume that would just cause massive dips in fps