Three classmates and I have about 10 months to create a game mostly independently for an assignment. We have roughly one hour each weekday to work, and one teammate does not have a computer at home, so their coding time is limited to that hour. We can choose our programming language and engine; we were considering Unity, though Godot is also an option.
Our idea is a 2D or possibly 2.5D real-time strategy roguelike where the player controls a group of cells inside a body. Players would fight randomly selected infections and pathogens, improve abilities such as movement speed, cell-wall strength, and attacks, and progress through different organs or areas with region-specific enemies.
I have passed AP Computer Science A and previously made a small Visual Basic game, but we are all still fairly inexperienced. How realistic is this project within 10 months? What should we prioritize, and how can we avoid making the scope too large?
3 Answers
Treat this like several small projects that can eventually fit together. Decide on the minimum playable version, put it in writing, and make sure everyone agrees not to expand it until that version is complete. Art, sound, menus, enemy spawning, and gameplay code can be worked on in parallel, and free assets or very simple placeholder shapes are perfectly acceptable while the mechanics are being built.
Use version control from the beginning with a shared Git repository. Each person should work in their own branch or on clearly separated tasks, commit frequently with descriptive messages, and regularly pull and test the latest changes. A beginner-friendly Git and GitHub tutorial should be enough to get started, but keep the repository structure simple so learning the tools does not become another major project.
It is feasible if you control the scope and focus on making a small, fun prototype rather than a polished commercial game. A good minimum version might include one level, basic movement, a few enemies, simple upgrades, scoring, win and lose conditions, and minimal menus. Do not start adding organs, dozens of pathogens, or complex abilities until that baseline is working.
For a first project, 2D would be much more manageable than 2.5D. Unity and Godot can both handle it, but Godot's GDScript may be a little easier for beginners than Unity's C#. The engine matters less than choosing one quickly and learning it together.
That makes sense. We were leaning toward 2.5D mainly because we wanted an excuse to learn Unity, but switching to a straightforward 2D version may give us a much better chance of finishing. I'll suggest a minimum version to the group before we plan any extra features.
Build the smallest version that satisfies the assignment first, then expand only if you have extra time. Break the project into individual tasks and estimate how long each one will take. Starting with something simple, such as a basic menu or one playable unit, will give you a much better sense of your actual development speed.
The idea of separating the work into a minimum version and optional additions sounds helpful. We'll also look up a beginner Git workflow and set up version control before we start writing too much code.