Development Working with others

[chefdez]

Hello everyone,

What has your experience been working with a team? How did you conclude what the design choices will be? I am interested in the perspective of the programmer however more perspectives will be very insightful!

 

[Yal]

Almost every indie project team I've been in so far has been a total failure.

Here's mistakes to avoid:

• Getting lots of team members in early, then not giving them any meaningful work. This just makes everyone leave, and then when you need them you can't get a hold of them (or they're busy)
• Not having any sort of project management tools to make sure you keep track of what everyone's doing. People drop out, forget things, or are busy with other commitments. This is especially important when you have a lot of dependent tasks (e.g. you can't make the cutscenes before you have the voice files recorded, and you can't record the voice files before Jerry finishes the script) because if ONE person messes up, everyone else suffers. At the very least, have regular scrum meetings and a kanban board so you can keep track of what's happening (and more importantly, what's not happening)
• Have separate "ongoing discussion" and "final" information repositories - it's a pain in the dèrriére to try to find that cool idea someone had in a Discord server 4 weeks later. Whenever something important is decided, put it somewhere it's easy to find.
• Don't have a million different overly specific channels in your project Discord server - one of the big failures I was involved in had, among other things, separate channels like "normal enemies", "minibosses", "big bosses", "battle graphics" and "areas", so every time someone wanted to discuss enemies, you'd need to try checking at least four places to see where the most recent discussion was, and chances are you'd end up having to jump between two separate discussions constantly once people started finding the active discussion (assuming they ever found it, of course). It was as disorienting as is was unorganized.
• At least one person in the team needs to know a proper versioning tool (e.g. Git). It gets much easier to share progress if you all use the same version of everything instead of sending unmarked files around haphazardly.
• If you're an "ideas guy", study some basic programming, visual design and music theory so you have an idea about what's possible and feasible in each field and can also have an intelligent conversation with team members of every field. If you can't tell a team member what you want them to make, the chances you get what you want are pretty small.
• Have a main GDD (Game Design Document) where all the absolute truths goes. Make sure to define every term/strategy/rule in exactly one place whenever possible (because otherwise the two definitions will deviate and people will use their own version of them; this can lead to very insidious problems that get spotted way too late).
• Last but not least, figure out the right balance between planning and doing stuff. If you plan too much, you'll get less work done and run into problems if any part of the plan fails. If you don't plan enough, you don't know what to do and thus will not get anything done. The right balance depends on what you're doing and the team members' tastes and cooperation skills so you'll need to experiment a bit here.

 

[chefdez]

@Yal
Thank you for that, I recently joined a game jam with 2 others and I was wondering about how I could approach it. Fortunately the jam went well these last few days and we did release the game on time. I agree with a lot of your points, especially finding a way to communicate with all parties. It does require context of the subject matter, at least the basics. One of the issues I ran into was organization of files, I am not sure how to use Git to make this process much easier for a team but I will look into this.

As far as a GDD goes, I have never created one because I mainly focus on game jams in order to test my skill under pressure... although I'm new to game design it doesn't sound excusable. I will have to study this process as well, but how iron clad are they exactly? I would imagine it's difficult to plan out exactly what a game will be from the very beginning.

 

[NightFrost]

Yeah, GDDs. If you're solo working on something like a 3-day jam project with sparse mechanics, your GDD might be more like an ideas list, or if you've a clear vision from the start you might not need one at all. But if you have a team on it, writing down a GDD lets everyone know what the design goals are. Working on a more complex and larger project, even as solo, not having a clear GDD where everything is planned is setting yourself to failure or at very least constant setbacks as you rewrite code. When you have multiple interlocking systems, for example an RPG that requires mechanisms for quests, items, characters, dialogue, UI, cutscenes and whatever else, it is essential to have planned all out or you're constantly redoing old code to make new pieces communicate with others. In a team, every coder needs to know what the code they write needs to produce and how it interlocks with other systems. Same goes for graphic and sound design. Version control like Git is pretty much the only way a team can submit code to a project in sane manner... Most of my experience in coding in a team is from work though, but in web development a design document is essential. (Doubly so as it becomes part of the contract with the customer, and you can then pull it out and say, this is how we agreed to do it.)

A GDD goes along with communication and tracking progress. If the team doesn't communicate or do updates, it is like trying to steer a ship in the dark. You don't know where you are, where you're going, if you're going, and where the icebergs are. You realize you're the helmsman of Titanic.

 

[Yal]

something like a 3-day jam project with sparse mechanics, your GDD might be more like an ideas list,

Actually, basically all my GDDs fit that formula. I'm a very abstract, top-down type of person, so I prefer starting with a high-level concept and then breaking it down hierarchically until it's obvious how to code it. It's not perfect for all types of problems (it's easy to get a bunch of disconnected monolith concepts instead of a big interconnected blob of systems) but it's very easy to adjust the level of detail depending on how much you know at the moment with it (which is perfect if you're like me and make everything up on the fly).

 

