Untitled Adventure Platformer Conceptualization

Good morning!

This isn't much, but a concept for the sort of platformer I'd like to make. I know everyone is making platformers, platformers, platformers, but I do love them myself, so I'm going to try for a sort of cross between Super Metroid (mobility, exploration, atmosphere) and Another World (survival, story and character).

It's not in TimeDelta mode yet, mostly because I'm not sure where to use it, or how to adjust my parameters without just using trial and error so they work they way I want them to. That and the code is pretty sloppy. Still, if you can run it at a vsync'd rate reliably, feedback/ideas would be cool. If you want to stea.. I mean, critique the code, I can upload the cap.

I plan to add a large sequence of animations which change depending on crouched height, as well as a fully animated world. Right now it has absolutely no graphics at all. Not settled on a style yet. But yes, the player character will be a man, not a faceless grey robot. Without further ado,

((I don't know why or how people keep hunting this down (perhaps it's webcrawlers), but it's old and quite terrible, so I'm removing the link.))

<img src="http://img.photobucket.com/albums/v325/mwahaha/cthulhu/movetest0d2009-05-1305-01-38-54.png" border="0" />

Bonus! Ambient music beta: <a rel="nofollow" href="http://www.box.net/shared/uknkz6koyj">http://www.box.net/shared/uknkz6koyj</a>

I'm afraid I really don't understand your movement. As near as I can tell, hanging off of ledges by the bits that stick out on the player's character is the only way to advance, which just looks odd to me. As it is now it just looks rather strange hanging by a ledge from a floating appendage that's separated from the main body... or by any part of your body other than your feet, really.

The acceleration and jumping seem rather off, as well. Running back and forth on the same stretch of flat ground yields different results... sometimes the character picks up a lot of speed, sometimes he doesn't. Sometimes a jump is completed with full momentum, and sometimes the momentum is lost halfway through, cutting the jump short.

The collision with the red flag object at the end of the level is pretty inconsistent as well. I assume that you're supposed to change direction in order to somehow chase the thing away, which I did eventually, but only through much trial and error. The rules just weren't very apparent, nor consistent, and they need to be at least one of those to work.

It also crashed the first time I got to the second level, when the physics balls fall into the pool, because there are too many physics collisions for my computer to handle. But the second time I hit Ctrl-X really fast to get rid of them. And I guess your need to get your TimeDeltas into the game because I can't even jump high enough to get to the pool. The character just makes a puny little hop that doesn't even come close to the first ledge.

It's going to take a lot of work to turn this into a solid game, and all I can say is keep at it.

Interesting! Just the sort of feedback I was hoping for. Thanks deadeye, you're the best.

As for the appendages, this is just the bounding box, I guess I should have explained the idea a little. I've got to rewrite everything completely to include TimeDelta, and at that point I think I will integrate them fully - they were more of an accident... but essentially, it's to allow the player multiple stages of 'hanging'. There must be a better way to do it, but I figure once I get a sprite animated and overlayed (these objects hidden) it should make more sense - stepping up, grabbing the ledges, etc. I'm actually lying to myself, because it just won't work. The player's lower half needs to pull up, after hanging on with the upper half, but I can't have both objects with the platform movement, because one is used for testing, etc, and it is just a big sorry mess of my not being a programmer.

... The red flag was also a complete accident, but I thought the movement was predictable. I guess it's sort of complicated, and would need again the animations to be present to understand how your character is moving... but, I could just make it simpler. It's basically, tap left, then right again, but that doesn't really make much sense.

edit: hah, yes, I see, it's doing all sorts of crazy things. Hey, that's a feature..!

Sorry about the physics objects overload, it would have been a cruel thing to crash your whole computer. I was thinking about them last night; this was just for my own amusement, to make a ball pit of sorts, but it also led me to discover various bugs and other methods of creating the effect I want. Basically, in the next re-write there will be no active physics objects until the player splashes them into the air, at which point they are purely cosmetic (and will have sprites to look more like splashes/droplets depending on their upward velocity). I see no reason to have fully simulated crap if it doesn't look right and isn't actually contributing anything but lag most the time, so presumably faking cosmetic stuff is where it's at.

I agree, it is completely unusable at the moment, but it did allow me to get my own thoughts in order. The movement was the main test, everything else basically... crap thrown in to have something to do..? Very sloppily. Next writing, I think I'll concentrate on getting movement working exactly how I want it, instead of a weak approximation. At the moment, it's pretty poorly conceived... movement, acceleration and jump strength are all affected by crouched height, the strongest apparent effect being air x velocity, which is more or less halved if the player is standing. It seems to work well for me if the player knows they must crouch to make a distant jump, but without knowing that I guess it's kind of lame.

Run speed and acceleration increases as the player reaches a height of 75 (100 and 50 being standing/fully crouched) - cosmetically, I thought it added a sort of 'bumbling' effect, but it makes more sense to have acceleration constant and only change the movement speed. The levels aren't meant to be extremely challenging; a lack of TimeDelta may be the reason for its present failing. I really dread implementing it, because from previously setting the speed to an exact value using an equation, it becomes guessing, adding amounts based on some secret hidden decimal...

use fixed rate then.

No... never!

