Three classmates and I have about 10 months to create a game mostly independently for an assignment. We have roughly one hour on each weekday to work, and one teammate does not have a computer at home, so their coding time is limited. We are considering Unity, although we could still switch to Godot or another engine.
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, upgrade abilities such as movement speed, cell-wall strength, and attacks, and progress through different organs or areas with enemies appropriate to each location.
I have passed AP Computer Science A and have made a small Visual Basic game before, but most of my teammates are still learning. How realistic is this project within 10 months, and what should we cut or prioritize so we can finish something playable?
3 Answers
Ten months is enough for a fun student project, but probably not enough for every feature in the original concept. Feature creep will be the biggest danger. I would strongly recommend making it 2D rather than 2.5D unless the third dimension is essential to the gameplay. Unity supports 2D well, and Godot with GDScript may feel a little simpler for beginners, but either engine can work. Pick one quickly and stop switching.
Define a baseline together: a main menu, one level, basic controls, a coherent placeholder art style, enemy spawning, combat, scoring or progression, sound, and clear victory and defeat states. Finish that baseline before adding more levels or complex upgrades. Split the work so programming, UI, art, audio, and design can progress in parallel, using simple original assets or appropriately licensed free assets where necessary.
Set up version control immediately so everyone can work on the project and recover older versions if something breaks. A shared Git repository with a clear branch or commit workflow is a good starting point. Have everyone learn the basic commands for cloning, pulling, committing, and pushing, and agree on who merges changes.
Since one teammate has limited computer access, give them tasks that can be planned or completed away from the computer too, such as level design, enemy and upgrade specifications, balancing tables, dialogue, documentation, or sketching UI and art. When they do have access, they can implement or test a focused task rather than trying to catch up on the entire project.
We will look into a basic Git workflow before starting so we are not passing project files around manually. We can also divide the design and planning work more carefully around everyone's available computer time.
It is feasible if you build the smallest version that meets the assignment first, then expand only if you have time. Start by listing every feature you want and identifying the minimum playable version: one level, one playable cell group, a few enemy types, basic movement and combat, a simple upgrade, win and lose conditions, and menus if they are required.
Do not begin with the full dream version. Estimate how long each feature will take, track the actual time, and use that information to adjust the plan. The first complete version should be playable even if it uses circles, squares, placeholder sounds, and simple UI. Extra organs, pathogens, abilities, and procedural generation can come later.
A working prototype will also show you which mechanics are actually fun before you spend months building content around them.
We were leaning toward 2.5D mainly because we wanted an excuse to learn Unity, but I think starting with a straightforward 2D version makes much more sense. The baseline plan should help us agree on what actually needs to be finished.