Should Ludeon release Alpha 17 as refinements, or wait for new content too?

[Alenerel]

Speaking seriously I think that you should release the bug fix A17 if the new content is going to take 2 months. Why? Because this time, as you said, its just bug fix and rebalance and its not even going to break saves so probably a lot of mods will keep working just fine, and the one that doesnt probably need just a tiny fix. Its not like a world remade like A15 to A16 which made some modders to almost completely rework their mods.

Tynon pls

[Kregoth]

I honestly think that a bug fix release should be made, but I think the game has grown so large now that I really think you should create a "Beta" Steam version. Like many other games, this would allow you to implement new features and get feedback faster, without ruining the experience for those who like a more stable version to work with. It's also great for modders as they can make the changes necessary to update to the new version before it's actually released.

I vote for a refinement update, with a new steam branch for content testing and feedback for those who like bugs. Which would also end the need for you to ever ask this question again!

[Bozobub]

I honestly think that a bug fix release should be made, but I think the game has grown so large now that I really think you should create a "Beta" Steam version. Like many other games, this would allow you to implement new features and get feedback faster, without ruining the experience for those who like a more stable version to work with. It's also great for modders as they can make the changes necessary to update to the new version before it's actually released.

I vote for a refinement update, with a new steam branch for content testing and feedback for those who like bugs. Which would also end the need for you to ever ask this question again!

This.

Additionally, it's madness to implement major content changes before bugfixes are applied.  Not doing so simply increases the chance for more secondary bugs, in a potential cascading apocalypse of errors that eats coder man-hours like church picnic fried chicken.

Nor should most simple bugfixes break mods, except those that were stopgap measures for the bugs in the 1st place.  Occasional occurrences are perfectly understandable but if this happens a lot, your API for modders is CRAP.  Yes, content changes can necessitate extensive API changes, but unless a bug is quite dire, it damn well should not.

Not fixing known bugs before slapping on additional code is silly, at best and badly counterproductive, at worst.  Why go there?

[Elok]

Honestly, I find that we're clearly missing too many important information to choose which one of the two option we'll prefer. Here's the choice :

Option A :  [Bug Fixing Update] + [Content Update]
Option B :  [Bug Fixing & content Update]

In my eye, the real question is how long will the content update will be set back if you release the Bug Fixing update now?

For instance, let's say you can release the Bug Update now and the Content update will take 2 month. If you decide instead to release only 1 update, how sooner will this update be? If in both case the final update will be in approximately in 2 month, I see no reason to not sent the Bug Fixing update now.

And about the modding argument, if your game is full of mod and you want to kept then, just deactivate your update until the mod are updated. Releasing the Bug Fixing now is only giving you a new choice :

Without Bug Fixing Update
- Play mod with A16   

With Bug Fixing Update
- Don't update and play mod with A16   
   OR
- Update and wait that mod are updated.

[Zhentar]

Nor should most simple bugfixes break mods, except those that were stopgap measures for the bugs in the 1st place.  Occasional occurrences are perfectly understandable but if this happens a lot, your API for modders is CRAP.  Yes, content changes can necessitate extensive API changes, but unless a bug is quite dire, it damn well should not.

It doesn't matter how good the official API is, we modders don't constrain ourselves to the bounds any API would impose upon us. Among the many tricks in our books, we use "detours" to overwrite core RimWorld code with our own. It's impossible for Ludeon to change anything at all without risking mod incompatibilities. (The new Harmony library has potential to significantly reduce this problem for mods using it, so it should get better in the future but it will never go away)

edit: That said, the work required for mods to update depends on how much things change in a release, so a smaller bug fix update won't take as much work to update for as larger content changes

[carewolf]

Thank you for the thoughts so far everyone!

I just wanted to address one thing that's a bit off-topic, but whatever.

