Theres two ways that work for me. The easy way and the hard way. Easy way- Offer a robux bonus on completion of a big update. If they refuse or are unresponsive you can either move onto another project or you’ll have to go the harder route. If they go inactive or refuse to work for weeks+, lower their percentage a bit and tell them it may be reinstated if they start working again.
People react all types of ways, some quit and you have to replace them but others get a reality check and start working again. That’s why when I make deals I ensure that I put in “with updates” in my offer, because if you don’t then people may be caught off guard. Most people just take percentages because they think it’s a passive income revenue stream, but in reality that stream dies off unless people are contributing to updating the game.
Without updating the game the developer should still be entitled to their credit in description, but their percentage should be lowered to account for their replacement. When it comes to business and percentages of games, it’s betrayal to go inactive and refuse to work unless there’s an explicit reason.(dont believe the people who always have reasons to be inactive, talk to them about it and you’ll find out they’re hiding something or working on other projects)
I’d recommend showing the specifics of what people did during development. No developer wants to be the guy in the credits with “made a window” next to their name.
Like you said they are motivated by triggering that reward mechanism so that means payments on completion. That’s likely the only way to motivate them other than by showing them a really good icon and some ads which will make them feel better about spending time on it because they’ll think its going to be successful if it has a good icon(this is if they make a percentage).
anyways stop asking questions and start working with me @HoudiniDev
Just left my current dev team because I knew I didn’t fit in with the others (Not meaning that in an egotistical way, they are all talented people), this article sums up a dev team perfectly though!
This post is amazing! I was terrible at team cooperation and apparently failed at all the said points but this finally changed all that. Amazing post, I really appreciate it.
I learned a lot of useful things while reading the article. This is very good for beginning developers as they learn how to communicate with other developers. Thank you for the article.
We talk about everything. Not just development. Our work cycle is slow and not everyone is likely being used to max efficiency, but it works and noone’s really mad about anything.
I will give them extremely close deadlines, but that’s typically for something I know won’t take NEARLY that long when they’re already doing dev work or sitting idle. e.g. UI mock-ups, placeholder models, etc.
And it’s all give and take. Typically I only tell people what to do when I’m dependent upon it, and same goes for them.
Reading this made me understand that past relationships with developers was hard, beacuse they broke about 5 rules. No wonder I left development (No, I’m not giving out names)
