next »

[archgame]

Your post #34 was a great read and I really appreciated the diagrams and explanation on animation finite state machines. My partner just finished up the jump animations and I'm now tasked with coding in the beginning and ending jump states like you have diagrammed. Your post is super useful and I'm definitely going to be referring to it as I try and get the jump down in the coming week (I know what you mean, jumps are soo tricky to nail down and get that perfect feeling, it is kind of amazing when you think about how good the jumps in old N64 platformers feel, especially after trying to mimic it yourself).

Keep up the good work, this project looks fun and I'm excited to see where it is headed!

Also the level sketch and explanation was awesome, these forums could use more of those, more diagrams in general.

[lululuprimal]

Really like the art style here!

[gimymblert]

https://roystanross.wordpress.com/super-mario-64-hd/

check PM

[bkslsh]

Your post #34 was a great read and I really appreciated the diagrams and explanation on animation finite state machines. [...] Also the level sketch and explanation was awesome, these forums could use more of those, more diagrams in general.

Thanks, Archgame! It's good to hear what's useful to people. I always love following along with other devs' work and seeing the gory implementation details, too.

Really like the art style here!

Thank ya, lululuprimal. I have an arts background and have worked my way into the dev side, too, so the art is definitely one of my favorite parts of this process.

https://roystanross.wordpress.com/super-mario-64-hd/

Yes! Thanks, Gimym, I have been following that project for a while and was super excited to see he released a complete demo a couple weeks ago, but then it was taken down promptly by Nintendo's cease and desist. I was not quick enough with my download trigger finger to grab a copy before then, but I am glad a lucky few did.

Thanks also to all the lurkers who have taken a peek at my humble work in progress. It's so very motivating to be a part of a community like this! 

[gimymblert]

you can use it for evil too  like colonizing new planet and subdue their life form 
/(written I could use some smiley I don't use often  )

[bkslsh]

Today is the day I increase the % done icon! Woot! 20%!

As of this week, I have a basically functioning character controller and camera, and despite ongoing battles with random bugs, it looks halfway decent. Still not as smooth as I’d like, but it’s getting there. The other big one is a video of a gameplay demo. The music's pretty great (can't take any credit there, it's by my friend BBass), so I really wanted to get this up even though the animation's still rough and bugs blah blah blah –



I guess the camera moves too much, because Youtube offered to stabilize my video for me.  

Added a couple new features over the past week – a flagpole for climbing (which will be extended into climbing trees and vines later), and an actual level-end scenario! This was a big one. I defaulted back to the good old “grab the gold star” trope until I can think of something better. Excuse my low score, I should've grabbed some minerals first –



I also discovered the moving platforms I made earlier didn’t move the player correctly, and that took surprisingly long to fix. The platforms are moved by a script – and when they’re moved during a visual update they can temporarily overlap other colliders prior to the next physics update occurring. That causes problems when relying on ray casts and the controller’s isGrounded parameter, which don’t work as expected when colliders overlap. To work around this, in the character motor script, I keep track of the platform currently below the player and its current speed and direction. The character position is then offset by that amount before any player input is processed. This creates the effect of the player smoothly moving with the platform.



I keep telling myself done is better than perfect. I know there's a lot of polish to add, but I'm at least making progress. Plus once I have this basic framework implemented I can pretty much re-skin it into any style or theme of 3d platformer, which is kind of exciting to think about.

[archgame]

You should make the link to that youtube video a picture! My first time scanning the post I almost missed it.

I thought the gameplay looked nice, there wasn't anything popping out and distracting me from what was going on. The one thing I wish I could have seen during the demo was some camera movement. I'm specifically thinking about the first time your avatar fell to the planet surface, I feel like I would have tried to rotate the camera if I were to attempt jumping those platforms; maybe I'm just super conscious of this because I recently added two camera states to my game: one that follows (like you have) and one that allows the player to move the camera freely. Have you done any play testing yet?

How are you doing your climbing btw? I've recently implemented some ladders in my game and I simply reverse the jump, although this is less than smooth.

[bkslsh]

Thanks for the feedback, Archgame!

I thought the gameplay looked nice, there wasn't anything popping out and distracting me from what was going on. The one thing I wish I could have seen during the demo was some camera movement. I'm specifically thinking about the first time your avatar fell to the planet surface, I feel like I would have tried to rotate the camera if I were to attempt jumping those platforms; maybe I'm just super conscious of this because I recently added two camera states to my game: one that follows (like you have) and one that allows the player to move the camera freely. Have you done any play testing yet?

Yeah, I didn't really use the manual control of the camera much in the video. I've actually been rethinking my approach to the camera – instead of sticking so strictly to a behind-the-player view, I'm now trying to get closer to the Mario 64 style, where you can run in circles without the camera circling, too. The video on this page shows at 0:14 shows what I'm talking about – http://www.nintendo.com/games/detail/TOEiNDty4AHQngsUnC2Eyog0kBeitORN.

I have been avoiding play testing until I fix one more big bug... if you jump while moving forward against an obstacle, the collision prevents the upward motion from continuing. It leads to a lot of player frustration. But yes, play testing is next!

Climbing was more difficult to get right than I first expected, I'll do a whole post devoted to it...

[bkslsh]

Ah, climbing the flag pole – the satisfying conclusion to many a Mario level. Here's how I got it to work for Astroman. It seemed simple at first, but physics weirdness forced me to do some manual collision resolution...

• The flag pole mesh has a capsule collider and is tagged "Pole".
• When a collision occurs between the player and an object tagged pole, the player is flagged as being on a pole, and the pole's position is recorded. At first I simply restricted the player's position to the same x-z coordinates at which they collided with the pole. If they moved the right joystick they rotated around the pole's center point or adjusted their y position.
• But a situation kept occurring where the pole ended up going through the player's head. My interpretation is that because the graphics and physics updates run at different speeds, at the time the physics collision event is sent to the script, the player’s position (which is moved every graphics update frame) is intersecting with the pole’s collider. This leads to the pole appearing to overlap with the player, or in extreme cases appear to go through his head. (At least I think that's how it happened. Either way my astronaut ended up with a flagpole going through his head way too often.)

Ordinarily this overlap would be fixed in the next physics update and you’d never notice it visually, but because we’re intercepting this process when the character hits the pole, we have to correct for this collision ourselves. We are using two capsule colliders with known radii, so this isn't too complicated:

• The distance d from the player’s center P1 to the pole’s center P2 should be equal to the sum of their radii (shown as correctDistance in step 1 below).
• Calculate the amount we’re off from that distance as offset.
• In step 2, we find the direction in which to move the player, which can be found by subtracting the vector P1 from vector P2, shown as offsetVector.
• After normalizing the result, the offsetVector is scaled to the same magnitude as correctDistance.
• Adding the offsetVector to the player’s position moves him in the correct direction.
• Finally, the player is rotated to look toward the pole.

If anyone has any suggestions or improvements or alternate explanations for the flagpole-in-the-head problem, let me know!

[gimymblert]

- Add a pivot object at object heights when the object collide with the pole
- keep the pivot in the center of the pole
- parent in some way the player to the pivot
- rotate and move the pivot according to input, play animation accordingly