Guests In A New Time and Space
G.I.A.N.T.S is a 4 player couch co-op puzzle game. It can be downloaded here:
https://nic-lyness.itch.io/giants
Created by (in alphabetical order):
Animation & Assets: Kerry Ivers, Macauley Bell-Maier, Peter Buck.
Audio: Ash Ball.
Game Design: Adam Crompton, Nic Lyness, Nicholas Staracek.
Game Programming: Caleb Barton, Jack Kuskoff, Pritish Choudhary.
Tiny Sail Games + G.I.A.N.T.S
@tinySailGames + @GIANTSvideoGame
The original group of developers and I created Tiny Sail Games! This was at the start of conception of G.I.A.N.T.S. We wanted to start something that’s allows us to be a team, not just another project that brought us together. But it could potentially roll over into the foundation of building a core team. Creating G.I.A.N.T.S has been as 6 month journey, the longest game development haul that the entire team and I have ventured on. The first 3 months were pre-prodcution – conceptualizing, planning, requirements gathering, documentation, art style and finding art reference images. conceptualizing a game based around one core experience which we all decided was a local co-op where friends or strangers come together to have a good time, connect and create some memories. Have you ever played ‘Halo’ local multiplayer and right as the screen fades to black, someone presses that B button for the eightieth time to cancel? Memories…
Post-Mortem
Good
Feature Cut:
In the pre-production phase of Tiny Sail Games’ first project G.I.A.N.T.S, we ended up having essentially 5 core mechanics which got narrowed to 3.
Tethers:
Tethering (a tether) is a rope between the players and EHU (Extraterrestrial Harvesting Unit) simulating rope physics. Which is a result of players entering a proximity of EHU or inserting crystals into her (EHU).
Crystal absorbtion:
- Swell – Makes the playable character larger, stronger, heavier, slower.
- Shrink – Makes the playable character smaller, weaker, lighter, faster.
Stretch– CutSticky– Cut
There were four different types of crystals. Each of which (when inserted into EHU) gave the player who inserted it a power up. Each crystal has a unique power up that it holds within and only applies it to a player via tether (through insertion into EHU).
Tethers are still a core mechanic along with inserting and absorbing crystals through EHU. What changed was, we removed two crystals and their abilities – stretch and sticky, what would have been green and yellow. Sticky would have been that anything the playable character touched, would stick to them and allow that player to stick and roll around on walls or the roof. Stretchy would allow that player to latch onto fixed anchor points in the world and stretch their character, fling objects or players or act as a bridge.
This resulted in not having to create two separate textures (big whoop) but mainly it reduced the amount of subsequent dynamics we had account for by ALOT.
Why did we cut them?
Short story – Scope.
Long story:
The Tiny Sail team took inspiration from Gang Beasts and Human: Fall Flat and were going to pursue physics based movement. Physics based movement alone, not physics based interactions. In a local couch co-op situation, who doesn’t love bursting out laughing based on the ridiculous things that happen to your physics based playable character and buddies? It wouldn’t have over complicated game play but just made the non-core interactions a little more goofy and pleasing to play with. It turns out that physics based movement isn’t that hard. But in combination with game play elements and other mechanics on top of what we needed the sticky and stretchy abilities to do and how they interacted with every other system in the game, it blew the scope way out of proportion. A very small summed list of the things we needed to think about:
- Physics movement + mesh stretching working.
- Mesh stretching and interacting with colliding objects.
- Physics interactions of objects within stretched mesh and physics of stretched mesh.
- Physics movement + stickiness + wall climbing + object weights + .
- How camera will the camera account for 2-4 players within an enclosed or open environment that can be positioned on the floor, walls or roof whilst keeping an orientation relative to the objective.
- Physics movement + any combination of crystal power up + any possibilities of puzzle elements + 2-4 players and how they each interact with any of the aforementioned.
- Level design consequences and puzzle design choices that we have to account for with the combination of all of the above.
Not to mention the number and severity of issues that we would discover along the way. Getting it to work and not be buggy is a massive task on its own, let alone within the given time frame and with the experience that our team had dealing with a game or task like this. The physics based movement was going to allow stretchy and sticky to really shine. Without it, it would be good, but not great. By only having swell and shrink as the power-ups, the physics based movement would still be a great addition but not a necessity.
This is what it ended up feeling like.
Although all of the above points I’ve mentioned are just a part of game development and I would actually love to work through those, there was no way that it was happening in the development time frame of G.I.A.N.T.S.
We could happily walk away from it and focus on other elements of the game. The shrink and swell elements of the game could still be used in so many interesting ways by themselves or in combination with each other and with different amounts of players. Rather than creating new mechanics to create interesting dynamics, utilise and expand on the existing ones. Don’t be afraid to feature cut on initial ideas, sometimes less is more.
Cause Analysis
Future Lessons
Using FMOD for Audio:
Mute Unity Audio
For the entirety of G.I.A.N.T.S we used a program called FMOD. This is what Ash (Our audio guy), and myself know how to use because we’ve worked together on multiple occasions. Mindstate was the first game we integrated FMOD with Unity and that’s where we discovered most of the hurdles and issues we’d need to tackle for further projects. That was definitely very worthwhile because it opened up avenues to learn foundations of external audio applications. I was solely responsible from getting all of the audio in G.I.A.N.T.S and collaborated very closely with Ash. There are plenty of benefits to use it rather than the standard unity audio setup. As an example: This is a single sound split into two sections, EHU hovering and EHU locking into a node, that are both comprised of different tracks with different transitions and more other fancy audio stuff.
Rather than having multiple sounds and having to worry about code and timing and transitions it’s all handled by a single event. It starts by playing the “EHU Hover” sound and enters the “Hover Loop” zone and loops repeatedly until the “LockNode” parameter knob gets set from 1.00 to 2.00. Then the transition from playing the hover sound to lock node sound starts and plays.
Why did using FMOD go so well?
Ash and I had collaborated multiple times (Transmutation, The Ride, Mindstate) before the start of this project. By now, I’d already learnt most of the foundations and necessary actions required to get FMOD integrated into Unity and make it do what we needed. Most of the hard learning curve had already been conquered. Ash knew exactly what he needed to do to make the sounds game ready. There is a large distinction between sound design and making these sounds game ready. As an example: like what was mentioned above with setting transitions, and looping areas of sounds with exposed parameters that also have appropriate naming conventions.
There were only two things left to do:
Learn how to get VCA, which is relatively similar to getting other parameters.
Make FMOD sounds playable via code.
We planned for it.
From the get go, it was decided that we would use as much audio through FMOD as possible. We knew the capabilities of FMOD, we knew what it allowed us to do, and between Ash, Staracek and myself, we decided a little big more leg work in the earlier days would save us a whole lot of workload down the track. FMOD integration was my third commit on starting work on G.I.A.N.T.S. Setting up foundations that allowed workflow and audio integration process to be much easier and faster.
Audio from the get go.
Audio was (and is always) just as important as the rest of the game. I didn’t leave audio integration until the last second of the project. It was an ongoing process over the entirety of the project. In which I set aside a specific amount of allocated workload each week to make progress on audio as it became readily available. Tackling each problem as it arises. Plus once everything was wired up with placeholder sounds all ash had to do was overwrite the old sound with the new one, re-build, it’d be updated. I’ve left audio until the last-minute before, and it didn’t go bad at all, in those instances. But those were very small games in comparison and there was much less margin for error. Having feedback sooner rather than later was always going to be good, especially because we wanted to put this in front of players as soon as possible.
I’ve had an experience when working with ash before (when I wasn’t in charge of putting in audio) and a lot of his efforts and assets went to waste because the person who was in charge didn’t put in the effort or allocate appropriate time for audio integration. Not only was there a lack of feedback, I can only imagine it felt like a kick in the teeth to Ash. Just as if I created content for someone or something and majority of it didn’t make it into the project due to lack of effort or appropriate priorities. Seeing this, has made me take it on board as if it was a problem that ‘I’ caused and didn’t want to see happen again. Causing me to plan for future endeavours which allows myself, or anyone on the team/project to not have to go through unused content.
Future Lessons
I can’t say “have a constant audio team member that knows what they’re doing”. But what I will say is:
- Continue to plan for audio with the same amount of importance as the rest of the piece of media (not game specific).
- Plan where your audio is playing from, is it housed in a game engine or through an integrated program?
- Plan for each of the sounds that your piece of media will need.
- Document each of the sounds that your piece of media will need.
- If more than one team member – document who is in charge of this specific asset.
- Have a checklist of some sort whether it is complete, in progress, or not complete.
- Document if that asset readily available for you to view. Document where you can find this asset.
- Document if it is implemented in your piece of media. Just because it’s implemented does not mean it’s finished.
Bad
Camera:
G.I.A.N.T.S required a rather complex camera system that we greatly underestimated. W Camera was the largest issue throughout the entire development process. It created major hurdles that hindered progress on getting the core game loop. Having the camera issue created a cascade of other issues which were all solvable by having a working complex camera system. We pursued a similar style of progression as INSIDE where the game has a constant flow of environments through puzzle play. So rather than loading in different levels and puzzles separated by load screens, the transitions never took the players out of the game.
What caused this camera problem?
In pre-production we didn’t know the exact systems that the camera would need in order to operate. We underestimated the amount of work that had to go into the camera to account for all of the possible things we needed it to do. We didn’t exactly know what we needed it to do. By the time production came around and we started to get elements of game play bit by bit, we started to fully understand how this game is going to be constructed and played and what we need the camera to do. We didn’t get the camera prototype to a stage where it even remotely started to do what G.I.A.N.T.S would need it to.
We had a specific team member who was allocated to getting the camera system working and implemented. They did not deliver or make anywhere near enough progress by any of the deadlines. We had to switch team members on who was working on other systems onto the camera, causing the other systems progress to come to a grinding halt. My point of this isn’t about playing the blame game, it’s to reflect and learn to have contingency plans if production elements go awry.
Future Lessons:
Research and explore other types of games that have similar elements of game play, pay attention to what the camera does, make notes, try to extract relevant information that will help design the system we need. Try to replicate small doses of functionality. Plan how these little elements will tie together into a whole cohesive system. Essentially rapid prototype before production phase.
Have a contingency plan (which comes under risk management). Decide what tasks take priority, what gets cut or how the production pipeline changes if an element needs attention or won’t get done.
Stay tuned for part 2 of the G.I.A.N.T.S post-mortem where I discuss topics like
- Being the project manager of 10 people (which is large for a student team).
- Asset Management within unity, prefabs, mesh’s naming conventions and the maintenance it entails.
- Weekly meetings within collaborative space. Working in a collaborative space.
- Tiny Sail Games Discord server and the purpose it serves and how it operates.
- Being the social media person for G.I.A.N.T.S and Tiny Sail Games.
- People Management.
- Teaching the animators how to be unity competent.
- Teaching non source tree familiar team members how to use source tree and not make the repository explode.
- Explaining how non source tree familiar team members made the repository explode. And how Caleb Fixed it.
- Particle Effects!
- FMOD Scripting.
- Documentation – Including bug lists, schedule, project breakdown.
- Why initial shipped product was lacking level 6 and 7.
- How the game ended up not being 2-4 player friendly and is only 4 player friendly.
Until next time –
Nic Lyness 