Playing around with a radiosity shader I made. I might include this effect as a setting for people with faster graphics cards. It's quite subtle in the screenshots, but it looks great in motion. Purple berries cast a soft purple glow on stone, lava illuminates anything near it, and the man's skin reflects light as he's climbing, making the walls look somewhat reflective.

<img src="http://dl.dropbox.com/u/1010927/Forumpics/TCradshad.png">

Is custom movement more efficient in terms of processor overhead? Is that what makes it a better choice than Physics? Just curious.

Yes.

One last question (I hope ): Now that I'm no longer using the bullet behavior, what is the best way to set a range for the bullets? My guess would be some version of destroying it over TimeDelta? Also, should I be using TimeDelta to regulate the bullet speed (so it will run the same on different computers)?

Using timedelta in your movement calculations makes the game run at the same relative speed regardless of the frame rate. For example, when the frame rate drops due to lag, objects will perform large steps of movement, which may result in missed collision or other unwanted things. You can also set a special setting for timedelta which remedies the aforementioned problem; it modifies the timedelta if the value gets to low, so that the game goes from "skip frame" lag, to "slowdown lag" if passes a certain threshold. Timedelta is not mandatory however. You can use a fixed frame rate for when you want to program to run with frame based logic, instead of time based logic. Without timedelta however, if you select V-synced framerate, then your game will run at different speeds depending on the monitor's refresh rate. If you need pixel perfect collisions, reliability and consistancy (ie. low res platformer), then use a fixed frame rate. If you want to be able to slowdown time in your game, then you need to incorporate timedelta (there are ways around that but I won't get into that).

An MMO is pretty infeasible. Not just because of Construct's limitations, but because it is an enormous amount of work for one person.

You have to set them up manually with events, and it all depends on the design of your game. It could get complicated depending on what you want. Something like "fence hop", for example, would require a variable which increments, for a sort of timeline. First, it would freeze the player movement, then it would detach the animation sprite, play the animation and possibly move it over the fence (timed with the animation), then snap the hitbox back to the animation sprite. Like I said, it's really specific and depends on the design of the game. Something like I just described would give a prince of persia (not the 3d one, the old one) type of feel. Maybe you just want the animation to play when the player actually just walks over the fence. In that case you would just set the animation when the hitbox is over the fence. Think about what you want, and try to implement it.

use custom movement and "set speed toward position", and choose accelerate as the type. It functions the exact same way as physics. Like I said, if you want vector based movement (ie. Inertia physics, without the collisions) then use custom movement.

Why do you want your bullets to use physics behavior specifically? Will they need to collide and bounce around physically? If not then physics behavior shouldn't be used. The only time you should use it is if you want physics based interaction between objects. Using it solely for the purpose of vector based movement/inertia is inefficient; for that you should use custom movement behavior. In general you shouldn't combine two movement behaviors unless you're manually toggling between them for a certain reason. Physics behavior hijacks the x,y, and angle of an object, so adding a bullet behavior on top will just apply angle based movement to the object after its movement has already been physically solved and applied by physics behavior. Bullet behavior is dead simple, and is equivalent to the "move at angle" action, minus the time-delta adjustment.

Try add force (1000000/distance^2) (off the top of my head), and just keep playing around with the formula. At 1000 distance the ship only gets 1 pull force. at 100 distance it gets 100 pull force. You can also use clamp(300-distance,0,300) to make your formula return 0 instead of a negative number.

use custom movement for thrust based physics.

At the end of the event sheet set a pv called "last angle" to .angle. Then use the system compare: "angle is clockwise/counterclockwise of" to check it against the current angle. If the current angle is clockwise to the last angle then it turned right.

Edit: Rojo beat me to it.

Saw the video on indiegames.com, it looks really good. I Didn't know you were involved! The concept is pretty cool, like tf2 mixed with battlezone. Does unity hold up well performance wise with a shader intensive fps like this? All the tech demos I've tried of complex unity fps's were really bad performance wise.

I wish you luck davo, seems like a great project!

families maybe? They can be used for things like this sometimes. Depends on the exact situation though.

Construct is basically what mmf2 should have been; a complete redesign. MMF2 is Klik and play with more features, and the grid style event sheet should have been dropped after TGF. And yea, the competition is good for the click products. I can't wait to see what mmf3 brings.