
Fam Ops Development Blog
Fam Ops is an arcade-style co-op survival shooter that throws you and your friends into a chaotic arena filled with relentless enemy waves. Collect points from defeated foes to power up your gear and play your way—whether you want faster firepower or quicker movement. It’s all about teamwork, strategy, and split-second decisions as the enemies get tougher and the stakes get higher.
Published Jan 15, 2025
We had a goal to build a multiplayer game to play with friends which had a co-operative objective to allow us to work with each other rather than against each other.. We wanted to make it online multiplayer so that we can play with our friends in different cities or across the world.
The game also needed to have simple controls so it was easy to pick up and an element of resource management strategy to keep the game loop interesting enough.
Hence we decided that wanted to create a game with the following constraints
- Online Multiplayer
- Co-Operative Objective
- Simple Controls
- Simple Resource Management
The game that inspired us was Dead Ops, a game-mode from CoD: Black Ops which is a couch co-op zombie survival. The Twin Stick controls were simple to pick up and just what we were looking for. We decided to emulate the game and make it work with online multiplayer in mind.
Fam Ops allows you to host/join a server to play with your friends using a combination of AWS Gamelift FleetIQ, DynamoDB, API Gateway and Lambda.
Fam Ops is an arcade-style co-op survival shooter that throws you and your friends into a chaotic arena filled with relentless enemy waves. Collect points from defeated foes to power up your gear and play your way—whether you want faster firepower or quicker movement. It’s all about teamwork, strategy, and split-second decisions as the enemies get tougher and the stakes get higher.
- Vlad Chandran
- Tejas Ahluwalia
- Notion
- Miro
- Audacity
- Figma
- Amazon Q
- AWS Gamelift FleetIQ
- EC2
- Auto Scaling Groups
- Launch Templates
- AWS DynamoDB
- AWS API Gateway
- AWS Lambda
We used an amazing starter kit template from Nodragem featuring a player controller, shooting mechanics and enemy behaviour that we used as a base for the game mechanics.

Although we didn’t utilise everything that the starter kit had to offer, we utilised the base mechanics to add multiplayer on top of that as a layer and test if we can even do it as it was our first time working on a multiplayer game.
We integrated the multiplayer functionalities to sync the game elements from the client to start exclusively running on the server.
We created a Test Map environment as a playground to implement the game mechanics we wanted to add
- New Enemy Type
- Wave Spawn System
- Upgrade Station
- Level Exit

We stress tested the server to check how many bullet and enemy instances we could run before there were dips in server framerate and performance.
We looked for alternatives for an optimised physics engine and found Jolt provided the best 3D physics performance for our use case.
We planned a basic core loop we wanted to achieve as Version 0 to validate and playtest the game with 2 players.
- Spawn Enemy Waves
- Eliminate Enemies and Collect Points
- Use Points to Upgrade Player Stats
- Spawn Harder Enemy Waves
Although we had planned a lot of player and weapon upgrades, we ended up only implementing one player and one weapon upgrade for the submission build.
- Player Movement Upgrade
- Weapon Fire Rate Upgrade


As for enemy progression, we had planned to add three enemy types and three tiers of difficulty in each enemy for difficulty progression, but managed to add two enemy types with only one tier of difficulty.
- Base Enemy (Normal Speed w/ close range attack)
- Chaser Enemy (Fast Speed w/ wide explosive damage)


We designed the map to be optimal for 4 players to play together with enough open area and choke points to shoot down at the enemies collectively.
Prototype Version


Final Version


After multiple iterations, we reduced the map size significatly as there was still too much space to run around which were not utilised.
We used the free assets from Atomic Realm, specifically from Low Poly Roads, Into the Wild and Assets Post-Apocolyptic to the 4 player map we designed.
We added a Lobby System to Host or Join a Lobby Room
Once all the players are in the lobby are ready, the host starts the lobby which connects all the players to the server. (at moment is only Mumbai servers but we plan to add more in the future)


