Release 0.4.0 Thread


#1
This is the original version of this post

Quick Intro

While we do have (Future Release Plans) for planning the roadmap of the next series of releases and what overall direction we want to go with them, I think it’s important that we also have a central thread for planning all the work and progress directly for the next update. Here we can also discuss outreach related to this update (something like Oliver did for 0.3.0).

I think these should be the major goals of this upcoming update cycle:

  • Gameplay. Now that we’ve implemented new GUI, removed the cell hexagons, added compound clouds, and overall made the game more polished and presentable, I think it’s time we move on to an update to add a lot more gameplay and features to the game. I think we should really try to nail down some of the features/changes suggested on this thread (Improving Thrive’s Fun).
  • Outreach. With a more polished and presentable game I think it’s nigh time to start more outreach to expand the team and community.
  • Organization. I think in this release cycle, both for the sake of increasing the team’s work efficiency and in preparing for the arrival of more developers, we should reflect on the current workflow and if we can improve it.

For each of the overall goals for this next update, I’ll also list some sub-objectives that will help achieve that goal. Ideally we can take each of the sub-objectives on the page below and make separate threads for them to discuss them in more depth, and I can add links to those threads here to make this the central hub for this new updat.e


v0.4.0

ETA: TBD

Gameplay

Gameplay is the foundation of the game, and as many of us have said so far, we need to create a good and fun game first, because that’s what will attract people to the project, and that will serve as a foundation to develop the game around. The following are features that will add to the gameplay.

