Hey guys so my 2 other of my buddies and I just graduated from college all with degrees in and or related to Computer Programming. The project I want to build is some what large but not like MMO large. We all would like to start a small company that builds games as a hobby with hopes to become a full time job but the moment it’s just a hobby as we all have full time jobs as programmers.
How can or should we split up the work so we aren’t stepping on each other’s toes. Would you suggest someone move to like a designer role and build levels and stuff like that? NONE of us are 3d modelers or gifted in that sort we are all Programmers.
What do you all recommend? All responses are welcome thanks!
I agree. Someone needs to assume the thankless role of final decision-maker / cat wrangler / project babysitter. It’s not fun, unless it’s the kind of thing you enjoy doing, but it’s absolutely necessary. This is different from a level designer role, though.
Give your team a trial run on the smallest game you can think of. Treat it like a warm-up exercise if you must. This will give you and your buddies a chance to settle into roles and work out your development pipeline, such as managing version control (e.g,. git), documentation (e.g., a wiki), and communication / project management (Slack, Trello, etc).
A game jam is a great idea. Do a week-long or month-long jam instead of a weekend jam. Weekend jams are so rushed that they promote bad practices, which isn’t the way you want to start your team off.
First ask for a refund on your degree. They should have covered at least the basics of collaboration and project management.
Most projects have plenty of space for three programmers to work without stepping on toes. If you are each working on different modular systems there should be no trouble.
Did your college education seriously not cover that? If it didn’t then it’s not getting people job ready, because almost all software is made in teams.
Anyhow…
The suggestion of starting with a small game is a solid one. Do something in a fortnight or a month to go through the process.
Are you at least using version control? Something like Git? If you’re not, start. It’s got a bit of an initial learning curve, but once you’ve stepped up that it’s indispensable and makes team collaboration so much easier.
Get some kind of task management process in place. Visual Studio Online gives you both version control and task tracking, and it’s free for small teams. Alternatively you can check out stuff like Trello, Hack’n’Plan, Asana…
Tasks should be less than a day’s worth of work each and with a clear criteria for “finished”.
Ideally you’ll give individuals tasks on different aspects of the games to minimise how often they need to work on the same files.
Once your team is making stuff, look into software project management methods and lifecycles. You don’t need to worry about this too much until you’re actually making stuff, though.
@NightwalkerStudio - Don’t get discouraged. I’m sure your degrees and academic experience are more than sufficient. The way I read it, you didn’t ask about version control and project management tools. You’re just asking if one person needs to assume the responsibility of lead game designer. And my recommendation is still yes. In some utopia it might be possible to have a completely egalitarian team where everyone has equal say over all decisions, but in reality eventually two teammate’s ideas are going to conflict, and someone will need to decide that you’re going with idea #1 instead of idea #2, or that you need to prioritize task X over task Y. I only brought up version control and project management tools in the context of completing a small project so you can get a feel for your team dynamics. Doing the small project, your designer might find that she/he really hates the role and just wants to program. Or you might find that one person is a great technical lead and another is an ideal art lead. It’s just a low-risk opportunity to figure out how your specific team is going to work.
Yeah, we’ve definitely interpreted the question differently. A bit more background on what experience is present would be great.
One thing to note is that “game design” and “(technical) software design” are different things. Game design is about crafting the experience a player has - what’s in a level, how the player moves, the rules of the game, and so on. Software design is about the high level plan for how the code will work and be written to make things work. I presume that in your studies you’ve had a reasonable intro to software design, but nothing on game design (because it’s way outside of the scope of the course).
Don’t let that discourage you either. I wouldn’t worry overly much at this stage about game design skill. It’s important, but again not until you’re building stuff. Don’t worry about it for your first (small!) project or two. Once you’re making playable stuff and getting feedback then start working on that in particular. The good news is that as trained programmers you’ll be able to make stuff more quickly than most beginners, which will lead directly to game design learning opportunities.
Along the way, you could start reading stuff like GamaSutra to get an idea of the kind of stuff people think about. I’m sure some others here could also recommend some books on the subject.
I’d recommend to have some time to agree upon a coding convention, and it might be a good idea to try establishing a code review process (using Gerrit or similar tools).
The idea is that, it is better to make every member of the project can feel any part of the code as their own. It is often the case that each developer has a slightly different types of ‘quirks’ in their coding conventions or approaches, and if they left unchecked in a collaborate work, it normally results in what can be called as privatisation of code or a module, which means they become reluctant to touch any code that they didn’t write themselves (because other modules use weird variable names, and such), and the codebase will eventually look like some patchwork rather than any coherent system.
Of course, making sure that they won’t step on each other’s toes is important and it can be achieved by proper use of a source code management system, and such. But it’s also important not to make too many ‘toes’ that only certain developer cares or feels attached to in a project. So, introducing a code review process or switching part of the code they work on from time to time can be a good idea in managing such a collaborative project.
After your first couple rounds of testing out creating things - you might consider bringing on another person who is actually into game design and a couple artists. Even though there is ample free content available for the first test runs, once you start working on that one cool idea - you are most likely going to want custom art.
But back to the designer - since you are all 3 programmers - I wonder if bringing in another person to perform design duties would be better than making one of you the chief coder/designer guy. More work will obviously get done if all 3 of you are doing rather than one of you planning and designing the work of the other two.