- <a href="https://www.flaticon.com/free-icons/firing" title="firing icons">Firing icons created by POD Gladiator - Flaticon</a>
- <a href="https://www.flaticon.com/free-icons/evolve" title="evolve icons">Evolve icons created by Iconjam - Flaticon</a>
- <a href="https://www.flaticon.com/free-icons/keyboard-button" title="keyboard button icons">Keyboard button icons created by kliwir art - Flaticon</a>
- <a href="https://www.flaticon.com/free-icons/wasd" title="wasd icons">Wasd icons created by Freepik - Flaticon</a>
- Sound Effect by <a href="https://pixabay.com/users/freesound_community-46691455/?utm_source=link-attribution&utm_medium=referral&utm_campaign=music&utm_content=64964">freesound_community</a> from <a href="https://pixabay.com/sound-effects//?utm_source=link-attribution&utm_medium=referral&utm_campaign=music&utm_content=64964">Pixabay</a>
- Sound Effect by <a href="https://pixabay.com/users/floraphonic-38928062/?utm_source=link-attribution&utm_medium=referral&utm_campaign=music&utm_content=177985">floraphonic</a> from <a href="https://pixabay.com//?utm_source=link-attribution&utm_medium=referral&utm_campaign=music&utm_content=177985">Pixabay</a>
- <a href="https://www.flaticon.com/free-icons/exercise" title="exercise icons">Exercise icons created by Freepik - Flaticon</a>
We ran into a few situations where the game behavior was not as intended due to a misunderstanding of where the code was being executed - the client or the server. Since both share the same codebase, we had to keep the code execution context in mind when working on any part of the game. We learnt debugging methods built into Godot that helped up get better at fixing bugs caused by this kind of error.
We had no idea that physics engines were this demanding. We could barely instantiate over 60 enemy entities before our powerful desktops would start to lag out. Moreover, since we had decided to keep almost everything server authoritative, there were few obvious workloads for us to offload onto the clients.
We spent a few days analyzing flame graphs. I was convinced that there must be something we did wrong, but after understanding physics engines better and realizing that this was indeed a common challenge, we started looking for solutions. And we found one, Jolt Physics. This physics engine is soon going to be integrated in Godot itself as an officially supported option. That gave us the confidence to switch over. The transition was completely seamless and we could now have up to 150 entities before dropping frames.
To give you an overview of our AWS infrastructure, our game client and server use a REST API setup by API Gateway which triggers lambda functions. These Lambda functions communicate with the GameLift FleetIQ GameServerGroup to Register, Update and Deregister. We also have Lambda functions for joining, leaving and retrieving lobbies. The lobbies are recorded in DynamoDB
AWS has GameLift, which is purpose built for game-hosting. It has features like matchmaking too. However, AWS GameLift has client SDKs available only for C++, C# and Go, and plugins for Unity and Unreal Engine. Since we’re using Godot, we had to work around this. We could use a GDExtension wrapper around the C++ library, but that carried some risk.
We decided to integrate our game servers with GameLift FleetIQ based on this helpful decision chart by AWS. - https://pages.awscloud.com/rs/112-TZM-766/images/AWSGameTech_Guide to GameLift and Game Server.pdf (Page 5)

To keep the code decoupled, our game server makes HTTP requests to a handful of AWS Lambda endpoints (via API Gateway) that handles the necessary communication with GameLift FleetIQ.
The integration with AWS services in this way makes our game reliable, easy to distribute and performant.
We also used DynamoDB to create lobbies. Using lobbies, we could let a few people join the room while they wait and are not utilizing a server, saving us ec2 costs. We weren’t too concerned about this though, since the spot instances that FleetIQ allocates for us should be quite inexpensive in the first place.
We’re using c5.large and c5a.large instances which are overkill for the load our game server puts on them. I wish more instance types were available for use with FleetIQ. We do get the occasional lag spike still that we need to investigate further into.
While dealing with AWS’s permissions and policies can be tedious, it also gave me confidence that my resources are secure. At the end of it all, I’m glad AWS’s rules made me deploy these game servers in the same way larger studios would.
The experience of working with Lambda, API Gateway, DynamoDB and FleetIQ was honestly quite smooth. There were more steps than I would have liked, nevertheless, everything made sense.
Although we followed the protocol of working on separate branches and merging often, we would have some issues of merging the same scene we would have worked on at the same time towards the end of the project. Specifically, when working on the same scenes, we would have merge conflicts that were tedious to resolve due to interdependence of external resources that would have been imported or sub extensions that might have changed. Often this required coming through the scene definition and manually recognizing dependencies and loading orders.
Although we had a lot of ideas of how we wanted certain 3D assets and animations to be designed to give the game a different feel, we had to work with the assets in the starter kit. We lacked the technical art skills to modify the art assets to shape the overall feel of the game without actually breaking the existing template.
There were certain challenges we faced when we were designing the upgrade paths and progressions for the player to utilize against the enemy horde which made the game feel too easy.
When we designed the enemy wave system difficulty progression as well, we would go back and forth of making the enemies too difficult or too easy. It was important that the game was not too boring or frustrating for the player.
Through playtest and trial and error, we think we found a balance for the upgrade path and wave difficulty but could still do a better job with the overall game balance.
There were issues setting up the Navigation Mesh to allow to enemies to move around obstacles and not get stuck. It was tricky to setup the navmesh to be generous enough to allow enemies to warp around complex structures and not to get stuck inbetween. There are still some issues where the enemy gets stuck when chasing the enemy, but most of the time the enemy should be able to find the player.
We didn’t want to make a generic game that would just fit the criteria, we wanted to build the game we actually would play with our friends. This game feels fun and challenging and we find ourselves playtesting it more than we should for the fun of it.
We decided our constraints in the first week of signing up to the hackathon, and although there were a few times when we discussed pivoting to a simpler idea like switching from 3D → 2D , we still stuck to all the constraints decided to pursue.
This is a first multiplayer project we ever attempted and to say that we had “built” a multiplayer game that actually “works” makes us feel proud that we went for it.
Although we have used other 3D Game engines like Unity and Unreal, this was the first time we opened Godot was for this hackathon so we had no experience with the engine. There was a learning curve to working with Godot and we found it easy to learn and pickup with a huge community that provided a lot of resources to learn from.
We were having a lot of fun playing and we knew we had to playtest the game with a set of new eyes to really tell us if the game made sense and if it had any fun it in. They played it and even when they ran out of content to play with, they couldnt put the controller down and kept shooting with no real objective provieded adn that’s when we knew we had a solid base for a game to work and develop on.
We are happy with how the submission build is and plan to work on it in the future.
Here’s what we’re hoping to add for the next version:
- Adding multiple server locations across the world
- Co-op features
- Revive, Heal another player
- Storyline
- Additional player and weapon upgrades
- More enemy types
- Additional Enemy tiers
Working towards a Steam Release also feels like an achieveable goal for this project and can’t wait to see where it goes.