Hello all, 

I recently had started making a game and invited some others to join the team as well to create content and write some of the story. The group is small, and there is no funding currently.

The problem I am having is that I have a vision in mind for the game, but have some difficulty getting others to follow it - it follows certain themes and there are certain things about the world that cannot be changed without it being out of place or disrupting the 'feel' of the game. 

I have so far been running things fairly casually as it is still a small unpaid team, but there are some things I feel that can't be compromised on. Don't get me wrong, I don't want to stifle my developers' creativity and I welcome new ideas/changes (we have had several good brainstorms in the past) but I think there needs to be a line somewhere so the game stays close to this vision.

In this example, the game is going to be dark fantasy, and have a rather serious environment,  but I have a developer who wanted to add silly easter eggs in as 'comic relief'. When I asked for an example or something similar, he talked about how Saint's Row has some sort of dildo bat that you can use as a weapon in-game. This is very much something I did not want in the game and I had to draw a very firm line there, telling him we are not going to have anything like that (for the reasons above). He said something along the lines of "Well, I am going to put whatever I want in my level". Following that, I had a conversation with him where I told him that while he is in charge of that level, if it is out of place from the theme/doesnt fit in to the 'feel' of the game, that I won't allow it in the game.

The developer then told me I am taking things too seriously, I am thinking too far ahead, and it is not fun to develop the game anymore - he decided to leave the project.  I definitely do like to have fun working on this game, and value the input of all my team, but I think there are times when I need to 'get serious'

I am very compromising with a lot of the story and design aspects, as the team is small and unpaid, but do not want to see this game run wild and turned into a joke. I am close to the design and story myself, and consider myself to fulfill the roles of a creative director and project manager - along with a bit of everything else. In the past, when the game was basically a blank slate, I tried to gather people around to come up with new ideas, but there was little contribution and I am seeing much more involvement after I went ahead and created a foundation of the story myself. I do my best to avoid coming off as 'managing' but it has been unavoidable in cases like this.

If you have read thus far, thanks for staying with me!

My question for you all - What is your opinion on this, what are some suggestions you have to avoid this in the future? I have some people with great Ideas and conflict is inevitable.

Do I need to be more picky with/vet developers better? Is there something dysfunctional in how I am approaching the matter? How do you work with your content authors/designers/developers to resolve creative conflict, and where do you draw the line?

Note: Usually I let a lot of stuff go that doesn't completely 'fit the vision', and adapt to it, in order to keep morale up and not stifle others' creativity, but knowing the guy personally, I suspect he had wanted to have a lot more control over the project and I had a feeling that something like this would develop down the road which is why I wanted to nip the problem early on.

1. Get the vision out of your head and into a document. Anything you won't compromise on needs to be in the document. This document is to be visible to new team members, so that they know exactly what is expected when they join.

2. With the above in mind you need to more carefully vet everyone who joins the team. Ask what their motivation is, and make sure it fits with the project. Make sure you are able to offer what it is that they need to feel that their time is being spent in a worthwhile way, and if that can't be done, don't bring them onto the project. You can't pay them in money so you need to be able to pay them in some other way - e.g. the ability to express certain ideas. But make sure that is compatible with your needs.

3. Accept the fact that some people will leave. They won't like the idea that they do a lot of hard work but you get to make the decisions. Many will want more control over the project than you feel you can offer. That's their right to want it. You can't change it. Just accept, up-front, that there's no one weird trick to compel someone to stay on your project doing your bidding.

6 hours ago, steelstrung said:

He said something along the lines of "Well, I am going to put whatever I want in my level". Following that, I had a conversation...

Oh that was fun to read.

I work on lots of these teams and can tell you that no one is going to make a "dildo bat". The amount of work needed to make a dildo bat, the model, the physics rig, the textures, the collisions, the code and the testing is way too much to do just as a easter egg.

It's dam hard just to get the game development moving.

However working with others means that your game will change in ways you did not expect and have little control over.

My advice is take charge by doing more than anyone else. The more other people have to make design choices because you didn't the less the game will be like you originally intended.

