Replace the "+" with "&".

"This is a number "&global('varNumber')

That'll work.

And welcome to the forums!

[CHANGE] - When grid scrolling, the zoom level of the camera will clamp to a point where space outside of the current grid area is never visible. Same goes for "Bind to layout".

Beyond awesome!

Wuv u !

Cool, haven't been expecting to be able to play this so soon.

The level of presentation exceeds pretty much anything we've seen so far in Construct. The art style is really gorgeous, the animations and character design charming and even the music fits so well.

There is not much to say but to praise this little gem of a game. And since I want to go back to playing this a little more, let me quickly nitpick some things:

• First of all it immediately striked me as potentially annoying having to go back to the entrance of the level all the time. I mean if there aren't any changes in the level it becomes more of a chore than a joy imho.

• I do loathe X and Z.

Because Y and Z are switched on many european keyboards a layout like this becomes really uncomfortable. Therefore I'd prefer X and C as standard keys. Yeah, us europeans...

Other than that, I sure do hope this will have gamepad support. I think I read that it would have, maybe even this beta has but unfortunately I don't have access to such an input device right now.

• More sound effects for Talbot!

I pretty much only noticed the noise he (is it a he?) makes when he drops down. Maybe some stressed groaning when you're really pushing him to fly or something. Just want MOAR!

• The particle effect when you pickup a baby ghost looks lazy in comparison to the otherwise polished appearance of the game. Not a major thing, but an "out of the box" effect like that seems misplaced imho.

As I said, those are just nitpicks. I'm really impressed with the work you guys put into Talbot's Odyssey. Which is why I'm gonna play some more now.

As good as Advanced Cam was, this sure sounds a hell lot better. Will be trying it soon. Thx for all your hard work linkman!

It is on such a layout (and needs to be). Anything I can do to get around that?

If I understand correctly what you're trying to do you should look into some system expressions. Check out the following example.

http://dl.dropbox.com/u/2306601/seteditbox.cap

It sets the editbox position when you click left using the ScrollXLeft and ScrollYTop expressions, which return the left and top visible edges of the layout. Therefore it will work correctly for nonscrolling layers.

I imagine getting rid of the 'always' event would help performance too?

It's not really a performance hit, just unnecessary. The loop will run every tick with or without that always event.

Family PV and per pixel collision fixes sound especially exciting. Thanks R0j0 and devs!

I used PixelRebirth's CAP as a base, so I took his sprites!

How dare you steal my block tree and stickman sprites? That was hard work dude!

Basically it tests for distances, then set the opacity of a tree to less-than-100 if the distance between those and the player are below X. Then, using the value of this distance, we can add a soft easing on the distance when the player moves.

The tradeoffs for this example over what you were discussing are:

+) Using the Y as reference for what's behind or in front of the player (Z ordering), you get more control of which tree to apply the effect.

o) The whole tree disappears (or nearly disappears - you just tweak the lower value). I don't know if its positive or not, but personally I like this style.

-) CPU intense: You may have to come up with better events if you use hundreds of trees on a level, the way I did it tests every tree in the level in every tick - not a nice idea.

Generally I like your approach. Without checking the Z ordering (like you mentioned) it appears a bit odd when even trees that arent in front of the player get faded. So that should definitely be added.

Oh, why did you use an always event there? You can just loose it and it works the same, btw.

Wow, thanks for taking the time to put that together! For some reason I'm struggling to get this to work when I edit the tree's layer mask though... I want the tree base to be solid so that the player cannot walk through the trunk, but is still able to walk behind it. So I've made the tree a solid object and erased everything from the layer mask except for the base. The collision detection works, but the player doesn't disappear when he walks behind it and the circle doesn't show up.

Well, that's not really surprising since the events in my example use an overlap condition in order to work. And when you edit the collision mark, it doesn't overlap anymore properly.

If I remove the 'solid' attribute from the tree then the player disappears behind the parts of the tree with the layer mask, appears correctly in front on the tree, but still shows up on a higher layer when he should be behind it whenever he's not in contact with part of the layer mask. And, of course, he can walk straight through the trunk...

I guess I'm doing something very wrong here? Should layer masks for trees not be deleted at all to achieve this affect? And if so, how can I make the trunk a solid object? Using an invisible block at the base could help I imagine, but would lose the exact pixel collision.

Hope that's not too confusing :S

A little confusing right there, hehe. I'd say you should put another sprite in a container with the tree. That object would be invisible and be solid. You shape it accordingly and set it to the tree's position with an event. That should take care of that.

But another problem I would see with this method is Z odering. Like smaller stuff, that would be behind the tree (like a flower for example), but maybe in front of the player at his feet and visible too, when the player is covered by the tree. I guess that may have sounded a little confusing now as well. Anyway, at this point I'm not quite sure how I would achieve this myself, while still using the basic method I showed. Maybe I'll give it another try these days.

What is the best way to think about multiple levels in construct? Should each level be in a different layout or should events be used to load things to get another level?

Generally speaking the 2nd method you mention would be preferable. However, if you have a little game with say 3 levels it might be more of a hassle and not really worth the effort to develop such a system/level editor.

How are behaviors of objects updated if there are multiple levels? Must changes be done individually on every level?

This question somewhat confuses me. If you have instances of an object with a certain behavior on multiple layouts, it will naturally work on all of them.

Can an object have a static variable? IE: player sprite has a static health variable that does not change from layout to layout.

That's what global variables are meant for. So instead of using a private variable which is directly connected to the object, you use a global variable, which will stay the same throughout layouts. Also look into global objects. But beware this will mean that the object keeps existing on every layout unless you destroy it.

And welcome to the forums.

You usually don't use negative width for sprites to mirror them for different directions. That's what the auto mirror attribute is meant for. Combined with the auto rotate attribute of the Platform behavior it should work just fine.

I also noticed that you have the frames of your animations always facing left. They should face right since the standard direction is right as well. You can simply flip a frame horizontally by right clicking and selecting the option.

So fix your frames, get rid of negative width (also the events that do set negative width) and enable auto rotate and auto mirror. Then you should be fine for the most part.

I'm not sure but auto rotate might not work properly on sprites that have ignored input. In that case you should be looking into setting the angle manually to the movement angle or some similar solution.

Oh, you also should put the "Start ignoring user input" action in a "Start of layout" event, btw.

And welcome to the forums!

Thanks for all the advice! I'll definitely use transparency instead of a complete invisibility, so I'll see if I can get that working with the canvas. If not, I will just have to turn the whole tree transparent instead, which still does the job.

Thanks again.

Just to clarify what I was getting at in my earlier post... here's a simple example:

http://dl.dropbox.com/u/2306601/treesee.cap