# Improvement proposal **URL:** https://forum.revolutionarygamesstudio.com/t/improvement-proposal/617 **Category:** Meta **Created:** [July 3, 2019, 8:30am UTC](https://forum.revolutionarygamesstudio.com/t/improvement-proposal/617 "2019-07-03T08:30:38Z") **Posts on this page:** 1 **Showing post:** 34
### Author: ![Oliveriver](https://thrivedevforum-cdn.b-cdn.net/user_avatar/forum.revolutionarygamesstudio.com/oliveriver/32/1962_2.png) [@Oliveriver](https://forum.revolutionarygamesstudio.com/u/Oliveriver) #### Post date: [July 4, 2019, 10:14pm UTC](https://forum.revolutionarygamesstudio.com/t/improvement-proposal/617/34 "2019-07-04T22:14:54Z")
Hoooo boy. First, I think we need to calm down a bit. We all want this project to succeed and for it to succeed quickly. Calling out others for their past decisions or tone won’t help that. I’ve just started my first job, a software engineer. Yesterday my manager gave me a rundown of how the decision-making and planning processes within this multi-million-dollar, continent-eclipsing development company work. I couldn’t get this thread out of my mind the whole time he was explaining it, because they kind of do things the same way we do. They filter suggestions from customers and the company’s marketing division, draft those into the next release plan, do their best to follow through on those features, test A LOT, and then ship that release. Features may be postponed into a vague idea of a “grand plan”, but they compartmentalise heavily. Somebody did sit down at the beginning and come up with a concept for the product as a whole, but they didn’t present the nuts and bolts and, with the product now largely in line with that initial plan and growing beyond it, development is very much done in the moment. Several major features have now been added that were never considered in the project’s inception. Obviously not everything works this way but it’s one example that demonstrates how planning isn’t everything, even in the corporate world. Even in places where they get stuff done. In fact… [![](https://i.ytimg.com/vi/rDjrOaoHz9s/maxresdefault.jpg "Fail Faster - A Mantra for Creative Thinkers - Extra Credits") ](https://www.youtube.com/watch?v=rDjrOaoHz9s) I mentioned in our Discord discussion that prototyping and having a tangible outcome is more useful than an amorphous spaghetti cloud of ideas. I forgot to link this video which is what solidified that point for me. For many years, Thrive was just a bunch of people on a forum coming up with whizz-bang awesome plans for their dream game and expecting someone with talent to come along and make it for them. [Articulated in less glowing terms by roadkillguy, the project’s one and only programmer at the time](http://thrivegame.canadaboard.net/t837-dear-thrive). I appreciate you’re suggesting a much more centralised approach to planning than ‘everyone and their dog submit[ting] ideas’, but even then we’re still just spinning gears without proper, tangible prototypes and testing (see video above). In 2013/2014, somebody realised that making a game actually involves making a game. Seregon, Nimbal and Daniferrito organised the codebase and cranked out prototypes, as you can see below. [![](https://img.youtube.com/vi/TfrwfH1KvL8/hqdefault.jpg "Gameplay of Every Thrive Release (to 0.3.1)") ](https://www.youtube.com/watch?v=TfrwfH1KvL8) Were the prototypes a game? Were they anything like what everyone had planned? Not a first, but they helped shape the course of the game far more than any of the “planning” from previous years. The control schemes, resource mechanics and visual style finally had corporeal forms that could be tested, critiqued and improved upon. A few years back, I saw the same problems you’re seeing and decided to take the problem into my own hands by writing a [GDD](https://forum.revolutionarygamesstudio.com/t/microbe-stage-gdd/77) (Game Design Document). I made sure to check in with everyone else and ensure internal consistency when I compiled the mechanics. I thought that was it, the game there on the page waiting only for someone to script it into existence. No one read it. Ok, well, people did, but they hardly stuck to it. Within a few months it was basically depreciated because I wasn’t around and no one else bothered to keep it updated. Then it was overhauled a few times by NickTheNick (the version you see today is mostly his work) but again, it’s not something the programmers actively look to when crafting mechanics. I personally think we should be using it more. Maybe I’m just biased because I wrote it and don’t want all my work to go to waste. Relying on it as the holy scripture of Thrive however is not the way to go. We have to try things out and, by trial and error, make our way forward. That’s how real evolution works, after all. HOWEVER… I do share your frustrations with how we organise each other in this project. Although product planning at my company is case-by-case and in the moment, there’s a very definite team structure and hierarchy with a frankly staggering focus on checking each other’s progress. Managers have managers have managers and all of them have weekly meetings with each other to assess what they’re working on, how well they’ve kept to deadlines and what risks there are moving forward. The issue with applying that to Thrive is simply one of manpower. Hierarchies are pyramid-shaped, and with only two programmers doing the nitty gritty work at the base, that doesn’t leave a lot of room for managerial overhead. Team structures typically arise due to the need to separate a growing team into more digestible chunks, which is what we’ve done throughout the years with the programming, graphics, sound, etc. teams. But no team has ever been big enough to warrant centralised organisation in that style. What I’ve decided we do need to do though is to keep everyone more engaged with their own and everyone else’s progress. People are here and they’re working on stuff but few ever notice. The open-source volunteer-driven nature of the project means a healthy development team requires a healthy community around it. If devs can’t appreciate what’s going on, there’s confusion and miscommunication and we end up in situations like this. If non-devs can’t appreciate the work going on, we can’t ever entice new blood to join. Simple as that. We absolutely need to catalog our own actions more. That means more forum usage, more regular check-ups with the team as a whole, more social media activity, more Devblogs. Maybe a weekly reminder to post a status update of your recent work on the forum if that’s what it takes. Over the years of watching Thrive go up and down I’ve decided the best way to motivate people is to act motivated yourself. And the best way to act motivated when you aren’t is to rely on discipline and routine. Untrustedlife made a devbuild a day for weeks if not months and he kept us in the loop about that, and that kept our spirits up. Yes, this is a volunteer project, but it is a project. It should be moving somewhere. We should be able to rely on people to do what they promise to do at least most of the time. I feel regular check-ins and tighter progress reporting are one way to ease us into that. Right, now I’m done with that rant, time to respond to a few isolated points. * * * > [@JoaoFilipe777](#): > > when some one leaves for some time almost the whole project stops This isn’t something centralised authority can fix. I was going to mention the bus factor until I saw hhyyrylainen already had. That is and always has been our weakest point, and giving more influence to individuals only risks making it worse. You suggest we have multiple co-leaders, but we already kind of have that with the project’s senior members and team leads. > [@JoaoFilipe777](#): > > I made an concept of website or new feature in the current website exclusively for devs, this may help the organization and communication as well as facilitate the contact with members, the new members will already know what’s going on and the members available can help us more effectively. I’m not really sure what the point of this is. Why do we need an extra contact channels? We’re not even making good use of the ones we have. If you’re suggesting we have some place with a list of current tasks though I’m in favour of that. See: > [@DonGororo](#): > > While is true that having an extremely detailed list of concepts and mechanics is too inflexible I’m happy with having a to-do list. For me it’s an easy way to kickstart my working schedule and I think it would be extremely helpful for new members. > [@JoaoFilipe777](#): > > In truth the forum it’s for “official” stuf or big discussions, announcements etc… But actually we use the discord for everything and the contact and communication becames a lot messy Agreed, we need to be better than this, even if we have to rely on some method of properly enforcing it. > [@JoaoFilipe777](#): > > it’s like an cycle, organization and planning creates an better and faster progress, the members sees the project moving forward, get motivate and get engaged with the project. Agreed, just not in the specific way you’re suggesting. > [@JoaoFilipe777](#): > > I think the time we use planning isn’t waste of time cuz it will speed up the developing project There’s a happy medium here. hhyyrylainen seems to think administrative work isn’t worth it but you do need some of it. > [@JoaoFilipe777](#): > > It’s like, how I told, shooting a movie without script, feels like we’re filming the first scene all by improvising and will it ends? > **[50 Greatest Improvised Movie Scenes](https://www.gamesradar.com/50-greatest-improvised-movie-scenes/)** > > Who needs a script anyway? Ok, but seriously, we have a script. It’s the GDD, or at least the part we agree on. And we’re filling in the blanks - improvising the bits we hadn’t planned - as we go. That’s how games get made. * * * Alright, I’m too tired to go on. I don’t even know whether I made the points I wanted to make. And as always I’m being very melodramatic. --- _[View the full topic](https://forum.revolutionarygamesstudio.com/t/improvement-proposal/617)._