[SemiSane] ...

edited in Questions and Answers
I idea no have I'm what doing.

So that I while figure out, this.

image

(aiming to post something every day, 6 days a week. even if it's, like, a scribble or a screenshot or something insignificant.)

Comments

  • Elyaradine said:
    So that I while figure out, this.
    This shall be forever imortalised! :D Also, he needs a monacle, even if it is just hanging from a pocket or something (do straight-jackets need pockets? YES!)
  • edited
    Monocle monkey says YES! :D

    I still don't know what I want to do, but I felt like doing some 2D animation, because I haven't done character animation in aaaaaages. So... maybe the game's going to have combat in it? (Maybe not? :P) Either way, scribbling animation is fun!

    image
    (Please wait for it to load :) )

    I know I'm going to try doing some kind of 2D sprite anim stuff, whatever it is. Been wanting to try that out, but up 'til now it hasn't been a priority to go and learn that yet. Having a look at Orthello; may look at SpriteManager later (whatever version the free one is). So, 2D platformer, some kind of asylum, and LSD-induced post-process shaders that somehow link up to the game mechanic/narrative that I'm yet to come up with.
  • That large left eye already look like a monacle :P

    Honestly though, nice work :) I guess I need to jump into practicing 2D animation too, been too daunted by it to even start something...
  • Silly little update. Finally got 2D working in Unity. :)

    I think I'm going to aim smallish (and artish) and just do a prototype of a platformer for now. :) It'll be fun to do the animations, and getting controls going that feel really tight/responsive is tricky enough. I think if I get that feeling really good, I can throw other stuff at it and see what happens... ^_^

    image
  • Woot, got some tiles I can lay out for my platforms, and got player controls somewhat working. Took a while for me to figure out why I couldn't detect whether my player was on the ground, but eventually found that moving my pivot to the centre of the sprite rather than having it at its feet seemed to get my raycasting behaving better.

    Also, was doing stuff using axes (horizontal, vertical) rather than in button down/up, because I didn't know I could use the axes in the same way. Fail. :P Not going to do my animated sprites until I'm happy with the way the controls feel, in case the move speed changes, and that's taking a fair amount of tweaking...
  • edited
    Yeah, I'll put up a web player tonight. :)

    [edit] http://pixofile.co.za/jonathan/prototype/WebPlayer.html (~100KB)

    I'm still not happy with the feel; jumping feels kinda floaty. I'd like to wall jump too.

    [edit] I think it feels better. :)
  • edited
    Added some wall jumping, and to be able to smash downwards if you press down while in the air. I like how it feels. :)

    http://pixofile.co.za/jonathan/prototype/WebPlayer.html

    Wanna see how much awesome I can cram into just this, with art and animation. If I get something that can keep me entertained for a while even though there's actually nothing there to play yet (no goals, no narrative)... then I'm happy. :P
  • The guy is still quite floaty. Doesn't seem to be accelerating down? much?

    I like wall jumping. I think the wall jumping could work even when you are pushing into a wall. (Super Meat Boy pushes out from the wall when you jump regardless of whether you are controlling him to jump towards or away from a wall.)
  • Hehe that was cool! I had a few minutes of fun just jumping around.
    Like BlackShips I also found it floaty like. I could also jump when falling, not near a wall or on the ground. I'm also having very choppy playback, something that may or may not be related to the crappy quality of my computer, or just the way the movement is being calculated, not sure.

    Juice is fun man. The past week I've been adding juice into the Game at work, and it's amazing how fading music in and out over scenes adds so much!
    Keep on keepin' on, can't wait to see him do something crazy!

    Are you using sprite manager? or UIToolkit?

  • edited
    Thanks for trying it out, guys. :)

    Upped the gravity. :) Tried adding the possibility of wall jumping the same wall while moving into the wall... which works nicely, but it breaks the alternate jumping thing quite a lot. Wondering how to approach that. I think I prefer the older way. It's more manual (switching x-direction to get it right), but it feels as if I'm in control, rather than having stuff done for me...?

    http://pixofile.co.za/jonathan/prototype/proto02/WebPlayer.html

    I'm using SpriteManager. :)
  • edited
    Thought about the wall jumping some more, and I think I got them both to work now. :) So now, if you're holding up and just pressing left and right as you go up the vertical passage, you jump between the walls. If you press against a wall and press up, then you do a little jump, so you could conceivably climb a single wall that way too (like what I remember from Super Meat Boy). And if you just hold against a wall, you slow your fall.

    http://pixofile.co.za/jonathan/prototype/proto03/WebPlayer.html

    [edit] btw, had a quick look in the profiler to check for a bit of stuttering I was experiencing too, but when I turn off vsync, cpu is about 0.25ms and gpu is about 1ms. If it's lagging, I don't think it's me... (although it totally could be, with my artist coding... :P)
  • edited
    Cool character design :)

    The character's controls are responsive, which is great.

    I love that you can press down while in the air to move down. (I did the same thing in my platformer, Demolish. It makes it easier to avoid spikes hanging from the ceiling or flying enemies.)

    Initially the wall jumping felt a bit messy. But then I tried it in the narrow space and it works nicely.


    Some suggestions:

    Make gravity slightly stronger.

    The character's jump starts too fast (e.g. up force too strong).
    Try this (what I've done in platformers before): delay the affect of gravity for about 2 seconds when the character jumps. So gravity only starts pushing him down when he's moved up for about 2 seconds. Do the same when he wall jumps.

    For now (while there's no animation) add a particle effect on the wall when he wall jumps. This will let you know it was successful, because sometimes you move away from the wall before you actually pressed the up button, so then you fall down.

    In the game "Batman" on the NES the wall jumping felt good. It was less controllable than your game. But they had a slight pause just before the character bounced off the wall. Try it and see what it feels like. The pause was an additional confirmation that you performed the wall jump successfully, and maybe it also gave you time to react to which direction you want to go next.

  • I look forward to trying this it when I'm back by my computer! (I'm out of town)

    I remember playing super meat boy's prototype on the basement collection and I always found that wall jump to be really dodge, cos it required me to press into the wall, press jump, then immediately press away from the wall or I'd jump back into the wall. It didn't feel right.

    Wall jumping is an art to get to something you don't even think about, I think league of evil has a really good wall jump where it sticks to the wall when you press against it, then when you jump off it, you get control back at the apex of the jump do you don't immediately have to release the into the wall to jump away.
  • edited
    Oh man, such awesome feedback! Thanks Diorgo!

    I just tried out the web player build, and it is suuuuper floaty! :( It's definitely not what I intended. (I changed my fixedupdate to be around 100x a second, which broke my physics elsewhere, so I rescaled all my numbers accordingly. But the web player one feels as if it's back to when it was unscaled. :/)

    Here's a Windows build that seems to be much more accurate to what I prepared. I dunno why the web player ends up being so different...

    I'll try out the other stuff later this week. :)
  • edited
    So it seems that my physics is framerate-dependent. :P The web player's locked to around 50-60fps, whereas locally the (incorrect) built-in fps counter was at around 4500 and the (much more correct) Fraps was around 950.

    Each Update(), I grab the rigidbody's velocity and assign it to a "newVelocity" Vector3. I then check for various conditions based on player input, and assign this newVelocity some new values, like making its y-velocity 14 for a jump.

    Then, in FixedUpdate(), I assign this newVelocity to the rigidbody's velocity. This is quite clearly where things break, but I'm busy fighting with why. :(

    [edit] Wow, that's a lot of code I'm gonna have to shuffle around... but at least I think I know what's wrong. :)
  • Hey @Elyaradine, I'm just taking a stab in the dark here as I don't know how you have implemented all your code, but can't you just multiply the jump value(14) by Time.deltaTime. That way it becomes frame rate independant?

    Keep us posted :)
  • edited
    Okay, had to do a whole lot of refactoring and crap. It's not quite the same as it was before (I had to jiggle a lot of numbers to try and squeeze the same feel out of it, and ultimately ended up with something different), but at least it's independent of framerate.

    I had to sort out how my logic was working. My player's currently using a non-kinematic rigidbody, which I guess is where the problem was. If I set the velocity, I have to do it instantaneously, so it happens in Update. If I set a force (which is necessary for all horizontal movement, because acceleration is applied there), I have to set a flag in Update, and do the applying of the force in FixedUpdate.

    It feels... more complicated than it should be. :(

    Anyhow, it took a while, so I haven't done anything new. Going to try and integrate Diorgo's advice next. And then maybe lay out the beginnings of a level, so that I've actually got some ~30 seconds or so of gameplay. :P Might have to rope in some friends to do some environment work and/or animations for me -- I've got a course I'm enrolled for that starts on Friday, so I won't be able to do much, if anything, from then on. Been fun pretending to be a programmer for a bit though. :D

    http://pixofile.co.za/jonathan/prototype/proto03/WebPlayer.html

    I feel as if there are tiny jolts of unexpected behaviour, and I'm not why. Perhaps someone who's playing can figure out a pattern? :P
  • edited
    I showed Claudio my game, and he suggested some other cool stuff, like ledge hanging, and making the horizontal velocity drop off a lot more quickly when you let go of a horizontal direction while in the air. Thing is, those are more unrealistic kinds of physics...

    so...

    ...I've been redoing all the physics stuff, this time without the use of Unity's physics (because that assumes realism, which isn't really the goal here). Helped that the course I was enrolled in got pushed back to this week (so it starts tomorrow! so excited!).

    The up-side is that I've got my movement working again, along with some super basic collisions (which is fine given that my work'd made up of blocks anyway). Still gotta get wall-jumping and stuff back in, and I'd like much prettier/juicier particle effects. I'm also somehow back to being framerate dependent somehow, so no web player build, but I'm tired now. :)

    With the course starting tomorrow though, I may just have to revert to the old physics, and whip up a quickish level just to demo on Tuesday.
  • Well, this is all I have time for. :) But I'm really happy with it! :D The web player struggles a little I find, but it's not too bad.

    image
    http://pixofile.co.za/jonathan/prototype/proto04/WebPlayer.html (~130KB)

    Controls: Arrow keys.
    Thanked by 1Tuism
  • edited
    Cool game, I liked how the jumping ended up feeling. Jumping to the block with a small gap above it infuriated me, either I missed the block and fell off or I got into the small gap and proceeded to knock my head and fall into the gap afterward. It made me angry enough that I HAD to finish it, and then finally the orange block of the deadliest dead-end appeared. What happened to his animations from the previous build?
  • edited
    Oops. I pretty much had to write the whole thing from scratch, and ended up forgetting about the animations. >_<

    Thanks for playing! :D (Dunno if you saw that, if you're in the air, you can press down to do this diving type thing, which you can use to break the orange blocks. It could really use an effect...)

    Is the gap bit something you'd change?
  • I thought the gap was awesome, and also found the controls easy to learn, in terms of figuring out the diving. I think it's coming along nicely. Personally I'd make the delay on the camera less, but that's frivolous.
    Animations?! Can't wait to see them!
  • Right, I had forgotten you could dive down. Yeah I agree with Pomb, I'd keep it in, I would just extend the bottom very slightly past the roof so that players can jump off the edge and not hit their heads. I had a similar situation (with a low roof before a big jump) in the game we made at the global game jam that made getting to the next platform (and next level) practically impossible for players. Yours isn't nearly as bad though and it probably goes with the SuperMeatBoy feel you have going. :)
  • This has really come along!

    There was that one part where I was between a floor and a ceiling and had to jump over a hole and kept hitting my head and failing. That's not so mu a problem with the platformer logic and an unfun piece of the level.

    Still not sure if the wall jumping is quite as forgiving as it is in Super Meat Boy. But it works.
  • Cool!! :D

    I really like the way it moves, it mostly feels good :) I was at first not sure about the bounce after you land from the dive attack, but it didn't seem like a problem after a while. The wall jump feels simple, although to me the point of a wall jump would be to jump to an opposite wall instead of the same wall - right now it's next to impossible for me to jump to the opposite wall so he can climb with just one surface (ie no need for tunnels up to climb higher quickly). If that's intended then that's cool :)
  • edited
    Still not sure if the wall jumping is quite as forgiving as it is in Super Meat Boy. But it works.
    Yeah, I'm finding that sometimes I expect to be able to wall jump, but then... don't. I'm not sure how to fix that, except by adding another couple of collision points/raycasts to detect wall jumps further away.
    right now it's next to impossible for me to jump to the opposite wall so he can climb with just one surface
    That was definitely supposed to be possible. :( I'll take a look at that when I get back to this. (Got two anatomy sculpts to do, and want to polish up that document on game art tech, by Friday, and both of those are higher priority right now. :) )

    The original concept, which I intend to get back to, was that if you hopped up a single wall, you'd be fairly slow, but it'd still be possible to do; whereas if you hopped on alternate walls, you'd be able to shoot upwards quite quickly. I think I achieved it in one of the earlier prototypes, but lost it again when I rewrote the thing not to use Unity physics. Should just be a case of massaging some numbers though, once I've figured out the reason the wall jumps aren't triggering as easily as I'd like.

    [edit] Actually, after chatting with Diorgo, I think I... kinda approached it wrong again, which limits me a lot in terms of collision detection. Gonna think about that while I'm artingstuffs. <_<
  • Got to play this a couple of minutes ago, and much like everyone else, I'm inclined to comment on the gap area. :P

    In terms of level design, the roof thing is cool enough (making sure that you get a good jump arc without hitting your head can be considered a challenge in itself), but you're combining it with the first player death risk in the game, making it a bit of a double challenge with a very steep penalty.

    I would suggest either keeping the bottomless pit of doom there *OR* the "hit your head on the roof" jumping problem, but don't cluster both of them. The former is fine and classic, and the latter could be worked with if you made some particular blocks "non-sticky" walls (since it's always easier to design a level when you can insert more restrictions on player mobility).
    Thanked by 1Elyaradine
  • edited
    Er... quick summary of the stuff I did for this, and what I learnt.
    • Wasn't immediately inspired by the theme, so went off to do some research (~30 minutes of trawling Google, reading Wikipedia, looking up material about insanity and looking for something I felt would be fun to make as well as fun to play.

    • When research turned up fairly empty (a game about lobotomy sounded kind of interesting, but didn't sound like much fun past the first few seconds), I resorted to scribbling and thumbnailing for inspiration. After several failed/uninspiring sketches, I posted that dude in the first post.

    • Well, that's nice, but no game yet. Well, screw that, I've never made a 2D platformer before, and I've heard it's quite hard to get the feel of it to be satisfying, so I might as well give it a bash. (The other thing I've been wanting to make is a game that conveys the sublime feeling of flight, but beyond that feeling I couldn't think of any goals that'd make it a decent game.)

    • Prototype movement. Ask for feedback. Fix. Repeat.
    Stuff I learnt
    • Really handy to expose all of your physics parameters in the inspector for tweaking numbers while the game's running.
    • Using Unity's physics is messy, having to split physics and input between Update and FixedUpdate. For a *simple* game with physics that doesn't need realistic behaviour, you get much better control out of doing the physics yourself and doing everything in Update with deltaTime. It seems easier to do unrealistic movements like air control/drag, wall grabbing and ledge hanging.
    • You can still use raycasts for your collision.
    • Test your web player build before you upload it. :P (Also, I have a feeling people are more likely to test a web player build, where they just click a link and start playing, as opposed to having to download something they need to save somewhere or install. In terms of Unity, with a project that had minimal/no art, it was also the difference between a 120KB download and a 30MB executable.)
    • Cap your framerate and see if your physics breaks. I found a lot of instances where my physics was highly dependent on framerate.
    • It seems that if you're happy with the movement itself, where it's fairly fun just to run around and bounce around a room that doesn't have much in it, it frees you up to be able to make levels more quickly. You have to do the movement before you plan the level though, or you risk redoing a lot of work.
    • Try to get the player to face only one new challenge at a time.
    I'd like to come back to this later, make it a fuller, finished level, and flesh out the visuals into something droolworthy. Rayman type stuff? Irunno!
  • edited
    Can I ask you how you used the raycasts. I experimented with raycasts for collision detection a while back and found that a simple setup where I used four rays(left,right,top,bottom) to check collisions didn't work so well when moving diagonally. Go figure. :P

    I haven't worked on that stuff for a while but I was just wondering how you used your rays because your game(which is quite cool btw :)) don't have the same problems mine had.
  • I was checking for intersections with any of my collision boxes. I'd have collision boxes on the bottom left and bottom right (so that you could stand on the very edge of a ledge before falling), left and right (which I used for normal collision checking against walls), left top and right top (which were used for detecting wall hanging), and top left and top right (for whether I could bump my head.

    So, basically, I was doing a lot more checks than I'm guessing you were. :) Apparently raycasts are really cheap, but Diorgo was also suggesting only checking certain ones if I'm moving in certain directions. e.g. if I'm moving right, I probably don't need to do collision detection for my left side; you could thus probably cut your checks down to half or less.

    I was checking for intersections by having my character a little in front of the environment, and firing raycasts backwards into the environment... but in retrospect, it'd be better still to do the raycasts up/down/left/right, which works better for things like low framerate collision, and I imagine also for various movement-based special abilities.
  • edited
    You were definetly doing more checks than me. :)

    I'm not sure I understand what you were doing though. Did each of your (roughly 8 ) collision boxes have a up/down/left/right raycast? Or am I missing something else? Also, you say that your character was a little in front of the enviroment, do you mean that you would process the raycast after you passed a certain point to check if you collided with that point? Wouldn't that create a situation where you could get stuck in walls?

    Thanks for answering my questions. :)
  • edited
    No, each collision box was doing one raycast, firing backwards (i.e. in the z-direction) to hit the environment. (I wasn't really thinking of real raycasting at the time; I actually just wanted to check for 2D intersections, and this was the only way I could think of.)

    I was saying in retrospect the left collision box should be casting left, the right should be casting right, etc.

    The collision actually checks from the collision box + the character's velocity though. So unless your frame rate is super low, you shouldn't get stuck in anything. (But currently, if the frame rate is somewhat low and the character is moving sufficiently fast, he'll come to a stop before he actually reaches the wall... although at that point his velocity then becomes smaller, so then he'd be able to move toward the wall again. If I were doing the raycast in the correct direction, I could move the player an exact distance to where the collision would have taken place, which would be much smoother.)

    I hope that makes sense...? :) I can probably just show you my code when I get home. :) (I can't share the project though, because I'm using SM2, which isn't free.)
  • I understand now :) When you forget about the z direction "in front of" can only mean left or right. But I get what you were saying now. It's actually an "easy" solution for the problems I was facing. I wil have to think on this some more :)

    I leave you alone now so you can get back to drawing all the pretty things :P
Sign In or Register to comment.