Thrive Task List

On Nick's request, here's the list of tasks for Thrive we should aim to complete in the near future:

• Complete developers/newcomers split - This will involve the separation of the two groups based on the issues discussed in the previous two Devblogs. So far, only a few users (and those newly joined) are classed in the newcomer, or fan, category. The moderators will have to do the work, although others are free to suggest their own ideas as to what the parameters are.
  
• Create and organise separate developer groups - Leading on from the previous point, the developers list will then have to be split into separate user groups based on the sections of development a user is, or was, involved with. The groups should effectively be used as the game's credits, so older members who may have left but were crucial in the creation of concepts or other progress should still be added. So far, the possible groups are: art, music, programming, outreach and science. If possible, users may be added to more than one if they have contributed significantly to several aspects. Once this is done, it may be a good idea to appoint a team lead of each group, as at the moment team leads are only nominal statuses. If we want a more organised and concrete team structure, a team lead for each group who can report back to ~scio and Nick (possibly via the developer Skype chat) for their team's work is a good idea.
  
• Move current website and other assets to a Thrive-only server - This has been bugging me for a while, as currently the website is hosted on a server only I have access to, meaning all assets uploaded must be done by me, and I'm not always available (and neither am I the best at understanding the use of SQL databases, as Dani will remember :roll: ). The server will inevitably cost quite a lot, so if necessary it could be the first use of a donation system for the team.
  
• Finish the updated website - This ties in with the previous point, but the use of a more integrated website system has been in the works now for a while. Jacob (WJacobC), would it be possible for you to work on that?
  
• Contact Quasar for a joint podcast - As stated here, Quasar's proposal to do a joint podcast with us has so far yielded nothing. Firstly we need to contact him, then work out the logistics of when it's actually possible to do it with the most people present.
  
• Start work on shorter development updates to post to media outlets - If we can't get the full podcast done sometime soon, shorter but more frequent audio development updates will be a good substitute, and I suggest we strongly consider doing them anyway. The ModDB page hasn't been updated in a while - the same with Facebook, Twitter and YouTube - so there'll need to be at least some small-scale outreach work done to make sure everyone knows we're still here.
  

When I originally posted this list to the developer Skype chat, I estimated it should all be done by the end of February. Obviously I had underestimated quite how long it would take, but I'd expect most of the above to be complete by the end of May. Of course, this list doesn't take into account the programming efforts, which are unfortunately now being done by a one-man programming team in the form of Crovea.

Oliveriver wrote:

Move current website and other assets to a Thrive-only server

