Postmortem


The character is the soul of this game. Our goal is to make a ragdoll-ish character that is completely driven by Unity physics engine. Players can then take control of its different body parts to perform complex movements. To fit into our game, it needs to be able to walk, jump and run. Here are some development stages:

  • Decide to make this project in 2D or 3D

We actually want to make a full 3D project. However, due to rigidbody rotation in 3D is handled by quaternion - a supper cursed 4D Vector unit, a lot of weird bugs appear when I try to take control of it.

 

Whereas in the 2D world, I just have to modify the rotation angle in the Z axis to set rotation for all the limbs. In addition, our camera will only face one direction during the whole gameplay, so making the character in 2D is the easy winner.

See it in action:

3D Stickmanfail.m4v

  • Set up a basic stickman ragdoll

Thanks to Youtuber Zunity. I borrowed his basic setup of my ragdoll. Making An Standing Active RAGDOLL in Unity!

Basically the setup uses hinge joints to connect the total 10 body pieces of the ragdoll. To make it stand, the rigidbody of each body part is assigned as a variable of a new class called “muscle”. The muscle will rotate to its designated Z rotation in a gradual way by calling the muscle activation method inside the class.

I also created my own method to manually rotate the ragdoll’s limb by pressing different keys. The basic stickman is completed, and the result is very fun and interesting.

See it in action:

Ragdollsetup.m4v

  • Upgrade the ragdoll to a working character

The aesthetic changes dramatically after using Chloe’s sprite. Beside, I add some custom variables and methods to enable lean and jump. The character starts to take shape. However, the movement and animation is just bad.

See it in action:

Earlystagewalk.m4v

  • Dramatic improvement of the feet

One of the most frustrating problems I encounter is slippery issues. No matter how I tweak the gravity, mass and friction coefficient, character feet will slide and glitch when it is applying force to the ground. Since the forward movement of this character completely depends on the equal and opposite force that each foot is applied to the ground, it is crucial to solve the sliding problem in order to make a agile and responsive controller.

After trying so many approaches, I come up with a solution that when each foot is touching the ground, a temporal friction joint is connected between it and the ground.

Sometimes the counter-acting force is just not enough to support the character to run. So I decide to manually add some force which magnitude is proportional to its current speed pointing towards feet’s downward transform, creating an illusion that momentum adds up.

See it in action:

Frictionjoint.m4v

Running.m4v

  • Some Final Touches

After solving the feet problem, I Improved jump animation alot. Previously I was using a Coroutine to handle the jump animation. However, Coroutine does a good job on making animation that doesn't interact with physics, so I put jump animation to the Update method, and control it via real time key press. I also add a “Character detach” feature to the controller, where if the vertical impulse value is too large, the little girl on the shoulder will topple. Thus the player should pre-bend the knees before landing to prevent that from happening. It in a way forces the player to make up part of the jumping animation for me.


Future development

  • For future development we would like to address all of the feedback we received especially on both level design and visuals. As for level design, we would like to break up the levels into shorter segments that gradually increase in length and difficulty. This would ease the learning curve and also reward players more regularly. The idea of rewarding players is one whose importance is often overlooked. We would like our game to be both difficult yet somewhat encouraging at the same time. If players are unable to pass the first few seconds of the game with ease, it might dishearten them when thinking about the other 90% of it. As for visuals, we would like to add a soft shadow to the 2D sprites so they blend even better together with the 3D models. Another component that needs to be reworked is the dog, Poppy. Currently the animation speed is not matched to the movement speed so it looks more as though it is skating than walking. However, even more important than that is the need to make Poppy look as though it truly fits into the scene. At the moment the colliders on Poppy and lack of response to the environment make it seem like a moving box especially when compared to the very fluid physics based movements of the children. Creating more natural looking animations as well as creating more natural reactionary behavior to situations like going uphill or dangling over a ledge is high up on the to do list.

What we learned

  • This project reinforced the importance of learning how to adjust and adapt to new ideas. On our Notion page we have a handful of drastically different game experiences which we were unable to include in the end. We learned how to make the most with the work we already had completed, dial back on scope, but ramp up on quality. In the early stages of game development our group agreed on integrating both 2D and 3D assets. We learned through experimentation what the best practices were for creating in 2.5D. This allowed us to create a game that visually felt very cohesive. This decision to create in 2.5D was just one of many compromises our group came to. Lastly, we learned the importance of easing players into gameplay. We did have tutorial assets which we ran out time to add in. However, we now know that possibly even with those tutorial assets we would still need a more of a gradual introduction to the game. After sitting with a game for multiple weeks it can be hard to place yourself in the shoes of someone who has never touched or seen it before. Moving forward we will know to focus more heavily on that aspect.

Successes

  • Some of our biggest successes in the game revolve around the main character. Alex managed to create what we all think is a system of movement that’s really fun to control and play with, and in fact I’d go as far as to say more fun than what we were even hoping for in the design stages. We were originally planning something much more iterative on QWOP, but in the end we ended up with something distinct and that feels far more our own. 
  • We’re also all very happy with the art; integrating 3D assets into a 2D project worried us in a bunch of ways; whether the shaders we used would work, whether it would do weird things to the physics, whether it might just look strange. But it went surprisingly smoothly, and I think we’re all very happy with the result. I think we all feel the the art styles we chose complement each other well, and are pretty successful for the kind of game we want, as well as feeling nicely unified. 
  • Our time management was also relatively successful. Nicky was on top of planning and dividing out the tasks, and while there was still a bit of a crunch on the final day, it’s far less than I think most of us are used to, and the resulting game feels so much more complete for it. Nicky also set us up a really clear Notion page, that made it simple for all of us to see what tasks we still had to do, as well as what was involved in all of them.

Setbacks

  • Version control was, as ever, an issue for us. We decided to try out Unity Collaborate, but couldn’t get it working well; after that we defaulted to the standby of just sending things through Google Drive, which worked okay when it was just Unity packages we exported, but when it came time to transfer the whole project, we ran into errors that wouldn’t let one member open it. Eventually we managed to fix them, but it still caused us some problems.
  • The other biggest setback was probably the way the game evolved, with us constantly changing plans despite the short length of the project time. This was a problem both at the start in our planning phase, where it took us a week or so to even decide which of several ideas to finalize on, and then beyond that we went through a whole bunch of different iterations, making it really hard to keep the different parts of the design consistent. If the mechanics were different than what the designer had expected, the level design stopped working. Version control probably impacted this part too; since Alex was working on the character while Xander was assembling the level, both in different Unity files, Alex couldn't test the character on the final level until we finally managed to unify the versions, leaving not much time for playtesting. 

Get Afternoon Walk

Leave a comment

Log in with itch.io to leave a comment.