I wrote a bit in here about priorities and patch notes and I think it's worth bringing up: https://www.reddit.com/r/Diabotical/comments/izvoxm/patch_notes_version_020358_september_25_2020/g6lwqvy/
An important thing to emphasize is that you are not seeing just the result of a day's work on a day's patch. We are still working on important things on the background and they are released (hopefully) when they are ready. This one optimization thing took a month of changes and testing here and there, for example. There's a lot of trial and error, research, failure, asking somebody to test when they have time, then waiting for the results, then you come back to it, and you realize that the change uncovers a problem in a 3rd party dependency, you need to wait for them to give you an update, etc. I.e: the normal development process still goes on.
Many things are indeed done entirely on the same day. Regarding the smoke, for example, frankly we just completely forgot about the smoke weeball when we did enemy name plates. We were concerned about giving away any info when it comes to obstacles in the environment and I guess our testing focused very strongly on this and it created this blind-spot. Nonetheless, yes, pretty dumb. When we realized this after pushing, we implemented the intersection for the smoke, we tested it for what I think was a sensible amount of time considering the position was being given away on the live version completely and we were mostly concerned with not breaking things and causing a regression. But names linger for one second after you stop pointing to them and we need to cut them short in this case too. This situation never came up during our testing. (At least this is what I think is going on, we'll fix this shortly on a minor version, a tentative fix is being tested as I write this). The result is that people think that actually you haven't fixed anything sometimes, and this is regrettable, but I don't think we should change direction because of things like this. We can still keep things as they are but learn from this, I'm pretty sure next time we add any informational aid to the game we won't forget to consider our exotic mechanics, and then things will get the adequate amount of testing.
Like tylerrobb mentioned elsewhere in this thread, and this is actually very close to how I would try to objectively assess our performance from our end, I would say that we would know we are going too fast if we are constantly having to rollback changes. But I think we have a pretty decent "finality" rate, I don't think there's been many things that we've had to take back out of hundreds of items. There are a lot of things that need an extra turn of the screw, and there is some notorious blunders. All in all I think that this pace results in more enjoyment on average for everyone.
It is a trade-off, and there are borderline experimental philosophical decisions involved into where we have have decided to fall on this trade-off. It's understandable and expected that you look at this as a developer and you cringe a little bit inside because you are familiar with the ways in which we are putting ourselves in situations where mistakes are going to happen. As a programmer you normally wouldn't want to have any blunders attached to your history as an employee or contractor and you would go out of your way to make sure that nothing unexpected happens, you will happily make things take 500% longer just to make sure you don't look bad because you know that that client is not gonna forget about that one mistake that you do.
But let's assume the following instead:
That the overall satisfaction of the community is more important to you than not looking dumb sometimes.
That you trust the community's intelligence to understand the trade-offs involved, so that the reputation of the team doesn't suffer either at the end of the day.
If you have the luxury of being able to be in this mindset I do think that it is hard to argue that most people would rather have a slower rate of development in exchange for not having the occasional glitch sometimes that is fixed pretty quickly anyway. I feel very strongly we are doing the right decision here if you try to leave programmer's ego at the door. It is interesting to me that the people telling us to slow down are often tech people (and it's a very sensible thing to say, not criticizing this thought at all).
Somebody also mentioned weekly patches. I think there is intrinsic value on what we are doing with daily patches. Obviously it's not something you can keep up forever, but if you can do it for a time, specially as the community is forming, I do think it's very interesting. You could call this dialectic development if you wanted to be off-puttingly pedantic. In the same way that different modes of communication that occur at different paces result in different outcomes of communication (i.e: writing letters vs chatting). I think that something interesting happens when you increase the frequency of updates as much as you possibly can. People hopefully start feeling as if there is a conversation going on. Causality becomes clear and it's no longer "cool I actually suggested this two weeks ago, maybe my suggestion made it to their tracker and they finally got around to it", it's now "yeah, I'm pretty sure they read my thread".
There is also an important feedback effect that this pace has on our side of the dialogue, too. Assuming you care about what you are trying to accomplish, you are going to be in this perpetual state of guilt if you get to have a say into what gets resolved and what isn't. The increased pace makes it way easier to talk to the community and to say "we'll do this" if you know they won't have to wait very long. It's not nice having to tell people "we'll do this at some point" without an ETA which unfortunately we still have to do a lot. In turn people appreciate the communication, we appreciate the positive feedback and also the effort that people put into explaining bugs or putting across their cases, and this motivates us further.
Long story short: the trade-offs involved are carefully considered and so far we have no regrets with regards to the choice of patch frequency :)
devtrackers.gg