While I don't have much actual experience in server acquisition and management, I do know the foundations and am fluent in SQL, so if you need my help, I'd be happy to.
This will also help get the game assets moved away from Nimbals server where they currently reside (Nimbal unfortunately left the project for now, for those that didn't know).

I think the project needs this to progress further, especially organizing the developers groups i feel like every contributor has too much freedom now everyone's personal preferences leads to different styles of...everything loosing the focus on the main idea although the concept is nearly completed.
 Little off-topic what do you guys think about having each hex of the cells have some freedom in movement as then when cell bumps into object won't be stiff as rock but deform a little more bubbly.
Edit: Thank you for the reply crovea.

It is indeed off topic, but I'll leave a quick reply to you.

Quote :

a little more bubbly.

The current look of the microbes are temporary and does not reflect the final design. They look like this as it was an easy way to make a procedural body and getting the game started without spending too much time refining graphics yet. Programming soft bodies, as they are called, is a difficult and complicated process that we will get to.
Here is a rough sketch I just did yesterday of how things could look in the future: https://i.imgur.com/qnvZlKU.png

Since this is probably the last time I'll have a lot of free time for the next few weeks, I'm intended to get to work on a few of these things this weekend. I've already drafted my idea for the development teams and who should be in them (as I've posted in the dev Skype chat) and I suggest the other mods and team leads do the same so we can combine our ideas and, as Tritium said, become a little more organised. It's probable I'll be able to set up a new server for the website and transfer it over, which will hopefully be a welcome burden off my shoulders as those who actually know what they're doing can use it. If it's alright with everyone else, I may also contribute to contacting Quasar (slightly off-topic, but he posted something about Thrive somewhere recently, so he's certainly not forgotten us).

I completely agree that we should start to think about a donation system. That way, people who can't necessarily contribute to the game can still help it progress by donating.

We are to stubborn to change our vision on donating, sorry. ;p

Speak for yourself, but I think that a donation system for maintaining servers sounds fine, unless anyone has any objections.

We might also want a donation system for advertising the project I may point out. It would be a good way to attract more coders.

WJacobC and I were actually discussing a server and the donation system yesterday (we're also hoping to bring it up in the dev Skype chat today), and we both agree with Nick that this is a justified first use of any monetary input. Advertising, on the other hand, I don't think is necessary. As we've already seen and can be seen all over the internet, almost anyone who finds out about Thrive is itching to spread the word. It hasn't exploded yet (with the exception of last year's Reddit post) only because the game is unlikely to appeal to the average person in its current state, and we're trying to temper advertising efforts as a result to prevent potential interest from being turned away.

Oliveriver wrote:

...prevent potential interest from being turned away.

So, another potential interest just got turned away. Since I pretty much agreed completely with their reasons, I started thinking again about how this project isn't organized the way a large, efficient, easy-to-develop-for open-source project should be. So I started looking around for a manual of sorts, since open-source hackers have a habit of figuring out best practices. And I found one. After reading just a few chapters into it, I am convinced that the mod team, and anyone else who wants to help fix all the process issues we have, should be reading this and other works similar to it.

One of the more striking self-evident truths I've found so far is the idea of communities of practice -- and the contributor community being the most important, without which the other communities will stagnate and die. Oliveriver can attest to the fact that we've managed to cultivate a community of practice over in sound development -- people can feel comfortable posting their music and talking technical about it; getting useful tips, growing in their skill.

However, in terms of programming, we quite obviously don't have such a community going.

One reason why is that past efforts to get programmers have focussed on acquiring people, one by one, and kinda just throwing them into the project, and telling them to read a bunch of threads. Threads, btw, may be good for discussion, but are quite a bit worse for getting information, since one must sift through many posts to figure things out, but that's beside my main point. Anyway, the thing is, acquiring people one by one while we're still getting on our feet with regards to the whole project organization and not scaring them away will just scare them away.

What I suggest we do is first educate ourselves on good open-source project/community management, and then we'll start posting in some appropriate sections of appropriate open-source development forums, ones containing loads of people just raring to help a project get on its feet, and introduce our project as one that's just been a fantasy for a long time, has had several false starts getting actual development going, is in the middle of another start, and might die again unless we find experienced people that can help us get a proper open-source community going. If people come here expecting to see a train wreck and expecting that they'll help fixing it (since that's why we'd be inviting them), they're much more likely to stick around as we pull things together.

Oh, and on an unrelated note, the book also notes that we shouldn't mention our competition, it's unprofessional. Honestly I'm surprised nobody's noticed before, all our references to being a better Spore reflect poorly on us and we should really cut them out.

Oh also, would it make sense to move almost everything to the archive until its pertinent? Then people showing up will get less confused by all the old threads, focus can stay on microbe, and the disturbing amounts of necro-arguing can be swept under the rug until later.

This leads me back to something I mentioned a while ago to just the mods and team leads but is still present and will continue to be until we actively do something about it. Even when considering whether to reply to this post, I felt like I could probably put it off, or that someone else could do it better. Procrastination seems to be a large problem at the moment, at least if everyone else is looking at this the same way I am.

Weighing up the worth of doing something now when there are no deadlines or obvious problems as a result of not doing it often leads to the same conclusion. I say obvious, because in fact the procrastination tends to compound, with others waiting to reply until someone else has, or being disheartened at a lack of activity and discouraged from contributing. Of course, if someone physically can't contribute something as regularly as the rest of us would like, then we can't place blame on them (~scio's activity, for instance, has dwindled due to university, but there's nothing we can do about that most of the time). As a project made in people's free time, we are getting somewhere, just insanely slowly because it doesn't require any concrete involvement. Should we ever get to the multicellular stage with a fairly well-received microbe stage, the publicity, recognition and increased expectation of others might help drive us towards collectively working more, but until then the problem still persists and may prevent us getting there in the first place.

So I for one am going to get reading what you linked. I have actually been doing a little research into game development in general recently, and the consensus doesn't seem to be promising for a project of this scope (as if we didn't already know that), but there are a few ideas we can take from other forms of game development to help.

moopli wrote:

Oliveriver can attest to the fact that we've managed to cultivate a community of practice over in sound development -- people can feel comfortable posting their music and talking technical about it; getting useful tips, growing in their skill.

A forum like this, while unsuitable for programming as you explained, suits music production quite well (probably why for a long time it was the majority of what was made here . . . or not as we may have later found out). Compositions are made by a single person as compartmentalised pieces to add to the game, and generally don't require much collaboration save for the decision over whether a theme is suitable for the game.

moopli wrote:

has had several false starts getting actual development going, is in the middle of another start, and might die again unless we find experienced people that can help us get a proper open-source community going.

I don't think this is something to look at as too much of a problem. The false starts we've had have shown strategies, game mechanics and community management methods that aren't viable, making the game better in the long run. Without them, we'd probably still be running headlong into a game where the player plays as molecules before microbes  :pale: . . . yeah, I found that on a Spore thread recently and was genuinely impressed that we never went down that route.

moopli wrote:

Honestly I'm surprised nobody's noticed before, all our references to being a better Spore reflect poorly on us and we should really cut them out.

It also attracts those who still like the creative freedom of Spore, giving them the view that Thrive will be the same but a million times better, which will a) lead to their hopes being dashed when they find they have to manage a list of compounds they've never heard of instead of making an anaconda-rhinoceros with dragon breath and b) change the demographic of the contributors to those who may not have the necessary skills.

Oliveriver wrote:

I felt like I could probably put it off, or that someone else could do it better

That's funny, 'cuz my opinion is the reverse -- I can't keep it all in or I'll get frustrated and abandon the project. So instead, I speak my mind, people respond to my provocation (:P), and the forum sees loads of hopefully-productive activity. It seems to me often enough that lots of people are content with the game being pretty much vaporware, and that's just no good. I'm actually interested in seeing this game to completion, but if me and others (Earthium, for example, but that's their choice to make) are to stick around that long stuff has to change.

By stuff changing, I mean an overhaul of the forum -- taking all those long threads people keep getting referred to, turning them into wiki pages, archive (or similar) everything not related to current development, moving fan discussion off to other channels (perhaps by aggressively (but nicely) closing fan topics made here and re-asking on reddit -- it jump-starts the fan discussion there, and makes it obvious that here is not the place), updating the eons-old banner and read-before-posting sidebar, and relentlessly (but judiciously) copying the practices of other more successful open-source projects.

I only have 3 months until I get swallowed by school again, so I don't have much time to push these changes, and frankly if things don't continue improving, faster and faster, I won't be back after that. Is that an ultimatum? I guess it kinda is, but there ya go.

Oliveriver wrote:

I don't think this is something to look at as too much of a problem.

False starts are nice because they involve progress being made -- however a false start is only false once things stagnate afterwards. The stagnation is very, very bad, which is why we need to work so hard on fostering a programming community of practice here.

Of all the things I've researched on the internet in the past months to help develop the project, I had never thought of looking up a paper on how to structure the team/forum itself. That is a greatly useful find, and tomorrow as my day off I'll be sure to read it through. 

I agree it's quite important we establish a community of programmers for the project, Crovea has been doing such great work but alas it is currently mostly him. In the past we've had periods where we had quite a few programmers at once, but the problem was it seemed they were either always busy or lacked the initiative to do things on their own. Part of it was, undeniably, the structure of the forum at the time (it was much messier than this). 

Wiki updating and archiving are essential to cleaning up the forum, however I feel like there is currently overlap between the wiki and the GDD in regards to the Microbe Stage, so my idea was to initiate some discussion and work on the GDD which we could then copy over to the wiki. Also, it would be useful to get some more people to help out with keeping the wiki up to date. I personally will finish high school in about two weeks, which will end a lot of the time consuming activities on my schedule and give me the time I need to start working on the wiki, the GDD, restructuring the forum, and other jobs in addition to regular posting. 

moopli wrote:

What I suggest we do is first educate ourselves on good open-source project/community management, and then we'll start posting in some appropriate sections of appropriate open-source development forums, ones containing loads of people just raring to help a project get on its feet, and introduce our project as one that's just been a fantasy for a long time, has had several false starts getting actual development going, is in the middle of another start, and might die again unless we find experienced people that can help us get a proper open-source community going.

I agree. In fact, our goal is to finish a good chunk of the Microbe Stage, and then with that as our demo visit online open-source development forums to try to attract programmers, modellers, animators, and the likes to join the project. However, it'll be important that the project structure is more efficient, so it will be good to have this paper to reference to. 

For the spore references, it's not really competition as much as it is inspiration. It was thanks to Spore, what it promised to be, and what it ended up being that drove the first members to found Thrive which we are continuing today, basically just recognizing the project's origins (it actually has quite an interesting history). Having said that, the references to Spore have become quite cliche in how much they are used, like a boogeyman reference even. 

And I'm the same, I'm here to help see the development of this game as fast as possible, wherever possible, as well as possible, despite the lack of skills I have to present, so I'd be more than glad to help, especially with my abilities as a mod, to improve the forum and the project wherever possible to improve the process of making the game, to help attract future members (or not scare them away), and to keep awesome developers like you guys on board.

EDIT: I'm quite tired, and so I realize I used many run-on sentences and sometimes confusing terminology. Tomorrow I'll be able to respond much more coherently.

Since this thread has been diverted a little, I think it's time to get it back on track for its purpose, namely tracking the progress of the tasks listed in the OP.

Oliveriver wrote:

Complete developers/newcomers split

This has of course been partially implemented as the two most recent devblogs outline, but as T0N12 points out there are still a few bugs. The current system is still probably lacking somewhat from what was decided too.

Oliveriver wrote:

Create and organise separate developer groups

No real progress here unfortunately. I can give my input if need be, but all the mods and team leads will need to decide on a way for this to go forward.

Oliveriver wrote:

Move current website and other assets to a Thrive-only server

With discussion here, we've found a donation system may not even be necessary, but the organisational problems still remain as to how the money would be transferred, which hosting service would be used and who the money should be transferred to for setting it up.

Oliveriver wrote:

Finish the updated website

Probably held back by the previous point.

Oliveriver wrote:

Contact Quasar for a joint podcast

We have so much progress to show since the last podcast, but the current media side of things is a little dry. Hopefully with summer vacation/holidays starting in several countries around now, we can get a lot of people on board to participate after we contact Quasar.

Oliveriver wrote:

Start work on shorter development updates to post to media outlets

Same as above.

Oliveriver wrote:

a team lead of each group, as at the moment team leads are only nominal statuses. If we want a more organised and concrete team structure, a team lead for each group who can report back to ~scio and Nick

Having more organization will certainly improve decision-making while this project is still small. However, as this project grows, we'll need to transition to a more fluid structure, where contributors are allowed to work more or less autonomously and check in every now and then. But currently I'd say it's a good idea.

Oliveriver wrote:

Move current website and other assets to a Thrive-only server

I think we could do it completely free, with some work.

Oliveriver wrote:

This has of course been partially implemented as the two most recent devblogs outline, but as T0N12 points out there are still a few bugs. The current system is still probably lacking somewhat from what was decided too.

That should now be fixed, I closes this one loophole in the usergroup posting restrictions.

Oliveriver wrote:

No real progress here unfortunately. I can give my input if need be, but all the mods and team leads will need to decide on a way for this to go forward.

So just to clarify, was the idea to classify people into "teams" or "departments" like programming, modelling, animation, sound, music, outreach, etc. and only allow them to post in their specific subforum?

Oliveriver wrote:

We have so much progress to show since the last podcast, but the current media side of things is a little dry. Hopefully with summer vacation/holidays starting in several countries around now, we can get a lot of people on board to participate after we contact Quasar.

I just finished a big exam I that I had been studying for, so I can email Quasar tomorrow if I get his email (I might still have it myself, see if you can PM it to me). Should we create a thread a new thread for it?

NickTheNick wrote:

So just to clarify, was the idea to classify people into "teams" or "departments" like programming, modelling, animation, sound, music, outreach, etc. and only allow them to post in their specific subforum?

There's no reason to prevent people posting in other sections. I think the only point of splitting people into teams was to make it easier for people to know identify whoever they might need to contact, as well as keep track of who's contributed to what, for the eventual credits.

Quickly skimming through the Skype discussion we had around the time we decided this, I think we wanted it more as an organisational focus thing than anything else, similar to what Tritium said on the previous page. It would also create an incentive for productive members to stay around longer, as they'd be officially labelled part of the team. And of course there's the credits aspect Seregon pointed out.

Posting restrictions weren't originally considered, but there might be some merit to the idea depending on how it's implemented. Those with multiple skill sets would be placed in several groups so could post in any development aspect they have knowledge of, and everyone would of course be able to post in forum support and suggestions, etc. It would certainly prevent any derailment of entirely programming-oriented discussions and the like, but overall I'm of a similar mind to Seregon in that it's probably too much.

@NickTheNick
Good to hear! Quasar's email has been posted in the Skype chat but I'll still PM you with it anyway. Not sure whether we need an entirely new thread - it depends on how he responds.

EDIT: In sending the PM, it occured to me that it has an option to send a message to an entire usergroup. Could be useful with separate developer groups.

I saw a system for developer groups used to great effect during a stint on the Wesnoth forums:

Each wing of the development team (programming, graphics, sound, etc) has a public component and a protected component -- anyone can prove their worth by being a good contributor in the public section, and then, usually after a little bit of deliberation between team leads, they get promoted into the pertinent developer group. They can post anywhere (I'm quite sure), but their group affiliation (visible on all their posts) makes it obvious to everyone about where they have proven their mettle and thus have more authority.

Perhaps what we can do is a similar, but more 3-tiered system, where new members have access more or less as they do now, and accepted members are in a generic "contributor" group. Then, as contributors self-segregate into their interests and earn their spots on the credits, they get promoted to one (or more) of the specific developer groups. 

Then, once the effort to move fan discussion off the forums and dedicate the forums to development succeeds, we might even be able to do away with the new-member introduction-gauntlet, or at least accelerate it greatly.

From my understanding, the forum allows for two methods of classifications. Ranks, and usergroups. Ranks do nothing, and are just meant to signify a position. For example, team leads are not part of a separate usergroup, but rather simply have a title _____ Team Lead. Usergroups, on the other hand, actually can alter your abilities and permissions on the forum. For example, I am an administrator, so I have access to the forum administration panel and the forum moderating tools. Moderators only have access to the latter. Developers have to mod or admin abilities, and users are limited in where they can post.

From what has been mentioned, I'm pretty sure we are going for these team positions to be ranks, not actually affecting your permission but just being a name to your account. In fact, it's your rank that appears above your avatar, not your usergroup, so adding new ranks like "Programmer", "Artist", "Composer" would appear above those users' avatars.

NickTheNick wrote:

From what has been mentioned, I'm pretty sure we are going for these team positions to be ranks, not actually affecting your permission but just being a name to your account.

I was of the opinion otherwise, although we don't necessarily need to change permissions for a usergroup. For one thing, just having a list of everyone who had contributed something to a specific area of development in the past or continues to do so is a convenient and less ambiguous way of creating credits. I'm not sure whether having a rank underneath names would allow for such convenience.

That's true, usergroups would make it easier to manage, especially since a user can be part of as many usergroups as possible at any given point. Then ranks could also be assigned if we wanted to make it say, above the person's avatar, what position they are in. In fact, this gives me an idea to use a hybrid of usergroups and ranks. There would be various usergroups, which would represent teams or departments of the project, and then ranks would be specific categorizations inside of that team. For example, the usergroup would be programming, and the rank would be AI Programmer, or the usergroup would be Art, and the rank would be Modeller. 

Therefore we need to consider what the teams will be. What I have is:

• Programming
  
• Game Design
  
• Art
  
• Audio
  
• Project Management
  
• Scientific Advising (Maybe?)
  
• Wiki Management
  

And then the ranks in each team would be:

Programming
Scripting Programmer
Engine Programmer
UI Programmer

Game Design
Game Designer
Game Tester

Art
Modeller
Animator
Concept Artist
Interface Artist
Texture Artist

Audio
Composer
Audio Engineer

Project Management
(All Team Lead Positions)

Scientific Advising
Maybe?

Wiki Management
Wiki Manager

That hybrid idea sounds workable, I like, and the list you drew up is a good start.

I'm not too keen on where you've drawn the lines between a couple ranks though. AI, Engine, Graphics, and Gameplay programmers are likely going to overlap a whole lot, which makes it a murky distinction. Similarly to how you've split things up for art, I would draw the lines not based on what bits people work on, but what sort of stuff they do. I'd probably start with:

• UI Programmer (working with CEGUI API calls, XML)
  
• Engine Programmer (working on all the guts, we'll probably need more designations eventually, but I'm quite unsure how best to separate concerns -- this is an engine architecture issue, not a project management issue)
  
• Scripting Programmer (the padawan role, working in Lua with the APIs that engine programmers write, doing most of the actual game-rule stuff)
  

For audio we could also add sound effects (unless that fits under both?).

Next, scientific advising -- it's certainly important enough to deserve a separate team, but separating it out might lead to a disconnect between advisors and the rest of the team. However, since users can have multiple groups, this shouldn't be an issue.

As for the last, if the wiki is going to be a resource for fans to read about how the game works then wiki management could be part of the whole outreach system. However, if the wiki is to serve its dual role as a source of knowledge for both developers and curious fans, then I think it would be best to share its managing between developers and outreach.

That brings us to outreach -- it may have a subforum, but it seems like it isn't so much its own team as it is bits of others. what do we do with it? Do we save the question for later, when outreach starts ramping up?

I changed the programming ranks to match what you posted.

Sound FX is meant to be a part of the Audio Engineer. That name is not set in stone it could also be something like Sound Engineer, Sound Designer, Sound FX Technician, etc, it's just Audio Engineer is the name I found that developer studios normally use for it. 

There are two wikis, and one is meant to be maintained by the fans, whereas the wikidot one this thread is on is for developer purposes primarily.

Outreach does have it's own subforum, but I feel like it's not much of a role to be an outreach guy, unless you are specifically the outreach team lead. It seems more to me that outreach is something anyone from one of the other teams can do to help out with the project's publicity. However, if people are content with being purely a PR guy, I'd be fine with giving them that option. It's most likely only going to get more useful as time passes, because right now we don't really need it.