🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Frustrations from Working in a Team

A topic by Mantis created 5 days ago Views: 46 Replies: 3
Viewing posts 1 to 3
(Edited 1 time) (+1)

I guess I have to vent about this, but it would probably help to know I'm not alone and others have been in the same situation. (Not that I'd wish it on anybody!) I joined a team to work on what was originally a jam game, but they decided to rebuild it as something much bigger. I'm the programmer, but I seem to have taken the role of being a team leader. I don't like bossing people around and I try my best to be empathetic about things, but the rest of the team doesn't seem to have any organisational skills. That doesn't really matter with a 48-hour game jam, but with a full game if everything is jumbled about the game's progress is going to suffer. I take every single idea from the other members on board, and so we can choose something that's we all agree on we've run polls.

Sometimes my team has been very helpful and we've spend hours at a time discussing the game's development, and also watching films together (synchronised) with a similar narrative, as it's a quest/adventure. (Think like Phoenix Wright or Hotel Dusk in gameplay.) The thing with indie games is that everybody usually has different priorities and amounts of free time. It seems the rest of my team has plenty of their own and I probably have more hours to give to the project. That's why I set up a Google Calendar solution for us, and we all created our own entries with designated times to discuss what we're working on and plan ahead. The problem is, my team is regularly missing these times. I just don't know what to do when they're not showing up, despite them expressing their interest in the game.

If I keep badgering them to get to work on it I'll seem bossy and obsessive. If I just walk out on them, that's the programming out of the window. Hypothetically speaking, I could effectively "fire" them to find different team members, but since we agreed to work on it with equal ownership do I really have the right to do that? For every scenario I can think of, I'm the bad guy and it's a very interesting game I don't want to simply give up on.

Have you ever faced a similar problem? I think with no money incentive (at least upfront) a lot of people won't put their heart into a project. That's why I feel like just entering game jams for the foreseeable future where these issues aren't typically a factor.

Sorry for such a long thread, but damn, it feels good to get this off my chest.


In my experience that's pretty much what ALWAYS happens :P, either because the others don't have enough time or I'm the one that doesn't have the time the others need.

Finding a group of people with equal passion and dedication is the hardest part of creating a team.

Only thing I can think of to tell you is that if you really like the game, keep working on it, use pre-made assets for everything.
When you get it done maybe the others will gain enthusiasm again and work on it. If not then tell them that you'll proceed with other people and ship the game

That's a good tip. I've used some placeholder assets in the past. They can be hard to find at times but like you said, it's sometimes the best thing to do while programming a game. Thanks for the reply! :)

(Edited 1 time) (+2)

This is a problem I've totally run into before, and have been on both sides of from when I was a little kid posting in Usenet in the mid-1990's until today where I've tried on a few occasions to support groups doing fan games or open source games.

Basically, if you aren't paying people, then you are throwing a party, and if your party isn't great, people check out. Motivation, drive, focus are things you end up with by  accident, and when it's a group project it becomes very tempting to let someone else make the first move and not look like a fool. And anything you do might be worthy of extended discussion the first time you do it. Which in combination with large scope(which tends to inflate as a way of avoiding reaching a concrete and coherent resolution on any decision), makes things go slower, and slower, and slower, until everyone has given up. 

Plus it's easy to build a very flimsy kind of hype around the idea of "making a game" because games are fun at the surface, so lots of people sign up for what they hope will be a lightweight experience only for it to gradually sink in that there is a huge boulder to push up the mountain before the game can even resemble anything, and the things they thought they would work on and want to voice their opinions about are actually pretty simple decisions or only become relevant much later, while the majority of the work consists of blundering through the dark barely understanding how to move the project forward and learning new skills constantly to do so.

And even if you are paying people, this happens. Hiring people is a two-way thing in that while on a small team you would like for them to self-start and cover for you on many different fronts like intelligent automatons, the reality is that the average candidate will tend to hope that the job will be a straightforward fit to their very specific fixations and not require anything outside of that. Even more so when they're on a short term contract and already have the next gig on their mind - they may put on a brave face to pay bills, but no spoons will be spared to give your project special consideration, and if you let someone on who isn't up to it or is given insufficient direction, they crumble with anxiety and may be damaged by this toxic mix of obligations and inability to fulfill them.

And when put that way it becomes a little more apparent that team building is a kind of design process - you have to design both roles that you can fill and a workflow that puts those roles together in a way that does not blow up. Functioning game studios end up with a lot of overhead in the process because, as it turns out, what's acceptable for most people tends to be that mix of regular hours, a desk, bosses, meetings, and separations between "creative" and "business" roles. With all that stuff in place, the team can move forward and accomplish things even though not every member of it is a perfect fit or wholly engaged every day.

My solution has been to downscope to a project size that works for me alone and then fill in gaps by adding other people only once I think I have a clear role for them that doesn't cascade into "now you do all the work for me" - a lot of the fantasy of team building is that you just assemble the "artists/programmers/designers/writers" in a room and they automatically know what to do and how to resolve project decisions. Nobody does. Even if you've got motivated and skilled folks they will have blinders and bottlenecks. Even major, apparently better financed and organized stakeholders like publishers will fail at giving your project special attention and default to giving the low-quality, polish-focused feedback that you could get from any random player.

If you don't actually have the game done in any form yet I suggest rebooting it in a limited format that you can adapt from - the PICO-8, Twine or Bitsy version of the experience. Throw on as many limits as you can to avoid upscoping, even if it that means it becomes more like a mockup than a functioning game. If you can't finish it in that form, where the limits stop you from tacking on more stuff, then you don't have the game yet, you have an incoherent mess to untangle and prioritize. The team will have a much easier time seeing a working result and giving feedback on that than sitting in a long meeting going, "well, we could do any of these 50 things, let's keep all our options on the table."

Laatly, remember to mix group interactions with one on one interviewing. People share themselves differently in the two contexts and a lot of basic management issues can be resolved by going to person A and asking, "what's bugging you right now?" and then going to person B and saying "hey, person A is worried about X. Do you think you can help?" Because it will turn out that the communication just didn't happen before and they needed a go-between.