Since deadeye doesn't seem to like my per-pixel bounding box sprite having protrusions, I can go back to using a simple box object* as my platform movement object, and instead of having the bounding sprite catch ledges, do something similar to his ladders in Platform School. If I have an automatic step-up (hopefully better than the one in the present demo, which is already outdated as it is) then the short distance to "climb" will just be a short, invisible ladder. It will require changing the crouched height so as to pull the legs up with the body/arms still hanging onto the side of the ledge. When the legs reach a certain height, it will then do the step-up. Which would presumably be animated properly at the proper crouched height.

It's all really too complicated; I can think of the gameplay I want, I just don't know the best or most efficient way to implement it. Right now this would also require multiple conditions depending on if the player is pressing in the direction of the cliff they're climbing (releasing the key should make the player drop back to a hang), and animating in an entirely different way depending on if the player faces the other direction while hanging... and allowing an outward wall jump if they are. The list really goes on, and with all the movement I have in mind, the number of animations required (since it's just going to be sprites..) is through the roof, but I have ways of dealing with that, so we will see.

<img src="http://img.photobucket.com/albums/v325/mwahaha/cthulhu/hanging-concept.png">

* I'd probably use a box sprite anyway; box objects don't seem to have 'overlaps at offset'.

[quote:11de63j1]movement, acceleration and jump strength are all affected by crouched height, the strongest apparent effect being air x velocity, which is more or less halved if the player is standing

Ah! I see now... and yes, it seems much, much more consistent when you know the rules .

At any rate, I hope I didn't offend with my criticisms. I was just trying to give honest feedback.

Also, I guess you were using the platform behavior? If so, there's no need to TimeDelta it, it's already TimeDelta-ed. It's the custom acceleration and such that you added with events (and the fact that you said you need to use TimeDelta) which lead me to believe this was a completely custom movement.

You only really need to use TimeDelta if you're manually moving objects around by setting their x/y, without a behavior.

I'm totally new to developing with Construct but here's my constructive criticism.

I liked it a bit, even with the placeholder graphics. Honestly, the visual style it has now is kind of simplistically cool. Reminds me of some little jumper-bot or piston-bot or something going through a factory. I could actually see a game with similar mechanics and a big puzzle solving aspect being a cool indie game.

I really liked how you had the character automatically jumping up the small increases in height. I found it even cooler when I jumped into the ball pit, pushed them all to the right, and when I pushed them all back to the left they sort of stacked up a bit and the character did the same small autojumps up the stacked balls and out of the pit. Not sure if you meant that, but slick. The physics didn't slow down my laptop at all, but it's only a couple years old.

The movement pacing was a little odd, and you seemed to move a lot faster crouched, which didn't make sense to me, was wondering the rationale for that. Also the inching to jump ledge to ledge was a bit tedious, but if the puzzles or levels were designed around it, I could see it being forgivable.

Seems like it might be hard for you to animate the climbing up from hanging on ledges with the solid bits. What's your plan for that?

Deadeye, not at all, though I appreciate your being humble. It was a useful honesty, because now, for example, I know that in a final game I'd have to demonstrate to the player that crouched jumping is much more useful than a standing jump. I could animate the player to crouch before every jump, and have them all the same strength, but I felt like including that control. Have you ever tried jumping from a standing position? I can barely do it, heh. But it could be useful for hopping off ledges, etc. As for TimeDelta, I'll double check my events to make sure. For some reason I put "every 10 milliseconds" on a lot of automated events, only using always (every tick) on events that change the value of some variable, such as max speed or jump strength, based on some equation. I don't know what's best performance-wise, though.

revolther - that's actually an interesting idea; simplistic robot, with little latches running about dodging things. The fun part in a game like that would be programming all sorts of hazards to avoid. The autojump in this just works, intrinsically, to allow the player to exit the pool. It's pretty basic: if there's a box in front of the player's feet, and that direction is being pressed, jump. In that test build I think you can actually hold left against the far, low wall in the second level and just hop indefinitely, getting nowhere.

I've changed it so that isn't possible (by raising the bottom of the boxes so they aren't detected), but for example in the pool the reason it works is because after the first hop, the upper protrusion catches the top of that block, which makes the player object think it's on the ground, so it still sees the box, and hops again. It also really relies on the stepped nature of the lower bounding box to catch and hop again if the first jump falls short. I like it, but I'm not sure how to integrate it into a new hang / climb system; maybe it will just work, I don't know yet.

Much of the world interaction requires a good bit of meditation and deliberation on my part to make sure it all works together right. It's sort of daunting, I don't know. I'll probably just work on graphics for a while and then come back to working on the code, etc. I've tried different variations of speeds dependent on crouched height; I can't seem to find something that I like, and since every one thing affects the next thing, it's sort of a balancing act. But I'm not too worried, because it's mostly a cosmetic thing, as I don't plan on making the game very hard - not a lot of deadly enemies or pitfalls, mostly just exploration.

The animation should be interesting. It keeps me up at night. I plan to divide the player into two segments, upper and lower, which animate independently... if you've ever played Quake3, players in that are animated with upper, lower and head - I might separate the head myself - which all animate independently, even though they aren't using full body skeletal animation. Technically, they are, but only the three bones. Maybe I'll use Construct's bone system to connect some of the parts? I don't know, I guess I'll find out when I get there, haha.

In the meantime I've got a couple simpler ideas. To start, I think I'll try to make a platformer with climbing and hanging that doesn't use the segmented body or crouched height stuff; that's what's making this other one so complicated to animate, just thinking about it.

Sorry for the novel. It's easy to go on and on about something like this...