Into the Dataswarm
2024A 3D puzzle game where you must infiltrate cyberspace.
Overview
- Role
- Game Designer and Developer
- Team
- Digital Centurion (15 people; interdisciplinary team of artists, musicians, programmers, and producers)
- Context
- CSC404 (Video Game Design), University of Toronto
- Duration
- September 2024 - May 2025
- Engine & Tools
- Unity
- Status
- Finished, showcased at Level Up Toronto
How It Plays
Into the Dataswarm is a 3D puzzle game where you play as Anni the Cyberelf as she attempts to infiltrate cyberspace. The game is grid-based, and involves navigating Anni to the end goal on each stage. The player must also “hack” all of the enemies on a stage to complete the level.
Decisions
Since Dataswarm was built from the ground-up, we had initially only decided on a concept for a mechanic: the game would be grid-based, and the enemies on the grid would move when the player did. What the game would eventually end up looking like, both thematically and mechanically, was a complete mystery to us at the start. We built systems to handle the creation of the level grids at runtime, as well as systems to handle basic player movement, and iterated through a number of mechanical ideas before landing on the idea that the player would somehow “hack” the enemies.
Eventually, we settled on the idea that the enemies, once hacked, should dash as far across the grid as they could, and upon hitting another enemy, that enemy would also become hacked. That’s where the concept of a “swarm” came from, which led to the theming of the game as being set in cyberspace, and to the design of the game’s mascot, Anni (a cyberelf trying to infiltrate a computer system).
Iteration
The main thing we iterated around was the hacking mechanic. We knew initially that we wanted to make the game grid-based, but we didn’t know what our mechanic should be. We also knew that we wanted enemies, which began life as spiders that had themselves infiltrated the system, or sentinels that acted as the system’s antivirus:
These went through several iterations before we landed on the idea that the enemies should mimic chess pieces. The main two implemented in the final game were the rook, which can move across the entirety of the grid, and the bishop, which can do the same but diagonally.
We landed on hacking the enemies, but went through several iterations:
At first, hacking an enemy put it under the player’s direct control, mimicking the player’s own movement. Another version had hacked enemies become “overclocked,” acting more aggressively of their own accord rather than moving in sync with the player.
Finally, we landed on the dashing and hitting mechanics, to give the game a sense of chaos:
We also iterated internally:
Communicating technical challenges within our sub-team (and with teammates who had little experience with programming) was difficult at the best of times, and coordination across the wider group suffered for it.
We got into a rhythm by creating a global Trello board that the whole team, technical and non-technical, could follow.
The codebase was becoming increasingly messy and hard to work with as we kept iterating on the mechanic without a settled design.
It took extensive, dedicated work by myself and the rest of the developers to clean up, but freed up our bandwidth to develop faster.
Outcome
We performed extensive playtesting, recruiting friends and fellow students, and presented our updates at various milestones to panels of industry experts. We had the opportunity to present the game to representatives from Ubisoft, whose feedback let us take it even further, and as the course culminated, we presented our final build at Zynga’s Toronto office. We also showed off the game at Level Up Toronto, a showcase for student games in the city. People loved the game, and we even received fan art of Anni.
This project was a real turning point for me. Although I had built some small games and played around with Unity in the past, it was my first real foray into building a game as a team, and I found that I thrived in the environment. If I were to do this project again, there are of course many things I would change. I would test mechanics with paper or quick throwaway prototypes before committing them to the codebase (as I later learnt to do), and I would set up shared tools like our Trello board from day one, instead of waiting until our communication had already broken down. However, those mistakes taught me much more than if everything had gone completely smoothly, and they informed how I’ve approached every team project since.