Microbe Release Planning

Here is where we will decide, not on what features to implement for Microbe Stage, but when we do so. So, to get started making a list, look at our current state on GitHub, look through our target state on the GDD thread, and think about how we'll turn the one into the other. Not specific dates, but at least a feature ordering.

We could do this hyper-formally by making a dependency graph of the features, and then walking down it, or we can just talk about it. I think talking about it is easier, though a dependency graph can certainly factor into the discussion :P.


...
I'll edit the OP as we decide on stuff -- mods, feel free to if I forget.

To get things started a bit I'll add that we have microbe division (multiplication) ready, and I was thinking that mutation points and limiting mutation would be a reasonable next step!
I think the upgraded graphics are still a while off, so we could do a release before that is finished.

Here is a temporary plan I made a while ago on github: https://github.com/Revolutionary-Games/Thrive/issues?milestone=2&state=open

Okay, here's a bunch of things I can remember thinking about:

• Grid representation for environmental compounds
  
• Movement physics
  
• Improved microbe AI
  
• Fluid currents (grid-based turbulence)
  
• Procedural microbe models
  
• Microbe deformation
  
• Start-game customization
  
• Floaters
  
• Swimming ur-mitochondria and strings of cyanobacteria (chloroplasts) and stromatolites, microbial mats, and other structural complexity in the environment
  

Deformation depends on procedural modelling; currents and grid-based compounds both depend on getting a functionally-infinite grid working; and AI, I think, will rely a lot on the grid too. Start-game customization we could start right now. Floaters and other pretty environmental stuff like swimming mitochondria should also be more or less independent.

That covers ordering mostly, so now for priority: The pretty visual effects probably come last for now, as you note. I'd prefer they come before the first major release of Thrive (i.e, the complete microbe release we're all dreaming about that will blow everyone out of the water and attract programmers) though. Given how much stuff will end up depending on a grid, I'd say that would be the main medium-term project. Movement physics and start-game customization are anywhere from medium-short to medium-long -- neither is extremely difficult (actually, I could probably take one on pretty soon), but neither I think is super-important. Procedural microbe models, of course, are difficult and will probably not be ready for a long while; meaning we can't aim to have either models or deformation soon.

Edit:
Another for the list: dynamic GUIs -- how much work right now would it be to make a GUI that has fold-out tabs, pretty-looking context menus, and stuff?

From comparing the GDD to what is currently coded in-game, and what moopli has already suggested, this is the list I came up with:

• Graphics overhaul for organelles and cell models
  
• GUI for main menu and gameplay
  
• Different microbial environments
  
• Plasmids
  
• Population dynamics
  

Based on these two lists, I think it would be a good idea to pick what we want to get in for the next release if we were to set ourselves the next month or two as a goal.

As far as I know, production on model overhauls has been slow recently, (the GitHub issue is gathering dust in the corner) but the GUI is in full swing!

So just to make it clear, we are talking about the next 0.2.3 release here.

Quote :

this is the list I came up with:

I'd almost recommend none of these for the next release as I feel it would push back the next release too much.

We haven't heard anything from patowen for a while on the cell graphic overhaul, i just asked for an update on github but I don't think its close to completion quite yet and I imagine lots of changes will be added once we actually have something as well.

GUI Seems to be nearing the end of design but still needs quite some time for implementation: Drawing the assets individually and actually writing the XML which would take some time, especially if it was done by TheRabies or someone else not me (which would be preferable still I believe, considering the "value" of my programming time. It is pretty simple but tedious learning followed by easy but tedious work).

I'm not sure what different microbial environments encompass, I'll have to look up the GDD again, but it sounds like something that would take a bit lower priority.

It would be fairly easy to make a simple population dynamics model tho, I'd prefer to wait with this until after we have a new GUI tho, as it will require GUI elements.

How would plasmids work? As hostile AI in the environment?  

Some list notes of mine:

• Reproduction will obv. be there as we already have it working, just needs a bit of debugging.
  
• I'm working on, and will finish tomorrow savable and loadable creatures from/to file, as a minor feature
  
• Mutation points and limiting mutation to after reproduction feels to me like a good next step
  
