PixelRebirth's Forum Posts

  • As other people mentioned this is a beautiful and unique looking game you have here. The only thing desired are more frames for your animations. But I guess that'll be improved once you progress.

    When I took a look at your cap I soon got a vibe of you overcomplicating things.

    • Your animations have frames for both directions, when just one and the auto mirror attribute would do.
    • You use Play Animation actions where it's not necessary.
    • You have different conditions for different directions when you spawn the attack wind sprite (GustAttack). You don't need that for right/left, since spawned objects will automatically adapt to the angle of the object they're spawned from.
    • The many events you use to control your lifebar. That can and should be done with simple math. One event.

    That's just what I noticed taking a quick look.

    Regarding some of the problems you're having:

    -When talking to characters, you need to press the button twice the first time.

    That doesn't seem to happen for me.

    -Attack and Death animations not playing correctly (getting stuck on frame 1 etc.)

    Well, the way your attack events are set up it's bound to not work properly. First of all it's possible to just quickly press the attack key without actually attacking. The animation will briefly play and go back to normal then. Instead you should make it that when you press attack, the animation plays at least 1 time and a wind sprite is spawned.

    I think it's your intention that the attack animation should stay on the last frame and keep spawning wind if the player holds the key. So this kind of works already, although you shouldn't use For every x ms there. Instead the first time you spawn it you add to a PV a certain value and keep always subtracting from that value (use timedelta). When its 0 or below, you spawn again one and reset the value.

    L5j, those are some good design comments too. I've been experimenting with getting glide to work with the same button already, but haven't had much luck getting the script to work. Does anyone know of any other Construct games which use a double jump or glide?

    Why wouldn't glide with the jump key work for you? Simply replacing Z with SHIFT in your events already does seem to do the trick. Am I missing something?

    Edit: ah I see, there's an issue with the whirlwinds now. Could be fixed by raising the jump strength for example instead of changing gravity direction.

    In addition to that I'd like to suggest only using two keys (apart from the arrow keys) for this. One attacks, the other one jumps and glides. Talking would be done by pressing up arrow. I'd love to have X and C as action keys, as opposed to X and Z btw. It's a keyboard layout thing. Imagine trying to control your character on a keyboard where the Z and Y keys are switched (as they are on many european keyboards, see wiki).

    I'd also like to suggest disallowing bunny hopping and making use of jump sustain for variable jump height.

    -Score doesn't carry over between layouts

    When you run the game in debug mode you can see that the score is actually carried over. Yet the text shows 0. What also striked me as weird is that I do get points for killing enemies, as one can see in the debugger, but again it's not shown in the text.

    Ultimately I noticed that your ITEMS event sheet was doing it's own thing, yet changing the ScoreText text object over again. Therefore it appears faulty. I think you were testing something out with that event sheet? Just exclude it and it will work properly.

    And again I have to say very promising project. Looking forward to future updates! Hope my comments help a bit.

  • > 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.

  • 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!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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