- colonist coming from mining site / growing zone empty-handed
- colonist automatically cleaning hospital before operating
- colonists avoiding jobs in rooms that would disturb sleep
- sunlamp automatically turned off at night
- leftovers from deconstruction are hauled away from ALL nearby wall squares before construction is started
- colonists going to remote construction site empty-handed instead of with new batch of materials
- zero warning (not even barking dogs!) when there's a predator coming
- colonists prefering raw food over nutrient paste (it seems to occur when there are several going for paste at the time ? Or just distance ? Makes playing "no sowing plants in the ground" all but impossible)

This isn't an open suggestions thread, but just to note why none of these are changing. There are two main reasons.

1. They're defeated by balance. All of these are things that are essentially of the form, "add AI complexity to make AI perform more optimally and make the game easier". But, if we do that, we'll just have to make the game harder in other ways to maintain the same balance point. e.g. colonists automatically turned off at night? Well, now we just double the sunlamp power consumption to maintain the same balance. Ultimately we end up in the same place, with a bunch of new AI complexity and a bunch of new problems.

2. Any solution creates new problems which are often worse than the original issue. Of course it's easy to say something like, "colonist automatically cleaning hospital before operating". But if we do that, people will soon get pissed off because the patient died while the surgeon was busy cleaning the hospital instead of performing the damn operation. And now we have to add in some sort of player override control, or AI decision making, that can decide when to clean or not clean, and so on and so on. It's an endless regress of AI needing to solve the problems that the last solution created.

The same goes for something like, "sunlamp automatically turned off at night". By whom? When, exactly? What if you don't want it off? How far should they walk to turn it off, and can you control that? What does the UI for configuring all this look like, and what new problems will that create?

We can ask the same battery of questions about almost all these notions.

RW's approach to AI is to set up simple mechanistic rules that the AI follow, let them be suboptimal, and balance the game against those suboptimalities. I've seen other developers try to solve every tiny problem and it's just an endless cycle of problem creation and solving, with complexity increasing the whole time. And ultimately it's pointless, since all those optimalities just get balanced out per point 1.

The one main argument about these kinds of solutions is that they eliminate the incentive for micromanagement by "doing the micro for you". But, there is a point beyond which the downsides of trying to do this outweigh the advantages. Any game like RW is going to have places where players can micro-manage to get micro-benefits. Like many inherent problems in complex systems, this isn't something that can be totally eliminated without the cure itself destroying the whole system. All we can do is try to find an optimal balance where we keep the problem manageably small while also avoiding the huge costs of being too militant in trying to solve it.

I would be really open to specific suggestions about changes to make (in another thread in the suggestions forum) - but it's a lot more helpful to say *exactly* what changes you want. Remember the AI isn't people, it needs to have specific razor-sharp rules for every situation; it can't make intuitive decisions and doesn't understand anything about what's going on. It would be great to try to think through exactly what you want, and what problems that would or would not create, and present the solution instead of just the problem. Then you'll really be engaging in the design process! (and again, please do not make suggestions in this thread, they'll get removed as off-topic).

Those are all good points, and I mostly agree but here are two counter points:

1. There already is a great mod with a day/night switch, it takes a bit more effort for the player to setup, but UI wise it is pretty clean and just works as an automated manual switch. If you want to make it less "good" you could require it to be manually operated but instead just let it create a job to be switched.
2. About hauling. I know a lot of people are complaining about the colonist AI, but I think this one major complaint is easy to solve and has little effect on overall efficiency. You could have check that lets potential haulers check if something needs to be hauled the same way (with at most 10% longer route) when they need to take a particullarly long walk. This will make everything look better to the players, but those long walks are actually not that common, so in effect it just means a minor takes one extra handfull of rocks with them after a whole day of mining. Or one corn farmer takes a single stack of corn with them. It will not solve any significant fraction of the overall hauling need after a day of mining, or harvesting an entire field, but it will LOOK better to players, who will feel the colonists are now so much smarter and well behaved.

[Bozobub]

Um...  You're kind of tonedeaf, eh?

[milon]

I think it's contagious 

I honestly think that a bug fix release should be made, but I think the game has grown so large now that I really think you should create a "Beta" Steam version. Like many other games, this would allow you to implement new features and get feedback faster, without ruining the experience for those who like a more stable version to work with. It's also great for modders as they can make the changes necessary to update to the new version before it's actually released.

I vote for a refinement update, with a new steam branch for content testing and feedback for those who like bugs. Which would also end the need for you to ever ask this question again!

This.

Additionally, it's madness to implement major content changes before bugfixes are applied.  Not doing so simply increases the chance for more secondary bugs, in a potential cascading apocalypse of errors that eats coder man-hours like church picnic fried chicken.

Nor should most simple bugfixes break mods, except those that were stopgap measures for the bugs in the 1st place.  Occasional occurrences are perfectly understandable but if this happens a lot, your API for modders is CRAP.  Yes, content changes can necessitate extensive API changes, but unless a bug is quite dire, it damn well should not.

Not fixing known bugs before slapping on additional code is silly, at best and badly counterproductive, at worst.  Why go there?

• You'll be pleased to know that there is a Steam beta option! (It's been there for quite a while now.)
• Content isn't changing before bugs are being fixed. It's the other way around.
• Pro Tip: Alpha means nothing is set in stone yet
  
  • Game mechanics, internal structure, etc are all subject to change until the game is done
  • Consider how that might affect mods
  • Consider the man-hours involved in maintaining support for deprecated functions/methods
  • Consider the debugging nightmare that would be
