The Tale of Shu

Description
The Tale of Shu is a 2D single player platformer adventure game where the main character, a lovable green ball named Shu, must explore the world around him and solve puzzles to navigate his ever confusing terrain. Through his exploration, Shu finds the world around him is becoming corrupt and polluted by a mysterious presence. Will our hero be able to save his world before it is too late?

Controls
"A" and "D" - Roll left and right
"S" - Squish down
"Space bar" - Jump
"W" - Climb
"E" - Menu Select
"Escape" - Quit Level

What went right? 
Our goal going into this was to create a fun but challenging movement based platformer and we think that is exactly what was produced. Movement turned out better than expected after putting effort into making the movement fluid. In the art department, the overall design for each object worked out better than planned, especially since we tried to draw everything by hand to make it original. We also created some unique sounds that were varied and suitable for each scenario. Overall, we were able to attend team meetings and online chats to keep us on track when implementing mechanics and assets. Although we did fall behind in some areas due to scheduling conflicts, we managed to reschedule appropriately in which we could all condense our original concepts into a concise finished product.

What worked better than we expected? 
We were surprised how smooth the game felt after being put together. The momentum of Shu is very fluid and the jumping physics worked out well. The movement animations for Shu also give that one extra layer of enjoyability to the simple act of moving around. It was our lead artist’s first time creating an animation frame by frame, and worked for the game’s movement mechanics. The implementation of the corruption effects turned out surprisingly well and really fit with our plan for the game’s story. It was also our sound designers first crack at making sounds for a game and we think that his work turned out really well. The lead coder also put a lot of work into writing the music. It often got stuck in our heads and worked really well with the theme of the game. We were slightly surprised with how the game came together for the final product. 

What went wrong/what problems did we face?
We really struggled with having the skeletons for our later levels line up with the level designs because there may have been a miscommunication between developing the design to the skeleton. We initially planned on developing 5 levels, but had to narrow it down to 3 due to time constraints, which was our first major change. Another major change was in our art design. We changed the “corruption” effect of the art from  a direction of smooth to pixelated, to the direction of a “glitch” effect in the art. We made this change because it was becoming too difficult to pixelate every frame that was necessary for the way we wanted to implement the art. One problem we encountered was that our methods for many of the mechanics in the game were very sub-optimal, with a lot of repeated code. The main example is the button/door systems that could’ve been assigned to a parent class with changeable variables. Our sound designer struggled to create quality sfx for certain sounds, so we turned to opengameart.org to overcome those issues. We also ran into some issues with our scheduling and the coordination between our art direction and level design. We found that our initial concepts and additional mechanics that we were designing were beginning to be too complex for the little time we had in order to finish our project. 

What did we learn?
While developing this game, we learned a lot about the flow of the game creation process. From a leadership standpoint, we learned how to run a team ensuring that all voices are heard. We also discovered that we could have had a more efficient system for our objects. We learned that not everything will be produced as imagined-we had to adjust appropriately. Luckily our team was able to adapt as necessary. We discovered that there are many different kinds of effects and textures available to use in certain art applications. With sounds, some were easier to make than others. We overcame these problems by using opengameart.org to outsource some of our sound effects. Two sounds that gave us the most struggle surprisingly, were the jump and bee sounds. Finally, we learned that a product being finished is better than it being perfect, and it was more complex to develop a game than originally anticipated.

Aidan Fyfe - Lead Designer
Trevor Gritz - Lead Coder and Composer
Gannon Andrews - Producer
Yumi Lamansky - Lead Artist
Steven Harms - Lead Sound and Designer

Some sounds taken from
https://opengameart.org/content/jumping-man-sounds
https://opengameart.org/content/soundpack-04
https://opengameart.org/content/single-bee-sound