So when your coder asks how the menu should work, you should be able to tell them. When a artist asks how a character acts in this kind of event, you should already know.

This is one reason for writing a design document that is more detailed than the ones you normally see.  It is the starting point that the other people involved with the game have then essentially agreed too before the project even starts.  Whether it is story, atmosphere, or specifics of the design of the game, you've established those things before others agree to become involved.  When it comes too the game itself, a detailed design document is the only way that "your game" will ever come into existence.  Without it you have "design by committee", you will "blindly blunder forward through trail and error, praying that things work out well in the end".  You will, in the end, wind up with a generic game of whatever genre it falls within that doesn't resemble the game you wanted to make at all.

Thank you all for your thoughts! 

@Kylotan @Kavik Kang - you bring up a good point with writing a design document. I had actually wrote one up far earlier in the project, but it seemed to get too lengthy. Perhaps now would be a good opportunity to revise it now that the form of the game has taken a clearer shape.

@Scouting Ninja - thank you again for your help. I have wrote probably a good 90% of the story/world so far, with the exception of the NPC's which I am not very good at writing. The developer who is working on NPC's so far has done a really awesome job and we have probably poured hours into talking about it. What sucks is that this guy is also close friends to the guy who left, so I think the guy who left will pressure him to leave as well. 

Reflecting on your thoughts here and @Kylotan's input from this thread, I think my path is a little clearer. Revisions to the GDD are in order, and I will also write up a short developer agreement which I will ask each new developer to read both of before coming on, agreeing to the rules that are in place, and being aware of the contents of the GDD so there is less gray area.

Thanks again for your thoughts on the matter, it was definitely a long post to read  

2 hours ago, Kavik Kang said:

Without it you have "design by committee",

I want to make clear that I agree with Kavik Kang to this point.

Design by committee is not a bad thing, especially if you are a new developer who doesn't have a lot of experience. After all this happens when others have to fill gaps you left.

By example if you did not care what color shirt a character wears then leaving it to the artist to decide is fine. If the character is wearing a uniform and the uniforms have some kind of color code then this should have been in the design document.

If you do not have the experience to make a UI, you can leave the full design to the UI artist.

So Kavik Kang is right, you should have covered all the details you cared about in the design documents and you should have made them clear to the team before anyone made there own choices.

Few people read the full document so guiding the game as you reach that point is important. The things you do not care about you are free to leave to design by committee.

13 minutes ago, steelstrung said:

What sucks is that this guy is also close friends to the guy who left, so I think the guy who left will pressure him to leave as well.

If this happens it happens. Just remember to get the legal rights for the stuff they made and to give them credit for there work.

@Scouting Ninja So right now I have several concepts of the game that I feel are set in stone which will be in the GDD. Things like shirt colors and the like I have not gotten to as of yet. Should these things just be added to the GDD as I go? It does seem like a lot of minute details that would really bloat that thing.

And regarding your edit - I did have a conversation with him and a few others in a meeting far earlier in the game where I did mention that what they would contribute stays with the project if they leave, but nothing was really put in writing. There was very little IP he contributed, and I am not sure if that will even make it to production

Just now, steelstrung said:

Should these things just be added to the GDD as I go? It does seem like a lot of minute details that would really bloat that thing

Do it as needed. For example create a document for the artist with this in but don't bother your coders with this.

There will also be things your artist don't need to known and such, Remember that the developer is the manager of the full team.

1 minute ago, Scouting Ninja said:

Do it as needed. For example create a document for the artist with this in but don't bother your coders with this.

There will also be things your artist don't need to known and such, Remember that the developer is the manager of the full team.

I think I have been using the wiki for this purpose. I have different article types for enemies, locations, ect, which I add detail to as I come up with it. This is my knowledge base of sorts for the game - would you consider this an effective method for what you describe? I write a lot of the articles but I do encourage others to edit as well, and revisons are kept like wikipedia

2 minutes ago, steelstrung said:

I think I have been using the wiki for this purpose.

This only works if you point it out to the team members and only if they take the time to read it. When ever a topic arises like a character you should work in your details into the conversation.

For example: