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…
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. 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.
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 (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.
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.
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:
Agreed, we need to be better than this, even if we have to rely on some method of properly enforcing it.
Agreed, just not in the specific way you’re suggesting.
There’s a happy medium here. hhyyrylainen seems to think administrative work isn’t worth it but you do need some of it.
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.