> pre rendered 3D is the worst thing that can happen to a good game.. good pixel art is beautiful. Ever played knytt? No one is playing that game and complaining about the graphics, even if everything is really simple, not even advanced pixel art. It's just... beautiful.

>

Have you heard of a game called Donkey Kong Country?

XD

I have to say that I tend to agree with Attan here (yeah, big surprise ). At least prerendered stuff has to be really amazingly well done for me to actually like it.

DKC is a good example, though it still can't come close to the charms of SMW imho.

all styles have their place.

True!

In short, low-res is easy?but again I say, it isn't a stylistic choice.

Why the F can't it be a stylistic choice? And what are you implying by stating that? And no, it's not easy to make top quality lowres stuff. It's still true though what Quazi said and I like to think that you're getting at that when you label it "easy".

We are no longer in an era where sellable games can afford to have their art created by programmers instead of artists, because even Joe Shmuck can tell when the art is poorly made.

Naturally there is bad lowres art. As there is bad HD art. Poorly made graphics can't be defined by the resolution or graphical style only imho. So you're saying games shouldn't have poorly made graphics. Yeah, so what about well made retro art? It's automatically poor because it's lowres?

Look, for example, at Cave Story and Spelunky: both games are either available or "coming soon" to consoles, and both featured low-resolution art. Notice I say "featured": now that they've got some funding, both are getting a graphical overhaul. This isn't a coincidence. Low-resolution art is sellable only for nostalgia value: it isn't now, it isn't valuable.

Of course HD graphics do appeal more to the mass market. And after all those games are being made to sell copies. This doesn't mean games without HD aren't valuable. What's the value of the original Cave Story game? Doesn't it have any because it's free and lowres? It's still widely considered the best indie game ever. Unless value equals money for you, I'm not quite sure what you're trying to say.

Also if you give a statement that a 2d game should be HD because we're not in the 90s anymore and all... it's basically evidence of you not considering games to be art at all.

Don't get me wrong. By all means, make a HD game. I enjoy those too as I enjoy all well made games. But there's still one good reason why people should keep making retro games: because they want to.

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.