• Sound effects are progressing, depending on how fast oliver is happy with a complete set of sounds, they could be in a next release
  
• Basic sunlight and photosynthesis mechanics would be fairly easy to implement
  
• Moopli is currently working on fluid dynamics so that would be an obvious candidate as well~
  
• Zooming as a minor feature could be implemented fairly easily I imagine.
  

Also I just read the version numbering post and I think the graphics update would deserve to be in a release called 0.3 instead of 0.2.X Might make it easier to refer to as well.

Plasmids are just a reskin of several organelles you find floating in the environment. All that means is different models.

Looking at sounds we have, I'd say we have enough to put them in next release. Updates can always come later.

I've already done a bit of the photosynthesis stuff, the only real issue is integrating with the assets repo. Luckily, I'm right on top of that

In terms of sound, music and ambient sound are done, while point sound effects are partially done. I'm not sure whether Moopli's right in saying the game would work with only its current sound effects, but hopefully by the time the rest of the planned features are added there should be a decent enough haul to release with - maybe only by including them in the game will any holes be filled. The current list can be found here.

In general it's been surprisingly difficult to come up with the right sounds for everything - 0.5 seconds of a clink or slosh requires about an hour of work and experimentation, and even then as I'm not really experienced in sound design other than music they might all be pretty terrible anyway. I guess we'll have to find out.  :) 

Well, for starters, the best sound effects are generally still made with a good ol' microphone and random junk lying around the house. But yeah, I have little else to offer for that, sound effects aren't easy.

However, your skill lies with music, so why not use music? You could always just have a whole bunch of little themes that play when different things happen -- some light pizzicato for a button click, maybe some cello-trombone adagio for swimming, something jarring for player death, something less so but maybe sad for another microbe death; or rather, whatever you think will work for each. Hearing music related to how you play, evoking feelings everywhere, would make for a very poignant Microbe stage, something I'd love to listen to and play.

After all, there is no sound at those scales -- sound is a phenomenon of a world too big for microorganisms. Thus you more or less have free rein -- it would make sense to have sound effects like what we'd expect in the macroscale, but in the end it's a choice borne of the aesthetic theme.

And finally, I'm pushing for having them added to the game because I want you to be able to test your sounds in-game. We can make it default to disabling sound effects until you're happy enough, but I want you to be able to change something in a config file somewhere and hear your sounds, and then just edit the wavs or oggs sitting in one of the thrive directories to see how your changes hold up in-game. For that we're probably going to want default sound effects for a bunch of things, so you'll have a lot of leeway in what you can test in-game.

Edit: Hey, it just occcurred to me that, now that we have chloroplasts, we can disable (or at least greatly reduce the density of) glucose emitters and give the AI cells chloroplasts. That'll give players a taste of strategic gameplay, and it's super-easy.

moopli wrote:

However, your skill lies with music, so why not use music? You could always just have a whole bunch of little themes that play when different things happen -- some light pizzicato for a button click, maybe some cello-trombone adagio for swimming, something jarring for player death, something less so but maybe sad for another microbe death; or rather, whatever you think will work for each.

While this could easily work (and I have seen it work for similar things) including sound effects like these would require too much of an overhaul of the sound design and aesthetic feel at this stage. The soundtrack so far has created the feel of an enclosed view of a wider, fragile world, which is why so many of the themes and sound effects are quiet, with slow tempos and high reverb. Adding a pizzicato twitch (fast, immediate, connotations of civilised societies and therefore stability) for something like picking up a compound would jar with what's already there. I have seen musical sound effects work extremely well in other games though, so I might start experimenting with it, if only by using more ambient instruments.

moopli wrote:

And finally, I'm pushing for having them added to the game because I want you to be able to test your sounds in-game. We can make it default to disabling sound effects until you're happy enough, but I want you to be able to change something in a config file somewhere and hear your sounds, and then just edit the wavs or oggs sitting in one of the thrive directories to see how your changes hold up in-game. For that we're probably going to want default sound effects for a bunch of things, so you'll have a lot of leeway in what you can test in-game.

Good point. So far I've been playing the themes and ambience at the same time as every sound effect I've tried, but this still won't show how they hold up when their associated action is actually performed.

Anyway, this is all OT.

