🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Issues with creative conflict for small unpaid team

Started by
25 comments, last by steelstrung 6 years, 6 months ago
3 minutes ago, Scouting Ninja said:

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:

  Hide contents

 

Artist: So for the underground city we make a huge steel door. (You like the steal door but want to remind them what the city atmosphere)

You: That is a good idea. But because the city is so deep underground(Pointing out where it is) and the magic mist (Pointing out a key design factor) you could work some rust into the metal from the moisture. What do you think?

Example 2:

Coder: So we make them walk on the map to this point, then what happens?

You: This is where they find the long path down to the labyrinth that is filled with magic mist. They will then have to navigate the hazy corridors.

Artist: What color is the haze? 

You: Light green and as it dissipates it should reveal the blue glow if the city. Like in this image: (Link to image)

 

See the whole time you need to guide and remind your team of the atmosphere of the game. Also use any excuse to get extracts from your design documents. Just the paragraphs that is important to the moment.

 

 

 

Perfect. That is pretty much exactly how I have been doing my brainstorming sessions and they have been pretty productive thus far. 

After I get this GDD revised I will definitely be referencing it much more.

Advertisement
1 hour ago, Scouting Ninja said:

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.

 

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.

Unless it is relevant in some way, there is no reason to worry about art details in a design document.  All that is needed from the designer in that regard is to set an atmosphere for the artists to work within.  They are the ones with a superior sense of aesthetics.  I don't even consider that to be a part of "design", although the design of the game can sometimes influence the art/look.  The more you have worked out ahead of time, the more the game will be like you wanted it too be in the end.

I'm not saying this to be annoying, just to point this out, but in the hobbyist game industry the phrase "design by committee" literally translated too "the worst possible way of making a game".  That was one of the most well-known mantras of that era.

 

"I wish that I could live it all again."

1 minute ago, Kavik Kang said:

Unless it is relevant in some way, there is no reason to worry about art details in a design document.  All that is needed from the designer in that regard is to set an atmosphere for the artists to work within.  They are the ones with a superior sense of aesthetics.  I don't even consider that to be a part of "design", although the design of the game can sometimes influence the art/look.  The more you have worked out ahead of time, the more the game will be like you wanted it too be in the end.

I'm not saying this to be annoying, just to point this out, but in the hobbyist game industry the phrase "design by committee" literally translated too "the worst possible way of making a game".  That was one of the most well-known mantras of that era.

 

I can see the merit in your words here. I fully agree that setting the atmosphere is important, and that the artists will likely have a superior sense of aesthetics (I am not a great artist myself, although I am learning). I would agree with Ninja though on the point that things you DO care about should be set in stone. Whether in the GDD or another medium, if I want the sky to be purple and stormy the artists should know this, especially if it is essential to fit in with the story of this particular area. 

So far I have not had much issue with artists' ideas, as they usually base their concepts on what I have already created in the wiki with the details I care about, but then again, there could be times when I have an idea for something, but it is not fully fleshed out and I later add edits when I work it out. 

For example, in this area with the purple stormy sky I added there are smokestacks rising from a part of the city that is producing the haze, and that the buildings are made mostly of metal for functional purposes.

I don't disagree with that, in fact it is even more important in the actual design of the game.  If you intend to do something different than has been done before, no matter what that is it will still most likely fall within an existing genre.  If you only vaguely describe elements of the game that you have a specific idea for how they will work, nobody but you will "see" that.  All they will see is how that genre functions, and assume that this game should and will work in the same way.  So you have to especially describe anything "new" very specifically.  If you don't, everyone else will assume it all works like all the other games within that genre.  Or, if you've only vaguely described how it will be different, then everyone will have their own idea of exactly how it will be different.

If you've done something like that well, it will probably all be linked together.  You might be doing a game that superficially resembles an RTS game, but that in reality is a very different thing.  And many of the aspects of how it will work are tied together.  They rely on each other and play off of each other.  They, in some cases, can't exist without each other.  So if one of those "pillars" fall, the entire thing collapses.  So when the "committee" later decides one of those things will work in some other way, the entire thing collapses. 

So the more unique the thing that you are trying to do is, the more detailed the design document needs to be for that to actually wind up happening in the end.  If you are making a Team Fortress-like FPS game, you don't really need a designer.  Or a design document.  Team Fortress-like FPS game or Starcraft-like RTS game really says it all, doesn't it?  "Design by committee" even works just fine in that type of situation, because everyone already knows what the game is.  You are just putting a different paint job on it.

"I wish that I could live it all again."

By the way, what do you guys think I should do with what he already contributed to the project? Since he never signed any sort of agreement or anything I guess I am a bit concerned it could become a legal issue later.

The only thing he contributed that I intend to use is a weapon mechanic he suggested. In the final product its not going to work how he described it, and only the basic idea of it is his, but the similarity is there. He had also put some reference pictures on the wiki for an ice area he found on Google, and helped a bit with developing one of the characters.

Not a huge loss if I don't include any of it, but I don't want it to bite me later.

45 minutes ago, steelstrung said:

By the way, what do you guys think I should do with what he already contributed to the project? Since he never signed any sort of agreement or anything I guess I am a bit concerned it could become a legal issue later.

This is always a problem.

First, when someone uploads the files to your project, there work automatically gets copyright protected by what is known as "the poor mans digital copyright".

If they worked from a concept that you designed and uploaded to them, then you own the IP but they own the copyright.

 

This is a problem for you even with content creators who are working willingly, because the only way to pass the copyright and IP legally is with a contract.

Sometimes a digital contract isn't even accepted. Then you have to send a physical contract by courier to have it signed. This happened once when the team gave the developer the assets for free.

Buying the assets from your team members makes things much easier, as most countries have some way people can trade over the internet. You can use this by paying a small amount for the work if the team member agrees.

 

So legally, you are actually borrowing the assets created by the others and they can remove them from the project at any time.

So deleting everything he added from the site would probably work best?

It wouldn't be a crippling loss, that's for sure, but it would I suppose it complicates things

On 12/16/2017 at 12:08 AM, steelstrung said:

So deleting everything he added from the site would probably work best?

Ask him if he would be willing to hand it over, then make a legal contract. If you can't make contact with him then yes it would be best. The last thing you want is to have him show up when the game is making profit and then trying to take legal action against you.

Chances are he will give it to you because if it's based on your ideas you own the IP, so he can't use it without your permission. Maybe allow him to use the content in there portfolio and in return you can use it in the game; that way you both get something.

 

Any person is allowed to leave your project, they aren't wrong for doing it and it doesn't make them a bad person. Dealing with these problems in a respectful manner will leave a good impression, it often happens that members return to the project.

 

With that said the person isn't the only one who is going to leave the project, you should have some way of transferring the files legally.

Getting legal advice isn't expensive and it helps a huge amount.

there are 9 billion people on this planet who can come up with ideas. and there are probably 10000 who can actually make it. it was a deadly mistake from you to beleive they will submit theyself below your absolutism, in fact you dont even pay for them and you are easily replaceable. make a conclusion, and accept the will of others next time. 

This topic is closed to new replies.

Advertisement