Embedded Files
Lead Paragraph
Before starting developing our game, we had to figure out what tools we were actually going to use. This entry focuses on how we chose our game development tech stack - from considering different engines, to settling on Unity and C#, and finally setting up GitHub so the entire team could collaborate.
Motive
One of the first challenges we faced wasn’t about code or gameplay - it was choosing the right tools. Before we could build anything, we had to figure out how we were going to build it. This meant picking the right game engine, programming language, and version control system that everyone could realistically use and learn. It sounds simple, but it ended up being a surprisingly important part of the project.
The work done
We kicked things off with a suggestion from Ewan - he had prior experience using GameMaker and was comfortable working with it. Initially, that made a lot of sense. GameMaker is beginner-friendly and has a strong 2D focus, which matched our game’s idea. However, after looking deeper into GameMaker’s limitations, we found out that exporting a final build would require a paid license. Since we were trying to keep everything free and open for collaboration, that was a dealbreaker. We dropped GameMaker from the list.
Next up was the Unity vs Unreal debate. Unreal is really powerful, but it comes with a steep learning curve, especially when it comes to using Blueprints and writing C++. Unity, on the other hand, uses C# - a language more accessible to our teammates, as they learned Java in one of our modules, and that isn't that different from C#. Unity also has a much broader ecosystem for 2D game development. We also found more beginner-friendly learning resources for Unity, which made us chose it as our game engine.
Once we settled on Unity + C#, we had to make sure everyone on the team could actually start coding and contributing. Not everyone had used C# before, so I searched for a YouTube tutorial that introduced C# basics in a Unity-specific context. I also found a clean introduction to Git and GitHub, since nobody else in our team used version control before.
To get the ball rolling, I created a test GitHub repository and told everyone to clone it and push a test file. It was a basic setup - no advanced things like branching or CI/CD - but it worked, and it got everyone familiar with how we’d collaborate. Watching the repo come alive with initial commits was a good milestone and a nice morale boost.
By this point we also brainstormed on the work needed to be done, take a look at our professional whiteboard task showcase!
Lessons learned
Picking Unity was one of the best decisions we made - not just because of the engine itself, but because of the accessibility and ecosystem it brought with it. Everyone was able to get set up fairly quickly, and the number of resources available meant that even those unfamiliar with the engine could still contribute meaningfully.
In hindsight, I’m really glad we tested things early. If we discovered GameMaker’s export limitations after development started, it could have derailed the whole project. That experience taught me to not just look at how good a tool is for development, but how it handles shipping the final result.
Setting up GitHub early also paid off. While it took a few people some time to get used to staging, committing, and pulling, it ultimately allowed us to stay organized and avoid overwriting each other’s work. More importantly, it introduced everyone to team collaboration tools.
Google Sites
Report abuse