Some time has passed, progress has been made, and a release is scheduled for today. Crovea tells me we'll likely be bumping it back a bit from today, to get in some more of the features Nick and Jacob want.

So, I must ask: what features are those?

If we were to release right now, we'd have, from what I can tell, photosynthesis, zooming, multiple AI species, microbe saving/loading, and mutation points. Delay by a week, and we might have some population dynamics, delay by a month and we'll likely also have compound clouds, but it would be much better to make a new release instead of delaying that far. We could have membranes in a few months, maybe even one if I work only on it after exams. GUI, as usual, could be done anytime, depending on how fast things go.

What I'd suggest is releasing 0.2.3 soon (within the week, this weekend would be best) with whatever features we have by then, to give fans the update they've been looking for, and attract some developers. Then, if we pick up a few good people, we can release 0.3, the great graphics update. Without those few good people, we might be able to release a slightly-less-great graphics update by then, but regardless of how great the update is, I think we (programmers) will have to focus on the graphics update for the beginning of September.

OT soundfx:

Come to think of it, I think it would be a good idea to try to push for the new GUI to be in next release, it's kinda awkward building around a temporary gui, which is seen as an example with the chloroplast which is currently not displayed as an option.

I think what you suggested sounds good, with the next release coming out this weekend. However, if the outreach will begin after that release, I will likely be gone for most of the critical time, because in several days I will be leaving on a two week trip. Once I get back though, and before university starts, I'll have a good chunk of time to work on outreach, wiki management, or whatever else we need to work on.

EDIT: On the other hand if you guys want to delay the release to get more features in, like the GUI crovea mentioned, that would be good to. Plus it would mean I would be here for the outreach.  :D (Don't let that be a determining factor though)

I think we should delay the next release to put in the new GUI because as crovea mentioned about chloroplasts not being shown in the editor as a option is a major bug we need to deal with. Also having Nickthenick around when It gets busy after the big outreach with the next release would be nice  :D .

In terms of GUI, the environment concept can probably be labelled as complete (bar the compound radar charts), but the editor and main menu still need some work. Everything also needs to be converted to CEGUI - I'd be happy to have a go since I'm pretty much swimming in free time for the moment, but I would need some guidance on how to get started.

As for population dynamics, in the past Seregon has been responsible (having written lengthy descriptions of the process and made a prototype), but as he's away for the time being an early version would have to be done without him.

Whether the next release is the big outreach one or not, it's definitely time to update ModDB, Facebook, Twitter and Reddit with a new release as soon as possible. The ModDB page in particular hasn't been updated in six months, and fans commenting don't believe any progress has been made.

Also (slightly OT), would the new release be hosted in some form of GitHub add-on this time, such as Sorceforge or Travis as Moopli's been suggesting?

And yes, a discussion about sound effects would probably be more suitable to have in a thread named sound effects discussion.

I just discovered a few days ago that github has a release framework you can use to release versions of your software. So the release will probably be hosted that way.

Some minor corrections: Sourceforge isn't a github addon, but a competitor -- the reason I suggested it was to get around github's space restrictions, and Travis CI doesn't do release hosting, but offers more of a compilation service -- it will compile your code for you (free if you're open-source) and is easy to get set up with github.

Conveniently enough, the reason I mentioned population dynamics as coming soon was that crovea is already working on it.

It seems settled then (or not, since we could just release this weekend) -- the release will wait on the GUI, and nothing else.

EDIT:
Our options are to release now/tomorrow/sometime this weekend, to fit our promise of an end-july update, or to wait until the GUI can be released too, or to wait even more and have a super-epic update. But why don't we do all three, since we're aiming to have more frequent updates anyway? That is, we release now, or tomorrow, to give fans the promised update, then we focus on GUI, to get the GUI out for another release in, say, 2 weeks, and then another 2-3 weeks and we have the back-to-school release.

Edit2: I was also thinking of renaming this thread to "Microbe Release Planning", since that gives us some much-needed breadth to discuss the how of release in addition to the what and when.

That sounds good, doing the three releases as you mentioned, unless there are any objections. We could begin outreach after any one of these given releases, although would it be better to do it after the GUI one?

I can rename the thread if you want.