Sync & Ecco
Role: Lead Designer & Producer
Engine: Custom C++ Engine
Side by side, you and your robot sidekick must navigate through a treacherous corporate building to find the AI core, freeing the robots from the control of the AI hivemind.
Are you ready to face the other consequences?
In this couch co-op experience, work together to overcome enemies and avoid hazards. However you can’t face this task alone, it’s truly a duality of survival.
Find all the relevant documentation for the project below!
Working in a Custom Engine
(Click to expand) During projects, I always aim to learn new skills.
Before this project, I had never worked outside of Unity, so learning a new engine was the perfect opportunity to gain some new skills. Being pitched a custom C++ engine project was scary at first, but after meeting my team and solidifying an idea for the game, I was keen to take on this challenge. We had two greatly dedicated programmers who had excellent communication skills, which made the whole process very smooth.One of my early concerns was that I didn’t know any C++ at all. In Unity, I’m comfortable prototyping mechanics and scripts using C#, however, for this project we relied heavily on the programmers to create everything for us. This meant we had to have constant communication between the design, art, and programming streams.
I felt like going back to the basics of game design on this project. Without pre-existing tools, I had to focus on the core aspects of design we needed and work closely with the programmers to develop the systems we wanted. It was a great experience that gave me a better understanding of what tools you really need and insight into what goes into building an engine.
Team Communication
(Click to expand) Initially, cross-stream communication was a challenge.
Our team was still getting to know each other and figuring out what we wanted the game to be. Better communication early on would’ve helped us scope the project more effectively early on, but again, this was an unavoidable part of working in a new team.As a producer, I made it a priority to make sure I was on the same page as everyone in the project and up to track with everything. However, I had to take an unforeseen absence due to personal reasons during an important early development phase. It was a difficult time for me, but the team adapted quickly and made the progress needed. When I returned, everything was on track, and I was able to jump back into the project like I never left.
Scoping in a Custom Engine
(Click to expand) The scope for a custom engine game was one of the most challenging parts of this project..
Not knowing what tools and systems we needed from the get-go made it difficult to predict the design and production pipeline. Another thing that was a result of a custom engine project, most of the assets were implemented near the end of production, which introduced some risks but ultimately worked out fine.I approached the project by creating a roadmap that outlined our stage milestones and development progressions. During daily stand-ups, we outlined and integrated specific tasks that were recorded in a document and then put into Hack N Plan for task tracking. For the most part this worked well. Towards the end of the project, we introduced whiteboard-based sprint planning. This turned out to be much more effective. I wish we started using whiteboard sprints earlier, as it helped keep everyone on the same page and improved communication and work efficiency significantly.
Below are some screenshots of how we managed these tasks.
All the audio on this project was made by an external team member, James Viola. All the audio was put into an asset list as they were not present in these discussions. This document outlining the audio and asset list can be found here:
Open Audio Asset-list here!
Design Tools
(Click to expand) This was the first project where I had to work without already existing engine tools.
We brainstormed what tools we would need during pre-production, requesting them from the programmers. Some of the key tools developed included:- A brush style level editor.
- Prefabs.
- Modifiable components on Sync and Ecco.
- Enemy flow map.
- Functional Doors.
- Enemy Spawners.
Enemy directional level flowmap:
Making Asymmetrical Gameplay
(Click to expand) From our brief, we were required to have two asymmetrical characters that cooperated during gameplay.
The real question was, how can we make both equally fun?Initially, each player had three abilities. This was soon cut due to scope and making each player feel too similar. Having a set amount of manually activated abilities that do drastically different things is an easy way to make each character “play” differently, however, it didn't feel asymmetrical enough. We wanted to go beyond just having two characters that play the same with different abilities, so we focused on making each character play completely different in several aspects.
This became our biggest focus during pre-production and I'm extremely pleased with the outcome of it. We got straight into brainstorming and after hours of discussions, we developed a draft for two properly asymmetrical combat systems.
This was the original combat system:
Ecco - brawler character who deals group damage by attacking enemies at high speeds. Damage was directly reflected by Ecco’s velocity. Ecco also had a boost. Sync - Sniper character who deals strong single-target damage from a range. Does more damage dependant on the amount of charge held in the railgun If both players pressed B in unison, it would create a healing field around the players that healed each player over time as long as they were close together. It was important to balance the resources for each character, making sure one wasn’t by numbers “easier” to play/manage.
After pitching our game at an industry panel, we got feedback regarding the level of cooperation from each player. When attacking together, we had the opportunity to create another layer of fun. We already had the co-op defensive ability that would heal but something we didn’t have a co-op offensive ability. Something that I had pitched very early on in pre-production that had been sidelined came back, the Prismatic Sync shot.
The Prismatic shot worked as follows: Sync would fully charge their railgun and shoot Ecco. If the shot hit Ecco, the shot would split into several beams and deal a higher amount of damage.
Here’s a clip of it in action:
This was received perfectly in playtests, with data showing how satisfying the shot was. This shot became our new focus for the combat, and we based further combat development around trying to make this shot happen. This took a whole lot of balancing, adjusting Eccos's hitbox, adding an extra hitbox just for the shot and adjusting Sync’s shot width.
Play Testing
(Click to expand) An issue we ran into, creating a two-play asymmetrical combat game, testing is bloody hard with one person.
This meant that whenever we had to find testers, we’d need to find two, or anytime we needed to test proper gameplay internally, we needed two of us. Solo testing led to some issues with the characters being more balanced for a one person experience, which we had to go back on and keep in mind during testing.As most of my games have been developed by myself or are just prototypes, I hadn’t done too much external playtesting before. In this project, especially due to our asymmetrical combat, lots of external testing was needed. We conducted our tests by finding other students on campus willing to test. This was our testing processing:
- We gave the testers a version of our gam.e
- A designer would sit by and observe them play through a level.
- After the level was completed, we got them to fill out a questionnaire.
- Observational notes were taken by the tester throughout the game session.
Open Testing Doc here!
Right before we entered beta, we took our game to International Game Developers Association Melbourne(IGDAM). This was a great opportunity for us, as previosuly we were only testing with other students on campus. IGDAM gave us the chance to test our game with a real audience.
The testing process for IGDAM was the same as the others. Heres our testing form:
Balancing Sync
(Click to expand) Sync’s final kit and values are as follows:
- Quick, low charge shot.
- Long, fully charged shot.
- Prismatic shot.
- 100 Health.
- 415 Speed.
We didn’t want Sync to be drastically underpowered or too powerful to the point where the player wouldn’t want to use the prismatic shot. We almost halved Sync’s charge times, and made them a bit quicker
Here’s the original shot vs the final shots:
The prismatic shot was tricky to balance, as we wanted it to be powerful, but not make the game a walk in the park. Originally, the shot dispersed 5 beams at a 70-degree angle. The shot was set up so we could edit this angle, number of beams, damage and pierce count. From feedback, the shot was too hard to hit and wasn't worth the payoff, as yes it annihilated any enemies behind Ecco, but only in a small area. We increased the angle and beam count, until we got 10 beams at 100 degrees. The issue with adding too many beams was, the shot felt way to busy on screen, and after a while, didn’t feel as satisfying to hit. Here’s the original vs the final shot:
Balancing Ecco
(Click to expand) Ecco's final kit is as follows:
- Damage dealt by driving into enemies at a high speed.
- Boost that allowed Ecco to temporarily accelerate past maximum speed and deal more damage and knockback.
- A slight siphon when Ecco hit enemies (Ecco slightly gained health on contact).
- 200 Health.
- 630 Speed.
Ecco’s turning circle was the thing we figured out first. Early in alpha, the entire team was testing Ecco’s controls to find the values that felt the best. From testing, general feedback showed people wanted Ecco to have tank controls or be able to turn on the spot. What felt “good” wasn’t what we wanted as it didn't align with our design We made an executive decision to keep it as car controls, to reinforce the differentiating kit from Sync.
We then came to a group debate, about whether we preferred global or local controls. After our first test, the questionnaire revealed players preferred local. We still had large disagreements to this decision internally, so we tested again after some value tweaks. Our second test showed that an overwhelming number of people preferred global this time, so we locked it in.
After changing to global as we were previously 90% set on local, that's what we had tested with. This meant the Ecco controls once again felt clunky due to different inputs.This was another tedious headache as we had to retest all the movement values.
Here’s what Ecco’s alpha movement looked like vs the final build:
Ecco’s controls were finally done, so all that was left was the combat values. We quickly found some values that felt comfortable. The issue we ran into here was Ecco was comfortable as if they were played by themselves (as mentioned before), so when it came to testing with Sync in the equation, Ecco was too powerful. As Sync already felt underpowered, they were even more shadowed by Ecco instantly ploughing through any enemies in their way.
To solve this, we lowered Ecco’s damage values as our original idea for the character and added knockback. This meant Ecco would still damage enemies, however, much less. Ecco would now knock back enemies to line them up for Sync to shoot.
Here’s what Ecco’s looked like final build:
Balancing Enemies
(Click to expand) These are the final enemy values:
- 200 Health.
- 25 Damage.
- 350 Speed.
Something that rippled from our player changes was now the best strategy was to stand still as Ecco and with Sync’s faster shot time, just spam the prismatic shot. We solved this by making enemies faster and more drawn towards Ecco rather than Sync. We added some more enemy spawns so that enemies would spawn slowly in previously cleared rooms and funnel to the player's location. This put a slow but constant pressure on the players, meaning they would have to deal with these stragglers and mess up their campy prismatic shot method.
Here’s what Ecco’s looked like with alpha values vs in the final values:
Asset Import Pipeline
(Click to expand) As the Lead Designer, I had the responsibility of importing the majority of our assets into the game.
This included models, textures, creating materials, and creating prefabs. While this process sounded straightforward—especially in a regular engine—it turned out to be one of the most time-consuming and tedious aspects of the project. With lots of help from Lochie, I managed to import everything, but frequent adjustments were required. At least one prefab a day needed to be modified, this added up and took away time I could have dedicated to other areas of development.The process involved a lot of manual notepad editing GUIDs and using an art tool developed by the programmers to import and edit files. Every file had to follow a strict naming convention to ensure successful imports, which added another layer of communication, hence time, if files were exported or named incorrectly.
Creating prefabs required manually building a game object, and saving it as a parent prefab. To make this process easier, I created a dedicated prefab level to store all parent prefabs. This approach made future edits far easier and more efficient. Refreshing prefabs in other scenes consisted of manually going into a scene and refreshing all instances of that prefab across other scenes. This again was a little tedious, but it had to be done.
Level Design
(Click to expand) Making levels was a core part of our development and something I was really excited to tackle.
Our levels would scale in difficulty in both combat and minor puzzles. I had around twenty levels drafted before level production started. Here are some of my level drafts:
The third image are the sketches I eventually based my two levels on, so keep that in mind when seeing the finished levels below!
When making levels typically, I take an abstract approach of just blobbing down shapes until something sticks. I did this for this project as well, however, I wanted to take an approach to designing my levels more around game mechanics. These were the core principles I based my levels around:
Long open hallways to encourage Ecco’s high speed and damaging movements (originally we didn't have the prismatic shot in mind and Ecco would just block Sync’s line of sight). Rooms with desks (any obstacles Sync could shoot over) scattered in an almost tricky-to-navigate environment for Ecco. This meant Sync could defend while Eccos focused on navigating around the room. These were the core concepts for each level, even though these ideas somewhat fell through the final game to design and gameplay changes, it made them overall more fun to interact with.
This was my first level created, the first level of the game that takes place in a warehouse setting.
As this level was the first level, I focused on introducing new mechanics with minimal puzzle elements. Straight away, I introduce the players to 2 mechanics, bollards and pressure plates. The players learn by going over the first plate that Sync can fit through bollards, and activate plates temporarily. They also learn that Ecco can permanently activate the plate here. Players would already know this from playing the tutorial, but I still wanted to simply re-introduce them early in the game for reinforcement.
I tried using these previously mentioned design principles to give both playersan area to shine with their character.
Here is the first version of the level.
The first version of the level ended up being too small, so I remade it but at almost double the size. Here’s the revised level:
The second version didn’t flow as nicely as I wanted, so I redesigned the second half of the level slightly, which brought me to the final version which made it into the game:
I developed a second level for the office setting, but it didn’t make it into the build due to scope. I took a more puzzley approach on my office level, as it was set later in the game. My puzzle was simple but forced both players to work together by stepping on different pressure plates at the correct times.
Here’s the level:
This is the puzzle clearly with the solution:
As you can see, the level has a circle loop in it. I wanted to create a level that could be replayed differently from the first playthrough. At the start of the level, I would show the players the exit elevator behind a locked set of doors. The players could pick either path (left or right) and play through the level. With the existing bollard mechanics, I used them to block off one side of the map so the players were forced to go the other way. The level made the players go back to the start of the level, being able to now access the elevator.
Here's both paths the player can take to complete the level:
Trailer
(Click to expand) I had the responsibility for creating the trailer for our game.
I used to really enjoy video editing when I was in high school, and after such a long project it almost felt like a reward jumping back into it. Straight away I storyboarded a trailer for us, here it is:To make the trailer, I duplicated our first level in the engine, creating a special trailer scene. I added special lights and changed some camera angles for a more cinematic feeling.
At the time of the first/draft trailer, the game hadn’t had its final polish yet. I had to add all of our audio in the editing. It was only a draft but I loved how it turned out and gave us a good idea of what the final trailer would be.
This was how the first draft of our trailer turned out:
Takeaways
(Click to expand) What I learnt on this project.
Custom Engine
Working in another engine was a great experience, not only because it was a custom engine but also a change of scenery from Unity. It gave me different perspectives on some design aspects and made me realise a lot of important tools/design methods I can use in future projects. In future, I want to try out engines such as Unreal and Gotto to improve my development skills further. I would also like to touch on C++ as if I had some minor knowledge of it, I would been able to contribute to helping the programmers with minor issues in this project that I could've helped fix in a language such as C#.Test & Plan tools ASAP!
I wish knew earlier what tools to ask for in the custom engine. As mentioned, since it was my first time out of Unity there were a lot of things I took for granted while working in Unity. Not being able to give these tools to the programmers earlier on meant we had to wait to test a lot of things we wanted to. We had to cut some stuff as a result of not having enough time to create the tools, being thought of too late in development. A lot of these tools obviously would’ve been impossible to know straight away, but this project has given me the skill to take a step back and look at all the systems in a project that we built from scratch. This means for my next project, even one in Unity, il have a better idea of all our needed systems.Communication
Communicate with your team! Keep it professional, but get to know them a bit beyond just in the context of the project early on. This will help build the team's comfortability and make the early critical stages of development less daunting. Working on a custom engine this was really important, as we needed to constantly be cross communicating between streams. This meant we had to communicate clearly and comfortably at the start, which I feel like we nailed.Asymmetrical Gameplay
Creating to asymmetrical characters that control and play differently is a really difficult task to pull off, but it was worth it. I’m stoked with how both players turned out. We created a really unique feel for each character and making them both as fun as each other was tough. I learnt that whenever making a game that’s two player, testing with two people is infinitely more efficient than testing with one. We had several moments where we catered a system for one of the characters based on how it felt playing by just that character against enemies, which caused future issues.Ripple Effect
Throughout the project, we encountered several points in development where we had to make unplanned changes. These changes gave rise to other changes, and those changes gave rise to more new changes.I learnt on this project that I previously “knew” but hadn’t experienced was the ripple effect. Feeling like we had finally found the right values for Sync and Ecco created a new strategy where the players just stood still. This was another issue that we had to solve, by adding more enemies. Then we had to tweak the enemy values slightly. It can bring rise to positive changes through, for example, the prismatic shot getting added back meant we didn't have to worry about Ecco blocking Sync’s line of sight when shooting. Figure out what things need balancing or changes early on and get to them asap. Test always and keep yourself time for unforeseen ripples during development.Design Principles
My level of design skills heavily improved on this project. Throughout pre-prod and alpha, I made over 20 level designs and gave myself plenty of time to iterate on these, take the best features/principles from each and refine it down to 2 full levels. I learned strategies on how to direct players (things like using weenies) and create a level around the mechanics of the game (for example creating long corridors for ecco to drive down so they can plough through enemies!). In future projects, I will continue my abstract-level creation method however I will always now put game mechanics in the equation.Playtesting
External playtesting is one of the most powerful methods of testing for a project. Getting constant fresh looks at the game brings so many things to light that you don’t see after working on the project for hours every day. I learnt a lot about observing people's behaviour when playing our game, gauging their reactions to player actions and level layouts. This led to a lot of raw data which also brought a lot of unforeseen to the surface. In general, external testing is great. Do it, watch people play your game and see if you’re eliciting the reaction you’re trying to.Video Editing
Jumping back into editing was a blast, and has re-ignited my passion for one of my old hobbies. In future projects, I’d like to make more cinematic-style videos for my trailers, similar to this one.Overall
Sync & Ecco was one of the most fruitful experiences of my development journey so far. I grew overall as a developer, learning more about leadership and how to communicate as a team. I gained countless new game design skills and refined existing ones. Flexibility and perseverance were key in this project as it allowed us to overcome so many unforeseen changes and ripples. I look forward to applying these lessons in the future. I’m super proud of our team and the game we created, and I’m excited to see how this project continues to develop if we decide to work on it after release.Credits:
Brodie Frazier (Me), Lead Designer and ProducerKian Kelly, Gameplay and Level Designer
Austin Lanyon, QA & Bugtesting
Lochlan McDonald, Programmer
Thomas O'Brien, Programmer
Rachel Missingham, Artist
Hachi Dinh, Artist
Lauren Trinh, Artist
James Viola, Sound & Music
Thanks for reading! If you want to download the game or see more of the game check out the itch page below :)