You didnt talk to me, i’ve been around since 2013 and am one of the main programmers, did you talk to @hhyyrylainen ? Me and him are the main reason 0.4.0 exists.
1 Like
Actually I tried to contact you, if you want check at your discord messages, you didn’t aswered me… I talked with @hhyyrylainen, and I also talked with some others team leaders and members, I don’t know if I really need to mention everybody, cuz I talked to them in private so I would need their autorization…
all you did is ask me how the engine works and whether we should add procedural animation
Which i answered
“Man, I saw some YouTube post of you from 2015 or so, about Thrive… Are you the longest member on the crew or is there someone that is working on it since more time than you?” 27/05/2019
“are you the longest member” doesnt exactly scream “Hey man, do you think we should restructure the whole project”,
Im sorry i didnt see that.
1 Like
I wasn’t at my computer when this got posted, so here’s my a bit late reply, a huge post incoming…
After thinking about the points a bit, I think most of the criticism is towards the lack of structure inside the graphics team. As the programming team lead, I review all the code going into the game (master branch), and working with our game designer I setup the issues on github for the next release. Though, I did know that we don’t have many good tasks for new people:
Good first issues: Issues · Revolutionary-Games/Thrive · GitHub
Easy issues: Issues · Revolutionary-Games/Thrive · GitHub
That makes it a bit difficult to get into it. But we haven’t had new programmers joining recently. Though, some of the latest programmers to join haven’t gotten started well.
I think there is room for improvement here. One idea I have is that me or @Untrustedlife could mentor new programmers (even more than currently) through a few tasks to help them get started. That would basically almost be pair programming, the way I envision it working, so it takes a ton of time. Not sure how possible that is, but the truth is that we need more programmers to join and be productive. @Untrustedlife coming back to the project has been a huge factor in getting 0.4.0 and subsequent releases done.
Anyway, back to the lack of structure for the graphics. @Narotiza is the current graphics team lead, but he isn’t super active. At least I haven’t seen him comment much on the art things happening lately. Maybe we just need a more active graphics team lead who can set out tasks for the graphics team? As I said, I think the programming side is structured enough, we are just short on people doing work. Lean methods are a big thing in software development and I think they are the right choice for a huge project like Thrive, they allow us to plan one release at a time and then do a “sprint” towards it. I don’t think we have any capability to make long term plans that would stick. Even 0.4.2 is delayed because suddenly there wasn’t any programming being done on the game. That’s just a thing we need to deal with as long as we don’t have anyone working on the programming side full time or even part-time (Untrustedlife has a patreon, but that hasn’t reached a level where he could work on part time).
I agree with @tjwhale that any improvements to the way the game is made should be made gradually and fully aware that this is a volunteer project. I think the current way works quite well, getting graphics done is a bit chaotic, I admit.
Now I’ll reply to some specific parts I feel like replying to:
I don’t think it’s possible to know how a game will turn out in the end. It’s an iterative process. Overwatch was going to be an MMO but then Blizzard realized it was going to be bad late in development and they repurposed the world and characters into a shooter (or so I remember it going, I might have the details a bit wrong). My point is that even huge game projects can’t be designed up front, they need iterative feedback from the designers as the game gets implemented.
Currently only way to really know who is working on what is to check the discord and with programming also the commits as we aren’t really using the “assigned to” feature on Github very actively. It would take time to have some kind of list. I think it works well enough that I know what each programmer is working on and can say if someone is thinking about doing something that is already being worked on.
This is a concern. We need to collect information somewhere regarding how things work to lessen this impact. Also known as the:
I think we have a release process outlined on the wiki but it is a bit out of date.
The current process that has been followed for the past few releases is that we have a big discussion for a few days about which features will be included in the next release (this is the agile workflow which has been adopted by the software industry). I think it is perfect for Thrive. The downside is that if someone is not active (even after @everyone) in the planning process the ideas will be just left out. Someone could promise to champion ideas that people have submitted to alleviate this problem.
@tjwhale is our designated microbe stage game designer. So there is someone whose word is final regarding the design of the microbe stage. I think that works fine as is. @NickTheNick is the overall team lead but he pops in very rarely.
Would the sending ideas be open to the public? We have the community forums for people to talk about their ideas for Thrive. It is that way because a lot of the ideas are bad. It’s been that way for a long time that there is a separate forum. I try to be active there in order to reply to the community’s questions. I’d like some help with that…
I also answer many questions on our discord that people post. But the quality of discussion is even lower there. And the same topics get recycled many times. At least on the forums we can keep tell people to reuse inactive threads.
I think this is a very important thing. Thrive won’t survive if someone becomes a dictator and makes the project not fun for others (granted many software projects have a single maintainer who does whatever they want even if no one else contributes to the project).
That’s why the official workflow says, ideas should be discussed on the forum: Workflow - Thrive
The workflow still mentions slack so it should be updated.
I feel like this does not apply to programming related things. I offer comments on possible approaches. I also sometimes say that this is definitely the way something should be programmed.
It would help if people posted progress on the forums here and people could comment. Like the new planet pictures by @QuantumCrab would be a good candidate to share here.
I feel like this is specific to the graphics team (and also the sound team when @Oliveriver is too busy to comment on a new piece).
The early game should have major impact on the later game. Meaning that it is not possible to concretely design the later game before the earlier game is done. This is also related to the agile working method, which I covered earlier.
Even with the best project management you can’t make something with 0 available programmers. Right now there’s a huge bottleneck with the number of active programmers. With the graphics engine change there will be an influx of a ton of graphics work as many of the models were lost and the organelles will (likely) be able to use a full PBS material on them, meaning a bunch of material maps are missing for the organelles.
For reference here is the discussion thread:
Maybe it was closed a bit early (only a day passed before finalizing the selected features). But even then people didn’t flock in with their ideas, which means that the ideas are not made into issues that are then in the queue for actual implementation.
I think we should more freely allow discussion about the next 1-2 years on here (instead of really out there far off ideas which I think are suitable for the community forums) with a push then to get some features people want into the release planning process.
One can always hope that we can start raising a couple grand a month in order for me (or someone else) to work on Thrive full time…
I don’t think most people just are able to devote a significant amount of time to Thrive no matter how well the leadership structure is planned. Also pressuring people too much may lead them to leaving the team entirely.
It’s perhaps too convenient. I’d like to make an effort to have more stuff going on here. But many people don’t actively check these forums, so I think that pinging people on discord is a lot more effective for many things.
Relevant discussion:
I’d like more opinions about this. Should we also include non-programming tasks on Github?
Also I just remembered we have this for project management tasks (anyone is free to update it):
I agree that we should make the website more engaging. There is a link to email us there (I think) but only a few people regularly check the email…
This is the huge issue with programming, it’s very hard to get into a big project.
With the “do whatever” approach I think we can better attract people who are very interested in making their dream game (just ask @Untrustedlife about microbes)
So you are saying that we should decide on an art style? And we need a more active graphics team lead to enforce style and hand out tasks?
Ouch. I’m not going to rehash my previous posts about these topics, but we have a ton of working code, reimplementing things without causing a ton of new bugs that take a long time to work out, doesn’t happen. As I’ve gained experience I’ve realized that rewriting things is often not worth it. So that’s why we are stuck with a game engine that works the way thrive is coded. The previous renderer is just too difficult to use. The new one will be easier. They are also planning to release an editor that graphics people could use to preview and work on their models.
Issues with previous scripts will always happen, there’s always bugs and things to tweak.
Totally agree. Those things would take a ton of time from someone familiar with the project.
This is how we currently accept new team members.
has shown pretty conclusively that in a software project planning too much will ruin the entire thing. I’m not entirely against planning ahead, but I like agile software development where things are decided just a bit before they are done, it works very well when you don’t know what the finished thing is going to be.
You are underestimating the number of ideas (and terrible ideas) they would be bombarded with constantly. Even I have to take breaks from trying to reply to all ideas on the community forums:
Right now it is quite certain that if both me and @Untrustedlife leave at the same time there is no one to pick up the programming and the project has a high chance of fizzling out as it turns out to be incredibly difficult to find volunteer programmers (we haven’t had anyone new join in half a year, I think).
@Oliveriver and @tjwhale are probably the oldest currently active members. I joined a bit after Untrustedlife went away, so in total time being active, I think I have the lead on him.
I’ll just finish off with some random points:
- @lavathor’s title is now “Outreach person” because I wasn’t sure what the proper form for someone doing outreach is
- I think updating the titles of ex- or inactive members might be beneficial (if someone is reading through old threads).
Time spent on this post and not working on Thrive: a little over 60 minutes
3 Likes
I think huge isn’t big enough to describe it lol, but here we go…
Totally agree, that’s what I’m talking about when I talk about “more effective team leaders”
the same of the previous answer, “more effective team leaders”
Why?
I mentioned it on “the project almost stops when someone is out”
5 years of developing and less than 50% of the first stage? Can you imagine how long would take to the whole game?
Every project, from bigger to smaller needs planning before start to execute, why wouldn’t be possible to imagine the game? Is like imagine a movie based on the script, storyboard and concepts… We can’t truly imagine it cuz everyone it’s thinking something different about Thrive, cuz the already existing content it’s too vague.
Do you prefer waste a lot of time reading all the discuss in discord channels, checking everything in Github and doing a lot of things to know what’s being done or take some time to make an list that will speed up all of the following process?
This is made when we talk about simple things and details, for example Fortnite always has a new update changing the damage of some gun, adding a new feature, but never change his basics already settled, we haven’t basics settled yet so every new update change or recreate previous stuff and it is like walking on circles.
that’s what we need to have an fix plan, so we won’t be creating an recreating something a lot of times
If they are the leaders and directors they’re not effective enough, cuz we’re a lot messy…
By establishing different channels to contact the leaders for fans and devs would be better organized and we need some people to filter and organize this ideas into the Thrive basics, but we yet don’t have this basics and as Tjwhale said:
I see that there isn’t an leader to organize and stablish things, it’s everyone doing everything and everything needs to be aproved by everyone, I don’t wanna talk about politics, but the current organization it’s looking more like anarchism than democracy.
Me and other people talked about it many times in this post, this will not be some dictatorship, there’s a clearly difference between choose some people to be responsable for the game and choose some people to dictate everything about it and not receive ideas and stuff…
It is really followed? Cuz what I see is a lot of people saying their thoughts in the discord and the discord actually isn’t the best place to communicate with everyone, and a lot of the discussion on it is cuz we work on what people say and don’t following an original plan and concepts.
We have a lot of problems beyond the graphics artists that affect directly our whole progress, the renderer limitations for example…
As I told, every project needs some basic planning before start so the crew can imagine what’s dealing with and do something looking at some goal.
When I talk about organization and planning, I mean for the whole game and the whole stage, not only to next patch, as I mentioned it work with games that have his basics settled and only feel details are implemented, Thrive isn’t that simple game we should have an good planning before start creating stuff almost randomly to see what work or not…
I didn’t mentioned put the screws on the members anytime, I mentioned people don’t know what to do effectively, cuz we don’t have that plan settled…
Exactly, the forum, github and others way to contact the crew don’t work as it should cuz the main focus is only in the discord.
I don’t think Github it’s simple enough to contact people fastly, that’s why I made this concept of website or tab in the official website to facilitate and speed up the communication
If we have and only a few members use it then it isn’t working as it should.
“us” who, the whole team?
This way we will never move on to finish it cuz any game it’s perfect and everyone has a different standpoint about the game, it’s like put 30 totally different people to make an wedding cake without any sketch and planning, in the end it will look like Frankstein’s monter cuz everyone has a different idea of it and nobody think the same.
Not just it, and as I said I guess we have enough artists on it, but we need to stablish some fixed concept of Thrive, including gameplay, visual and etc…
That’s what happens without a planning, trying a lot of different engines to see what fits better, trying a lot of different renderer, codes and etc, if we had already settled it in a good way estimating every possible results we won’t waste that time walking in circles.
It will take some time, but it is worth it cuz will save a lot of time in the future. As I mentioned a lot of time the movie example, if we want to create an movie we gotta waste time writing it so we will not improvise all of it.
? I was talking about define the general directors, of course would be something more complex than to enter the crew, for example to enter the team I never mentioned how I think the stages would look like or the whole game, I just told my impressions about it and who I am basically.
Sorry, but this don’t makes any sense talking about such a complex project and that much members, it is like throw a lot of gears in a mecanism and hope it to work fine, but some gears will move faster than others and another will just move backwards, in the end the amount of conflicts will just break the mecanism.
Well, the ones who apply for this may be prepared, and that’s what I was talking about on “filter ideas” when they see terrible or impossible ideas won’t try to add in game.
So in the whole team there’s only two programmers?
I don’t know about you, but I would rather waste time choosing my next move than just keep walking and possibly get trapped. I really think the best thing to do it’s stop and plan before we move forward, if we keep moving the way we are we may/will never end this project…
Every project, from bigger to smaller needs planning before start to execute, why wouldn’t be possible to imagine the game? Is like imagine a movie based on the script, storyboard and concepts… We can’t truly imagine it cuz everyone it’s thinking something different about Thrive, cuz the already existing content it’s too vague.
This is made when we talk about simple things and details, for example Fortnite always has a new update changing the damage of some gun, adding a new feature, but never change his basics already settled, we haven’t basics settled yet so every new update change or recreate previous stuff and it is like walking on circles.
Are you not familiar with agile development?
We of course have a gdd which is our initial plan but things have “evolved” so to speak. I dont see us redoing much already finished work. We had to redo things for 0.4.0 because we moved t a new engine, but from then we have only been building on things not redoing everything. Unless said thing we redo has been decided to not have been the best initial approach ( GUI for example) The game play is essentially the same, and so we do have the same basic gameloop and its been around for years. So i dont know how you can claim “we haven’t basics settled yet so every new update change or recreate previous stuff and it is like walking on circles.” because that is simply not the case. DO you really not see how much we have refined the game since the initial 0.4.0 release? Or since we first released in general? We haven’t been walking in circles.
Do you not see that the gameplay loop has stayed the same (our basics) gather compounds->mitosis->editor->repeat?
What you seem to want is something closer to Waterfall methodology and i don’t think thats right for this project
1 Like
I think there is room for improvement here. One idea I have is that me or @Untrustedlife could mentor new programmers (even more than currently) through a few tasks to help them get started. That would basically almost be pair programming, the way I envision it working, so it takes a ton of time. Not sure how possible that is, but the truth is that we need more programmers to join and be productive. @Untrustedlife coming back to the project has been a huge factor in getting 0.4.0 and subsequent releases done.
@hhyyrylainen i’m okay with pair programming, we do it alot at my job. We just need to figure out a way to do it properly via the internet.
We changed our engine (which I don’t really think was a smart move), we are plan to change the renderer, we are recreating the organelles, also we are planning to rework the membrane cuz the creator left, and no one knows how to deal with it, and that’s just what I first remembered by now. Also how I told hundreds of times, the game is in developing for about 5 years and we don’t have even half of the first stage can you imagine how long would take to finish the whole game? This kind of development it’s really working? It is the best way to develop Thrive? We’re clearly in the wrong way, I’m trying to alert that cuz it seems kind of obvious, but sometimes I don’t know if you want to create an good game and do what is possible to do it or just insist in the same way that has been proved to be failing.
We changed our engine
We changed the engine and so we did have to redo stuff in that case. I think it was a smart move as leviathan is much easier to understand and i initially also disagreed with it.
we are plan to change the renderer
That is because @hhyyrylainen wants better lighting support which i am fine with as his reworks havent harmed the project ever And trust me you arnet going to change his mind we tried that already…
also we are planning to rework the membrane
I didnt hear anything about reworking the membrane?
Sure we want to add proper silica cell walls and such but i dont think that requires a full rework and i changed somE of that math for this release already thats why our bacteria look LIKE bacteria now
we are recreating the organelles
We are recreating organelle models because no one saved them. We arnet changing how organelles work, just making new graphical models, that is all and it would have happened regardless if those models were lost. That isnt development in a circle, thats new graphics We have a place to save them now so that wont happen again.
the game is in developing for about 5 years and we don’t have even half of the first stage can you imagine how long would take to finish the whole game? This kind of development it’s really working? It is the best way to develop Thrive?
Yes it is. Because it works when we have active programmers as evidenced by the last few releases since 0.4.0 Also the new way of developing was only just added when we started on 0.4.0 (When @tjwhale was given design lead development has been significantly faster since then)
EDIT:
Also yes, most of the programming is just me and @hhyyrylainen that’s probabbly the main reason it has been slow since 0.4.1.1, because me and @hhyyrylainen have been busy, but we are here, and i dont know how changing the way we design things would have an impact on that except maybe discouraging us, since that wont mean we will attract any more programmers then we have been attracting,. progress attracts and even with the progress that has been made its still mainly me and @hhyyrylainen unfortuntalely. Though @crodnu has done some neat things lately.
3 Likes
Easier and less powerful.
So there’s some communication issue, cuz everytime someone talks about deforming membrane, or something about 3d membrane we discuss about how is hard to change something in the membrane cuz his creator left and a lot of things…
Alright, I can’t do anything about it, I already showed all the pros and cons, if you’re not up to accept the change and recognize some obvious things, I have no way to do it for you… Anyway I would ask for some kind of votation to the whole crew about change the way we work and the way we communicate or keep everything as it is if this post don’t make any effect… I just wanna make sure I tried my best to help Thrive.
So there’s some communication issue, cuz everytime someone talks about deforming membrane, or something about 3d membrane we discuss about how is hard to change something in the membrane cuz his creator left and a lot of things…
Membrane deformation is harder, and to be honest im not sure its nessessary, none of our concept work has that except some newer stuff. I think switching from 2d to 3d will be a big leap and we need that for multicellular, but that would have happened regardless unless we had a 3d membrane from the beginning which we didnt. But if we need to do it for multicellular, i suppose w emay need to rewiork teh membrane, but it wont be working from nothing we have code already we just need to make it better. Also we could just make it a non-rigidbody physics object to get deformation. Our physics engine supports that. The only problem is displaying it.
Anyway I would ask for some kind of votation to the whole crew about change the way we work and the way we communicate or keep everything as it is if this post don’t make any effect… I just wanna make sure I tried my best to help Thrive.
We definitely need to improve communication, i agree with that bit, however i think on the design side we are in good hands.
, I already showed all the pros and cons, if you’re not up to accept the change and recognize some obvious things, I have no way to do it for you
Being aggressive and claiming things you see that others dont are “obvious” is not how you get people to agree with you. And im not a fan of the way you are talking down to me here.We are all voluneteers be civil.
Can you show me where I was rude, lied or offended you? If I made it I’m sorry. But what I told was only the truth I mentioned obvious things and you said I’m wrong, working 5 years in a game and haven’t 50% of the first level seems fine to you? I’m being polite and talking to you in a civil way how I should… I’m sorry if you somehow get me wrong.
I did backseat programming using the discord share screen feature where my friend would almost basically just type in what I said into visual studio. It wasn’t the best as he isn’t really a programmer so I had to go almost letter by letter instead of helping to understand what to do on a higher level.
1 Like
A couple of points before signing off until tomorrow.
It sounds like there isn’t a lot of appetite in the team for a large scale overhaul of how things are managed. I like agile too and I think the systems we have now suit the volunteer nature of the project.
In terms of you Joao if there’s stuff I can do to help you feel more comfortable in the team then I’m happy to help (I think the others would probably say the same). So building some more structure to how the art team is managed could be a nice move. Also I’m happy to look at any concepts or ideas you have and keep you in the loop on when the decisions are made about the next patch (it’s just when this one is released).
Thanks for your other feedback, it’s been interesting to think about.
2 Likes
Before that there was a custom engine directly in the thrive code base. There’s a bunch of more features now after the switch.
I’m not planning anything regarding that. I’m going to let it be just the way it is until it needs to be improved.
@Untrustedlife said it well that we are doing an agile project. In software development the amount of work that keeping a grand plan up to date, is a huge time sink and the industry is moving away from that. I guess you need experience from a software project to really get why agile works so well and how it can work perfectly fine with a slightly hazy overall plan. We do have an overall plan for what the stages are, and some things they will include. I don’t see a need for a huge game design document to be made.
And even if there is a need then who is going to spend a lot of time first writing it and changing it every single time after playtesting we find that some feature is just not fun? I won’t be wasting my time on such a thing.
As I said, I think the problem is that there is some chaos going on in the graphics department.
I’m not going to volunteer for that. It’s a lot of work to constantly reply to fans. I don’t think many other people would either take that position. That position also would need someone very knowledgeable about thrive so it can’t be easily filled by getting some new people on it.
So you actually agree that changing the renderer is a good move?
And we have a very rough plan. Btw if you read the community forums you’ll find a ton of feature suggestions some of which I reply with basically “if it exists on Earth it is a candidate for inclusion to the game”. We aren’t making some defined product we are trying to sell. We are making the most ambitious evolution game. And it’s going to take a long time. Even if we had a huge team.
Thrive has a ton of existing code. This is not about just randomly trying different things. This is very carefully done in order to have long-term success with short term rewrites of part of the game.
Agile actually works. You just need to have a backlog of work for each team member to work on after they have finished their current task. Which is not currently happening with Thrive due to the programming bottleneck.
As the game is going to have a ton of procedural content, having a ton of tasks for the later stages related to graphics, may result in a ton of wasted work. That’s why it is also difficult to plan for the future as we literally don’t know if something is possible or not. And that’s the way a software project goes and it needs to be taken into account in the development method that is used (agile).
You have some good ideas that would definitely improve the project, implementing them would take away time from other things (other than graphics people sorting out their team lead, choosing an art style etc.) So I’m not going to volunteer to set up any of this, other than trying to see if I can get any of the newer programmers started on something.
2 Likes
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.
5 Likes
On phone, sorry for mistakes.
So first, I’m putting my money where my mouth is.
I was thinking about minecraft, how successful there are from a small start. One thing I love is thier weekly updates, called snapshots.
What if we did a summary of "progress " or things people have done. We could do this werkly, bi, or montly. I would be willing to check in with team leads/groups and organise it as part of the outreach group. Something we could post somewhere.
I think it would also help people to know thrive isn’t dead.
Just a suggestion im willing to try. But if not no skin off my back.
2 Likes
Honestly, how I mentioned before, I noticed this post won’t get nowhere and won’t result in any change, a lot of stuff you said above I already answered and explained more than one time so I also don’t want to write an bible answering or explaining for two or three times the same thing, I also don’t want to, like happened with Untrustedlife, make anyone feel opressed, so that’s why I won’t be replying anything isolated here and just tell my general thoughts, the thing is some people know we’re moving in the wrong way and want to change it, some changes may be effective or not, cuz how I mentioned the main problem about communication and organization isn’t something we solve by telling “there is this link”, “this is already existing”, “here is the website”… The information is diffuse in a lot of places and links, I can almost garantee you that the most of the new members won’t waste days reading tons of forum, github and discord discussions, not even I made that, I did wasted a lot of my time for some weeks studying all about Thrive, thinking in some solutions for some problems and how to bring it to everyone, I searched a lot in forum, websites, wiki, discord, and a lot of another places and even this way I couldn’t find enough content about it so I asked for some members and I’m still discovering new things about the whole project (game and developers team) and I guess it wasn’t the smartest move of my life cuz I didn’t know that for some the project is moving fine…
Summing up, I guess I really wasted mine and your time on this discussion, like hhyyrylainen said: “Time spent on this post and not working on Thrive: a little over 60 minutes” Well, some people has some different opinions and looks like stop and plan isn’t really what we (Thrive developers) do… Well, that’s it, I guess there’s only one last thing I can try to do before I give up on this idea… By now the post has 212 views, 40 likes and 8 users, I don’t really know if we have listened to everybody and I also guess very few people would enter this discussion by now, I know there people discussing here was team leaders and the longest people of Thrive, I would just ask permission to open a new forum post about this discussion not for discussion, but for voting, so the members can see the post, vote on each idea thinks may work better and we can choose what to do or not on it, or even just for see what people think about it, so this voting post would be “Change Thrive developing process or keep it the way it is” And each side would have his arguments so the members can read it on post choose some and tell us why, I don’t want to restart this discussion so I also would add the link for this topic if someone has something to add… Can I do it? And if yes please write below the arguments you used on this post about keeping it the way it is so I can copy the arguments and put on post without tendencionism “making it more interactive”, “making it funnier”, the links of developing techniques you defend such as “agile software development”, “stop the current work to plan may delay the progress”, “developing a game is really an slow thing so we’re moving fine…” and other things you said to defend the idea of keep the developing the way it is.
My arguments would be the ones I already showed up here, explaining our current situation, the issues I see on it and the way it I think it may be improved…
I think voting is the more democratic way to decide it as it affects the whole project and the whole members…