ORIGAMI

2D local multiplayer platformer | platform : PC | engine: Unity | language : C# | role: design, coding, animation | team size: 3

Origami is a 2D local multiplayer platformer, set in the Japanese paper world of origami art. On each level, the players cooperate with each other to dispose of the paper rubbish. To achieve their goal, they must coordinate their actions and use strategies to overcome obstacles that come across their paths.

1/8
PROJECT DETAILS​
My contributions:
  • Created overall game design (co-op)

  • Created overall visual design (co-op)

  • Planned and executed game play-testing (co-op)

  • Helped with debugging several issues along the way (co-op)

  • Created stop motion animations

    • Photographed stills for animation frames

    • Post processed photographs using Photoshop

    • Created key-frame animations in Unity

    • Created animation state machines using Unity Mecanim

    • Coded logic for animation in Unity

  • Implemented game-play logic for player characters

​​

Player-Centric Design Process

 

We considered the player’s existing biases and designed around them.

 

When players saw the rabbit holding the umbrella, we got feedback that players expected the rabbit to be able to ride the updraft. We added this as a feature to better match the affordances even though it invalidated co-op play in certain levels because technically the rabbit could fly on its own as a plane.

 

The reason the turtle and the umbrella are immune to water also stays consistent with the affordances and expectations we imagined the player would have. Even the speed of the turtle is made slower in comparison to the rabbit to make it feel more realistic and heavier. We repeated the question “What would the player think?” when designing the abilities of each character and environment piece.

 

We were also acutely aware of visual clarity. We considered where and what a player would focus on when looking at a level. We used different values, line densities and colors in order to lead the player’s eyes. More important things such as the ball and characters had stronger saturation to make them pop out more. To communicate to the player that the ball has to go into the round goal, we made the colors match and added rotation animation to the goal to make it more important.

 

We considered the player’s learning and progression in level design. We slowly introduced mechanics as the player progresses through levels. Earlier levels do not actually require morphing. We emphasize heavily on co-op from the get go to drive in the idea that players have to work together.

Operational Logistics

 

  • Camera - No.

    • We use a fixed camera which shows the whole screen.

    • We wanted to avoid camera-panning situations when players move too far apart.

  • Collision - Yes

    • We used multiple types: collision, triggers, distance check, AABB collision

    • Most objects have colliders on them.

    • Players will collide into each other, so they can push each other around and stand on each other to clear levels.

    • During deaths, collider boxes are switched off to emulate drowning etc.

    • Also, in certain special states such as the rabbit carrying the umbrella, we also have to switch off one of the two colliders to prevent the physics engine.

  • Control - Yes

    • Controls are set up for both keyboard and Nintendo switch controllers

  • Entity-State - Yes

    • Each player can morph between being an animal and an inanimate object

    • As an animal, they can move around.

    • Rabbit can jump, is grounded, die.

  • Game Mode - No

    • Title screens and the credit screens are built into the levels themselves instead of being a separate game mode

  • Linking - Yes

    • Each level is linked to the next playable level

    • The ball is visually linked to the vortex/hole by virtue of being the same color

  • Persistence - Yes

    • Minimal: The character that dies will be reset, but the other player’s position will continue to persist.

    • All changes will be undone when reloading the game.

  • Physics - yes

    • ALOT

    • As far as we could, we wanted to make everything physics based.

    • Pushing the ball, jumping, riding an updraft, falling, etc are all physics based.

    • The plane’s floating feel is made by decreasing the gravity acting on the rigidbody.

    • Left and right movement is not physics based. We tried but it was too difficult to add a force and get the objects to stop perfectly to the left and right. We nearly rewrote the physics engine but decided to just translate things instead.

  • Progression - yes

    • To the player: They have to complete the current level to move to the next level

    • We added a secret feature for ourselves where you can press ‘tab’ to advance to the next level. This is useful for us debugging or for showcasing certain levels.

  • Recombinatory - yes

    • All level environments are build up from smaller prefabs

  • Resource - No

    • Players do not have to manage any resources, not even number of lives.

    • The number of game objects does not change (other than cosmetic value on raindrops)

  • Selection - No

  • Spatial Matching - Yes

  • Temporal Matching - Yes

    • The re-spawn and morphing logic are based on their respective delay and animation timers.

© 2018 by Bianka Kovacs