All of the following are explained in this thread (Improving Thrive's Fun).

  • Improved tutorial and tooltips
  • Species mortality (Risk of extinction)
  • Predatory NPCs
  • Compound cloud changes
  • Fluid mechanics
  • Cell generation changes
  • Organelle upgrades
  • Combat improvements
  • Agent system
  • Predatory pilli
  • Bacteria

Assignees:

Outreach

I think now is a ripe time to try to grow the team. If we can expand the group of developers while maintaining a good focus and organization it can be a huge boost to developing this stage and the stages to come, and will greatly help the project become self sufficient and not dependent on individual schedules. Ideally, the following three tasks should bring in more people to the team.

  • Advertising. We have a template advertisement (Link will be on Slack). Included in the document is also a list of sites to advertise to. The plan is that this will be the primary means to recruit new developers to the team.
  • This thread is currently discussing the outreach plan for September: September Outreach
  • Contacting old members. We’ve done it before and we ought to try it again. I recall it did work with a few people last time. We just need to be careful not to contact members we’ve already contacted several times before. There’s a document of all the old members and their contact infos here (Link will be on Slack).
  • Checking up on recently old members. There’s a good number of users who’ve joined recently, but then disappear soon after, and often all it takes is just a quick reminder to get them to come back and stick. This we have no list for so we should make one.
  • Regular social media updates. There have been a few suggestions that we post more to social media. We should find people who have the time and interest to do so. I was thinking we could get some of the mods from the forum to help on that front.
  • This thread is currently discussing this: Social Media Activity
  • More dev forums, less Slack. There’ve also been a few suggestions from people in and out of the team that we should try to avoid having too much of the conversation on Slack. Let’s try to focus more of our discussions onto the forums, especially since Slack deletes older messages (though I’ll admit it’s a lot handier sometimes to use Slack’s instant and less formal messaging).

Assignees: NickTheNick, Naggorath

Organization

I’ve thought a lot about the workflow of the team in the past few months and I think we have a fantastic atmosphere and team dynamic. However, I think we could improve a lot on the focus and coordination of completing tasks, to try and create more of a clearer plan with mini objectives that we set along the way, and a sense of who is working on what. This one is really open to interpretation and I’m interested to hear what you guys think about it. My suggestions for how to accomplish this with are the following:

  • Efficient workflow. I don’t want to compromise the free and voluntary nature of the project, because I think that’s what is one of the best parts of working on it and makes it enjoyable instead of stressful. At the same time, I want to try and integrate some sort of system of setting objectives or milestones, like with this thread, that we can aim for and complete so that we don’t get releases or features delayed by months or years.
  • This thread is currently being used to manage workflow on GitHub: GitHub Workflow
  • Self sufficient documentation. A clear, informative, and well designed wiki would be awesome. I think the wiki has huge potential to be able to fill newcomers in on most of the information that they need to know when joining the project. It can even greatly help current developers who want to learn more about the work of a different team or what have you. This could ideally save so much time for developers from having to explain things to other people by just pointing them to the wiki first. Again I don’t want to overload people with all these objectives I’m throwing out there so this is something that certain people should specifically focus on (For example I will work on this among other things since I cannot help on the development side).
  • Team lead supervision. Maybe it’s just my perspective, but I feel like we could use the role of team leads more to its full potential. Some sort of habit of having team leads check up on people working in their team and then updating their progress on a central hub thread like this could help create an effective communication between our overall planning and the individual tasks people work on. Obviously we don’t want to overload team leads with the work they already have to do, but I think this can be done very effectively with minimal effort.

Assignees:
NicktheNick


Overview

This thread is the central thread for planning version 0.4.0. The overall roadmap can be found here.

These are the main goals of this upcoming release cycle:

  • Engine Switch. A reworking of the engine into one that is better understood by hhyrrylainen, and then through documentation and practice the rest of the programming team as well.
  • Gameplay. Some updates to the gameplay to accompany the engine switch, so that the release is not too similar. This will also be a chance to test the waters before the upcoming gameplay update.
  • Organization. To increase the team’s work efficiency and prepare for the upcoming outreach we want to do, we should work to improve the current workflow and documentation of the project (i.e.the wiki), as well as any media presences.

Engine Switch

Summary

Discussions

GitHub

Gameplay

Summary

Planned Features

  • Separate compound storage
  • Health separated from reproduction
  • Rebalance movement
  • Control scheme change
  • Removing O2 and CO2, adding hydrogen sulfide and phosphate
  • Add chemoplast organelle
  • Melee organelle (Pilus)
  • Life/Population tracking system with possibility for extinction, as well as a win condition (15 generations)
  • Diminishing abundance of free floating compounds
  • Basic AI
  • Implement Compound Rebalance and Blurred Background mods

Discussions

GitHub

Organization

Summary

Planned Tasks

  • Template Advertisement - We should update the template advertisement to have the up to date information on the project so that we can use it for outreach.
  • Draft a list of old members of the team to contact and see if they are interested in returning. Make sure not to contact people we’ve already tried before.
  • Regular social media updates, such as mini development updates. --DONE–
  • Finish updating the wiki.
  • Establish a clear workflow. --DONE–
  • More dev forums, less Slack.
  • Team leads keep tabs on their teams.

Discussions

  • September Outreach - A thread to discuss how to prepare for the upcoming outreach we want to do after this update (September Outreach is probably not the greatest name for it anymore).
  • GitHub Workflow - A thread to discuss the workflow of the project.

GitHub



Future Release Plans
GitHub Workflow
September Outreach
Compound Rebalancing
Social Media Activity
#2

Obviously we can’t go for all of these game features in one update so we’ve got to decide when do we want the next update out, and what do we want in that update. Then, I’ll edit this list to have the date we want to release by and the objectives we want for it.

So, when do we want the next update to release and which features do we want/realistically think can be accomplished by then?


#3

#4

I might be able to add the predatory pilus for the next release, depending on how much time do i get between the new engine being used and the actual release (and of course how much the physics engine hates me).

Also i have no idea what you mean with “species mortality”, could you elaborate on that a bit?


#5

Basically not only is there a risk that you can die, but that your species can go extinct. Also I just realized there’s a word for that (extinction) so I’m going to go update that haha.

Also, since I’ve been a bit out of the loop lately, what’s the current sitch with the new engine and the programmers in general?


#6

We tried ue4 and godot as new engines, but those didn’t work out because ue4 had weird bugs with physics (with different behaviour in linux and windows) and godot’s shader language was too simple and restrictive.
Now we’re adapting thrive to @hhyyrylainen’s engine Leviathan, which has a lot of libraries in common with thrive.
This thread explains it in more detail Switching engines


#7

I’ve been posting some screenshots and short updates in the Switching engines thread. Perhaps I could also post updates like that on twitter?

I think we should focus more on our github by making each item in the release plans an issue on github, which can be assigned to people. And then creating milestones and assigning all of the tasks to some milestones. That way new people can easily find small tasks (with “easy” tag) to work on. Right now there’s just some ancient bugs / ideas there which aren’t very useful.

I’ve been planning on creating some tutorials for different development tasks. The wiki is probably quite a good choice for them. Just need to make sure that we have backups in case the wiki goes down, I’ve also thought about putting such things on my own website as I would have better backups then.

I don’t think I have edit access to the wiki, so that’s an issue.

Slightly related to this is the engine refactor thing I’ve been working on (with using my engine: https://bitbucket.org/hhyyrylainen/leviathan) has simpler setup procedures. There are probably quite a lot of edge cases to handle initially when people start trying to build it, but I hope that if other devs can build it will be quite easy for new people to also build thrive.

I’ve also been working on continuous integration for my engine and getting an online version of the engine documentation. Thrive should also be pretty easy to setup with the same ci solution once the engine switch is done, so we can add more tests to thrive (this is also on my todo list while I work on the switch) which are automatically ran. This should immensely improve the code quality. I’ve also planned on doing code reviews on all parts of thrive and opening issues for every piece of unclear or undocumented code.[quote=“NickTheNick, post:1, topic:378”]
Team lead supervision. Maybe it’s just my perspective, but I feel like we could use the role of team leads more to its full potential. Some sort of habit of having team leads check up on people working in their team and then updating their progress on a central hub thread like this could help create an effective communication between our overall planning and the individual tasks people work on. Obviously we don’t want to overload team leads with the work they already have to do, but I think this can be done very effectively with minimal effort.
[/quote]

Good idea, but at least with the programming team there might be an issue as @crovea hasn’t been very active lately. Now that I think about it has been more than 6 months since he has done more than answer the occasional questions on slack.


#8

I am definetly up for making more outreach videos whenever needed


#9

I’ve been posting some screenshots and short updates in the Switching engines thread. Perhaps I could also post updates like that on twitter?

Awesome! Yeah I would say if you have the time and interest go for it! Otherwise, I could message one of the mods on the forums to see if they’d be interesting in writing it up for you.

I think we should focus more on our github by making each item in the release plans an issue on github, which can be assigned to people. And then creating milestones and assigning all of the tasks to some milestones. That way new people can easily find small tasks (with “easy” tag) to work on. Right now there’s just some ancient bugs / ideas there which aren’t very useful.

Definitely, I think GitHub would work great. From what I know we can bundle the milestones under a single release (or maybe the milestone is the release), and then as you said have sub-tasks within each milestone and that flow from macro to micro is perfect. I’ll go check it out right now and get familiar with it.

I’ve been planning on creating some tutorials for different development tasks. The wiki is probably quite a good choice for them. Just need to make sure that we have backups in case the wiki goes down, I’ve also thought about putting such things on my own website as I would have better backups then.

I don’t think I have edit access to the wiki, so that’s an issue.

Exactly, I’ve been interning at a new job lately and it’s taught me a lot about how effective good wiki documentation can be for a newcomer. Each tutorial we can put on there will be a good long term investment.

I try to save the important pages on my PC, but that’s the best I can think of. Also send me your email on Slack, I’ll add you to the wiki’s editing group.

Slightly related to this is the engine refactor thing I’ve been working on (with using my engine: https://bitbucket.org/hhyyrylainen/leviathan1) has simpler setup procedures. There are probably quite a lot of edge cases to handle initially when people start trying to build it, but I hope that if other devs can build it will be quite easy for new people to also build thrive.

I’ve also been working on continuous integration for my engine and getting an online version of the engine documentation. Thrive should also be pretty easy to setup with the same ci solution once the engine switch is done, so we can add more tests to thrive (this is also on my todo list while I work on the switch) which are automatically ran. This should immensely improve the code quality. I’ve also planned on doing code reviews on all parts of thrive and opening issues for every piece of unclear or undocumented code.

Perfect! Again that’d be an awesome long term investment, making it so much easier for new programmers to get on board. Good luck working on that.

@Naggorath : Fantastic! I’ll put you down for now as assigned to Outreach and I’ll get back to you once we start working on that (probably later this week or next week).

EDIT: The OP has been updated with a link to the new thread for managing workflow on GitHub.


#10

for the improved tooltips i have done this in the editor that now you can see what every organelle do (and pushed it to the assets in svn) and i am now planning to work in some sort of hints i think this count as improved tutorial but i am just missing the necessary gui to do that.


#11

“Contact old members” - Atrox knows where to find Sven.

Being more active on social media is definitely very easily attainable. I’m already on it, and there are a couple of other mods who’ve agreed to help out with that. I’m going to go to the social media page for the rest.

(It’s been ages since I’ve posted on here.)


#12

#13

Now that I’ve mostly settled back into the project after my leave in November and have gotten some of the initial things I wanted to get done out of the way, and also because we have quite a few new members who have joined recently, I want to take this chance to revive this thread and get some of the organization going that I was working on before.

Basically this thread will be to track the overall progress of the next release. For 0.4.0, the main tasks for the release will be the engine refactor, as well as some gameplay changes that we need to finalize and document. In the meantime we also want to improve a lot of the structure and documentation of the project to better prepare the team for the outreach and publicity after the release. This includes plans to organize the forums, wiki, and github in a way that we can easily work between the three as part of our overall workflow. I’ll get to updating the original post soon so it reflects our updated situation.

EDIT: Alright, it’s mostly done for now. Please let me know if there’s anything I’m missing from any of the three sections. I didn’t fill in Gameplay yet because the concepts for that are pretty scattered so tomorrow morning I’ll go through slack and the forums to fill out that section.


#15

I’ll go a head and start preparing to pull in the engine_refactor to the master branch and open github issues for the remaining issues and close old irrelevant ones.

Edit: this list by @tjwhale should be put in the gameplay section of the first post:

  1. Balance movement so it feels nice
  2. make toxins into a compound cloud
  3. add a mellee organelle
  4. population when you exit the editor, reduce when you die
  5. the abundance of free floating compounds starts out high but decreases each time you exit the editor
  6. have some basic ai working (we have something of this already)
  7. after ~15 generations put a message in saying “well done, you are a survivor” or something to that effect

#16

About turning toxins into a compound cloud. Maybe we can make it a compound cloud but add an extra effect Eg, sparkling to it so we don’t lose a color, in fact perhaps all agents have a sparkle effect to differentiate them from normal compound clouds.


#17

Are you volunteering to write the shader for it, or how do we do that effect? (right now the texture comes from a moving noise map image)


#18

I was thinking particle effects, i have no idea how to write shaders


#19

We don’t use any of those yet. And I’m not sure but I think even with those you need a shader to define how they look, also.


#20

I want to reactivate this thread, in terms of gameplay elements, we are almost there, we need to get the models for the new chemoplast ogrealle in the game but its there, and health and reproduction are seperated (thouygh reproduction is broken, im in the process of fixing that), We still need our pilus, is nick still active?