• I seriously got a really good laugh out of your "eats coder man-hours like church picnic fried chicken" comment. I genuinely thank you for that!

[Illusion Distort]

Personally I feel you have the branching system in steam, release it as a different branch, if steam mods want to update they can, DRM free people can handle this in many ways so i doubt it would effect us in any way.

I like to enjoy and play through when the mods start updating and the content is new.
But branching could solve or reduce the damage here.

[Tynan]

Since I cant troll comment in the blog I answer here.

So far we've fixed hundreds of bugs.

You gotta be kidding me. Where are those bugs? I have encountered some but hundreds!? I bet you are spending the money of RW in drugs and beer with a monk in Venezuela. Or worse, playing Counter Strike.

Tynon pls

You can actually look at the Bugs forum to see some of what's gone on. I think there are about 300=400 A16 reports in there (almost all of which are fixed).

Yes it amazing how many problems can hide in a game like this.

[Diovanlestat]

Don't know much about coding and such, but I really like rimworld. 

I think you should do the bug fix first, I'm willing to wait for the modders to catch up. (and my favourite modders here say they prefer that)  It's an early access game, and the assumption should be mods will break. 

My main reason is the let's plays people sometimes have lags and sometimes bugs and this makes the game look bad to prospective buyers.  Bugs are what turn people off the most, the gameplay, people already love.  It also makes it look like the developers take stability issues seriously.  (many early access games don't seem to) My 2 cent's, but you know best, cause game is already great.

[Kregoth]

• You'll be pleased to know that there is a Steam beta option! (It's been there for quite a while now.)

Son of Ahhhh! I had not noticed the "Alpha 16 on public unstable branch" post had an UPDATE.

UPDATE: Unstable version is being updated more or less (week)daily. The forum thread has the ongoing discussion and update details.

Ooops, my bad! Good.... good I'll just slip back into the void now!

[Keeper]

I vote bug fix patch.

At this point in time the content given to us from A16 should keep everyone busy with gameplay as there's plenty to do and I find it hard to believe that the majority of players utilised every aspect of the content. Then there are the challenges in the game which people strive to overcome. You can easily do 2-3 years just travelling the globe in the tribal stage not researching.

What's reducing the enjoyment of game is not the lack of content but the performance and bugs/crashes. Once these are fixed then players can expand their gameplay to do larger challenges like multi-colonies for example.

[ambivalence]

+1 for the beta branch on permanent grounds. It will allow modders to update their creations beforehand. Moreover, may be every update should be something like Intel's tick-tock strategy: for one big upgrade – one refinement?

[Scotias]

I voted to release the refinement patch then new content later.

I wouldn't worry about mod users such as myself, we know to rollback until our fave mods are updated. Playing with the refined build itself may uncover remaining bugs etc, fixes for which can then be included in the new content update right? As well as finding out how the fixes to exploits have gone down :-)