Sunday, December 2, 2018

Post-Mortem

As we finish the semester we can reflect on our game and see what we could have done better for next time:

1.    What went right / worked well or better than expected?

- Finishing all Tasks before deadlines. We had a committed group who wanted to ensure we all pull our weight and each member managed to finish their assigned tasks just in time. We had a good level of communication on Facebook. 
-Models/Textures. I believe we surprised ourselves at how well some of our assets came out, particularly after Zoe refined my models. The rendered screenshots by Alex with the textures by Georgia (and Zoe) look marvellous. In the end, we had a decent collection of finished and textured models.
-Team Co-operation. The team worked pleasantly together and any disagreements were able to be resolved in a civil and respectable manner. Group meeting attendance was good. 
-First Playtests. Despite many issues with Unity and our difficulty with our Pig mechanics, we were pleasantly surprised how quickly and smooth our first playable build which Alex put together worked. 

2.    What went wrong / didn’t really work?

-Last Minute Rushes. Our team had a bad habit of being finished at the last minute. While not necessarily because we started too late, perhaps we spent too long experimenting and fiddling around on certain things such as which style of camera angle we wanted. 
-Differences in art styles. While we agreed with how the game should look, we still had very different art styles that were a challenge to put together, but having a 2D art lead (Georgia) greatly helped in the consistency. 
-Inexperience in Maya and Problems with Git and Unity. I believe our team members should have been a bit more prepared in having up-to-date software at home, learning Maya skills such as exporting or asking for help sooner.  Because of our experience, we had to leave almost anything Unity related to Alex. 
-Picking a style of game that was challenging. We may have found it much easier with a more simpler style such as a platformer, however, our final version Yoink certainly challenged us and pushed us to learn new skills. 
-Animations. While I wanted to challenge myself and practice learning on my own, I should have asked for help sooner which would have saved time. Earlier communication between the animator (me) and the programmer (Alex) in what was required for the animations to be unity-ready would have helped both of us. From watching youtube videos from games conferences, it seems like this is a common problem in the industry. 


3.    What would you do differently next time?

- Broaden our skill-sets so we would be able to work more closely with the same software together.
- Ask for help sooner
- Learn even more about Unity. 
- More environment models and details. 
- Extensive back-ups for when models break (such as the lizard) and Unity scenes. Having Git as the only source for backups is not recommended. 
- Start Animations much sooner. Perhaps instead of doing all the models and then the animations, doing one by one would have been better.
- Plan more time for the finishing touches. We focussed so much on just getting everything complete in time that we forgot to budget enough time for polish. If we'd had the time to polish, we could have fixed all those little things that make a game look professional and complete, like lighting and particle effects.



Friday, November 16, 2018


Our game is almost complete.

I feel this game has both been a challenge but also a great experience for all of our team. 

Georgia, as our main 2D lead has continually improved the game's textures and level designs. 

Zoe, as our all-rounder, has continued to help with the animations, textures, and models. The Pig animations are also Zoe's work while myself (Tom) worked on the walk cycle and idle animations for the other characters as well as the props. 

Alex has been working very hard with Brad as our sole programmer, uploading all our assets as well as the coding and in charge of the debugging and testing. 

As of today all of our character and props are fully modelled, animated, unwrapped, textured and uploaded to unity from scratch. This would not have been possible without teamwork and working together to help each other as our group had a range of inexperienced members and final-year year members, and team members with more specialised skills rather then diverse. 

Our Main Development pipeline was:
Tom: Modelling > Unwrapping > Animations
Zoe: 2D Level Design > Additional Models and Textures > Improving Models > Unwrapping > Improving Animations. 
Georgia: 2D Art Lead > Textures (A ton of textures)
Alex: Coding > Testing Lead > Unity Assets 

Bellow are some examples: Our current game layout by Alex, Textures by Georgia (Left), Startled Pig animation by Zoe and Yeti walk animation by Tom. (Right)

That's it from us, thank you everyone!




Thursday, November 1, 2018

I've been texturing

So some more examples of how we're using textures to make object/enemy interaction/type clear to the player.

Attached are different textures for different levers (all the same model). One lever (red/purple) requires the head to push it once to activate, another (yellow/red) requires the butt to push it once to activate it. The last (blue/green) can be activated by either head or body, but only activates doors/bridges while being held.

Playtests

We've had 3 play tests done at a very buggy stage and then another 3 at a much less broken stage.
One bug involved enemy collisions with pig to launch poor pig high into the air. Pig also had a slow fall speed resulting in this floating bounce effect.
At this early buggy stage, the enemy hurt boxes were also too small, so pig would hit a cat, get launched, and face no damage.
Some players, I noticed, had the most fun playing with this bug and experimenting with the physics than they did playing the game as intended.
The launch bug/feature was being used to speed run the game (float over obstacles) and to get into unlikely places (see the attached image, which took 10 minutes of attempting to achieve).



Also, the pig aint stretching. Which is a pain, since this was the core mechanic we built around. But it's a nightmare to code. The game is playable with the butt and head separated still, and the controls are the same. It's still an interesting mechanic to control two halves of the same entity. And, maybe we slap on some particle effects, it'll look intentional?

One thing we learnt from both sets of play tests was that object interaction was just not clear enough - this in part due to some textures not being attached yet - but we will be needing some in game instructions for the first level at least.

Still, people reported enjoying the game and facing challenges, figuring out how to pass obstacles.

And that launch bug might become a launch feature. Of course, launching would have the drawback of actually dealing damage. Which would balance it, but keep it fun. You could sacrifice a health unit to access secret areas, collect hidden stars. And it's hilarious to watch pig jettisoned into space by cats.

Tuesday, October 30, 2018

Update 31/10/2018

Hi everyone, here's what I have been working on for the last few weeks since my last post.



Pictures one and two are examples of how the models were made and unwrapped.  Big Shout out to my team member Alex for showing me how to UV properly.

Last Pic is the Rig for the Yeti with added IK handle. The IK handle took me a while to learn but was great for making the feet stick to the floor. The wide hips also helped reduce the stretching.

All is left for me to do is to finalise the animations: Walk cycle, attacks, and idle animations of the characters. Looking forward to seeing how it turns out!

Friday, October 19, 2018

Name Change!


Yoink! is the emotion of this game. Yoink! is what you do to Pig to get him out of trouble. Yoink! is a much better title. 

Skins Update



One of our game principles is clarity/ 'no sneaky tricks'
We want the player to know how an enemy will behave, predict when it will attack, and not feel surprised cheated when killed.
Different enemy types move differently and we want the player to know what enemy type they are dealing with. To distinguish between enemy types we are using different skins.
Here are some of those skins :)