[Sybok]

I struggle in a team. The intentions always start out great, but then when the excitement wears off and the dusts settles, it’s not so fun. It becomes too much of a day job for me then. I’d rate her work on things at my own pace, when I like.

As tempting as it is to take up ’team’ offers, I have to be realistic with myself and decline.

 

[chefdez]

@NightFrost @Yal
Thank you for bringing the importance of the GDD up, I've decided that for my next game I will be writing one in order to increase my skill in GD. I've taken note of your suggestions on what it is and how to use it, if you would like to add anything else then please do.

On a similar note, I had a conversation with a friend of mine that I made a few games with already. As an artist he said he was uncomfortable creating art when he is not certain what the game will be and look like overall. He said it would be more suitable to look at another game or deviant art game mock-ups and decide that this is what the game will look like from beginning to end. Is this an accurate approach that artists take when they are deciding on a style - and should the GDD include details about stylization, such as GUI, art style, etc?

@Sybok
I respect your opinion! I'm not much of a people person myself but I have great respect for people who are focused, they make for interesting conversationalists and sometimes excellent colleagues. Personally, I would like to cultivate a team of people around me and make fun games - and in order to do that I have to focus on my people skills as well as programming.

 

[Yal]

Is this an accurate approach that artists take when they are deciding on a style - and should the GDD include details about stylization, such as GUI, art style, etc?

A lot of artists have a distinct style and anything they'll make will be in that style, but it's common to compile inspirational images into a thing called a "mood board":
(timestamped example - jump to 5:24 if the timestamp doesn't work)

Having keywords for what the overarching design should be could help bridging the gap if something unforeseen needs to be designed - something like "rusty jugend" would describe the general design in Bioshock, for instance.

 

[RefresherTowel]

Every team I've been a part of has died a slow death at some point (the sample size is small but the results are consistent). I think, to have a serious team that works properly, money has to be a big factor. I've always done revshare agreements and people...well people have lives. They got bills to pay, they have family/social circles taking up their time, they get bored, etc. Unless you (or whoever is leading the team) can afford to at the very least pay minimum wage to each person in the team, it's very likely that any work done by any members will be done in their own time, if it gets done at all. So save up $200k or something, I guess? Lol.

It might work better if you are actual RL friends and can meet up/already regularly see each other, as the social pressure there might be of some benefit (or it might kill the friendship when one person hasn't worked on anything and decides the least awkward thing to do would be to simply not meet up face to face anymore, lol). But I've never had any people that I know who have a skillset that can be applied to games, so I have no real idea about that.

I think unpaid teams are much better suited for game jam style projects, where there's a burst of activity for a week or so and then everyone can go their own separate ways. Knowing that you've only got 2 more days of putting all your free time into a project is much better mentally than knowing you've got another 6 months or a year.

 

[Zizka]

Pay people.

I know, I used to be a big advocate of rev-sharing but after a dozen attempt I can tell you it never worked for me.

Salary more or less insures loyalty and dedication, there’s no avoiding it in my book.

When hiring, don’t leave anything to interpretation, explain in depth to the very details what you’re looking for to avoid any misunderstandings and possible conflicts and screw ups.

I spend my own money to hire people. I’m poorer but happier, it’s worth the investment.