The feature I most often find myself wishing for when using Construct thus far has been the ability to manually enter in the coordinates for hotspots and image points in the image editor instead of clicking on the precise spot on the image itself.

I've now tried seeing what the camera looks like when it moves at a slower speed that the flashlight which now moves slightly faster.

I'm probably going to disable to 8 directional movement, as I'm liking the 'click to move' method better right now.

You can also toggle into and out of what will be an "aiming" mode which locks the view in place and moves the camera farther in front of the player using the right mouse button.

http://floatinghandsstudios.com/games/fltest2.exe

It's actually working really well now. I've got an image point slightly in front of the player character and the camera focuses on that, that means the player character is slightly off-center so the visual space can be focused more on his cone of vision.

However, I'm seeing if I can throttle the speed of the camera to speed up if it needs to rotate far, and slow down if it doesn't. Hopefully that'll make the off-center scroll just a little bit smoother. This may be a bit much to pull off but I want to give it a shot.

Here's my current events.

<img src="http://floatinghandsstudios.com/games/events.png">

It properly throttles up to the max speed, but it never comes back down.

I think I'm missing something obvious, but I'm too blearly-minded to figure it out at the moment. Maybe someone else can come up with a better solution.

The biggest problem so far is the placement of the camera. If I center it on the player it wastes 75% of the screen real estate. The farther from the player it is the more dizzying the camera moves are.

I've slowed down the camera from the original a bit which helps (it's now rotates at 180degrees per second). It'd be neat if I could have it ease in and out of the movement with varying speed, but I have no idea where to start with programming that.

I've halved the speed at which the flashlight rotates, I think that helps smooth things out a bit.

I'm a long time MMF user who just discovered Construct and I think I've fallen in love.

First thing I've done is build a game prototype for a horror/suspense style game focusing on limited visibility. Thanks to Shadow Casters this was surprisingly easy. Took a bunch of tweaks to get the shadows to behave how I wanted, but I think it works now. Hopefully I'll expand this into a proper game.

Aim the flashlight with the mouse. Move either by clicking or by using the arrow keys.

http://floatinghandsstudios.com/games/fltest.exe

EDIT: Newer version with combat is below. Left click moves/shoots depending on whether your gun is drawn. Right click draws/holsters gun. Holster the gun to reload. Press space to spawn a monster.

http://floatinghandsstudios.com/games/fltest2.exe

I've come up with a solution that I believe works, I just had to approach it from a different angle. (one that would take less processing power to boot, that's always a plus.)

Dropping the LOS idea entirely, there are now four different types of Shadow Casters. One for each north, south, east and west facing walls. They are very thin and place along the edge of each wall.

To prevent the Shadow Casters from from casting shadows onto the graphic of the wall, east facing Shadow Casters have their shadow depth set to 0 if the players X value is greater than their own. So on so forth for the other three.

It works pretty well, there's a few odd looking bits when there's spots where three walls make a sort of T corner, but some creatively placed casters of the appropriate type hidden inside the wall will make it look better when looking from certain directions.

Hopefully I'll have something to post on the 'Creations' forum with this shortly.

Oh, I got it, and without a dummy object!

I create a new image point 100 points to the right of the right end of the player object and have an event to scroll the camera to the X and Y of that point.

And it's excruciatingly dizzying. I may have to tweak that if I don't want to get people sick.

That's what I figured I'd be doing, but I'm still not sure how to keep the dummy object exactly X distance away from the player sprite in the direction of the mouse...

I'm toying with a control scheme much like the Ghost Shooter where you control where a player is looking with the mouse, however, I'd like for the camera to be focused... let's say 100 pixels in front of the character. However, which direction is in front of the player can change depending on where he's looking.

Is there a simple way to position the camera X distance from an object in the direction it is facing?

Any equation for it is completely escaping me at the moment.

I'm trying to design a game that revolves heavily on the Shadow Caster behavior.

I'm using tiled backgrounds with the Shadow Caster behavior enabled and it works great, however whenever there is a 'joint' where two of the backgrounds meet, the shadows overlap each other. I know it's happening becayse they're seperate objects but I'm trying to get around that so the shadows look a bit more natural.

The way that makes most sense to me is instead of having the walls themselves be shadow casters, have the walls bordered on every side with invisible Shadow Casters. Then have any ones the player has Line of Sight to be deactivated or have their Shadow Depth set to 0, both have effectively the same result.

However, I can't seem to get it to identify the ones with LOS reliably. It'll go for a while and then one will suddenly register as LOS and stop casting a shadow, or I can move around another and it continues to cast shadows.

I have the LOS setup to only register the shadow casting objects as blocking LOS so nothing else should be in the way.

I don't know what the best set of commands to test for the LOS. I currently have the following

-for each 'Shadow Casting Object"

+ "Player" has LOS to "Shadow Casting Object"

set "Shadow Casting Object" Shadow Depth to 0

ELSE

set "Shadow Casting Object" Shadow Depth to 5

Hopefully I'm just missing something obvious. If not I can post the source file shortly to see if someone can help figure out what I'm doing wrong.