Priest Game Issues?

[kamandi]

One of my fellow priests brought up recent difficulties with converting followers- Suddenly, as of a week or so ago, we are completely unable to convert followers, and both of us have pretty substantial oratory skills. We have preached in realms that haven't had preachings recently and get zero response.

On the flip side, influencing followers HEMORAGES followers. It's making playing a priest pretty useless, and feels awfully futile.

Is this a bug or have we just reached some sort of usefulness plateau?

AC

[Anaris]

I changed the way automatic conversions and deconversions work a while ago, and I think I may have been a little overzealous in some areas. It's something I've been meaning to revisit for a while now, but haven't had chance.

So while I can't speak to specific issues without seeing them in action (it's possible you've also found a separate bug in the way followers are calculated), I'd say that it qualifies as a quasi-bug ;)

I will try and see if I have some time to look into it in the near future.

[kamandi]

Ahhhh that would explain it!

If it's helpful, the problems have been on Atamara. Very resistant population there. Very stuck in their pagan ways....

Thanks!

AC

[Chenier]

I changed the way automatic conversions and deconversions work a while ago, and I think I may have been a little overzealous in some areas. It's something I've been meaning to revisit for a while now, but haven't had chance.

So while I can't speak to specific issues without seeing them in action (it's possible you've also found a separate bug in the way followers are calculated), I'd say that it qualifies as a quasi-bug ;)

I will try and see if I have some time to look into it in the near future.

Did you change preaching? Machiavel has 100 oratory fame, and yet, more often then not, 12 hours converts no more than 50 people in a typical region, 150 in a large city.

[Anaris]

Did you change preaching? Machiavel has 100 oratory fame, and yet, more often then not, 12 hours converts no more than 50 people in a typical region, 150 in a large city.

I don't think I did, but it was a while ago, and I'm not 100% sure.

Are you noticing it being because there are more "too many preaching" messages?

[Chenier]

I don't think I did, but it was a while ago, and I'm not 100% sure.

Are you noticing it being because there are more "too many preaching" messages?

It's been quite a while since I actively preached, too. I do tend to find that the "too many preaching" messages seem to come a lot quicker than they used to.

[Anaris]

It's been quite a while since I actively preached, too. I do tend to find that the "too many preaching" messages seem to come a lot quicker than they used to.

OK. I may have done some tweaking to how fast the peasants "forget" about recent preaching at the same time as the other changes, and it may need further tweaking.

[kamandi]

I don't think I did, but it was a while ago, and I'm not 100% sure.

Are you noticing it being because there are more "too many preaching" messages?

I, and the other priest I have talked to, started talking when we noticed the "too many preaching" was popping up in realms that no one had been in for quite some time. I just tried preaching in a realm no one has been in for over a week, or more, and there was no discernible change in the believer %, and I got the "too many preachings" warning.

[Jens Namtrah]

OK. I may have done some tweaking to how fast the peasants "forget" about recent preaching at the same time as the other changes, and it may need further tweaking.

It really is past time to learn about Unit Testing

This is a short and excellent series by a friend of mine that can get some simple stuff started:

https://jtreminio.com/2013/03/unit-testing-tutorial-introduction-to-phpunit/

[Vita`]

I completely agree. I even started playing around with unit testing a few pages before realizing a significant portion of it will require db mockups and I was too busy to mess around further.  But with one primary developer and a bunch who haven't had much time to contribute in a lot despite their best intentions (intentions alone don't do much and all that), it comes down to a lot of opportunity costs in what gets done vs doesn't. There's a *lot* that should be done to improve the codebase. We're *still* working on Doctrinification here and there. There's a responsive web design. And yes, unit testing would be nice. But I'm sure you also know the difficult of implementing good design into a codebase that began over a decade ago maintained by volunteers. While obviously not impossible, the codebase is such that implementing unit testing will be a significant effort - effort not spent on visible portions of the game that most players enjoy seeing progress on. We would probably be best served by using test-driven development to begin implementing unit tests into anything new from hre on out, but then you have to get support (and show new dev members) for implementing tdd development practice. And as is, that means convincing Anaris to implement that into his current practices. If you'd like to help out, I'm sure Anaris would enjoy a message. And again, where I wrote we - that's primarily Anaris and its a rather disingenuous usage of the word we.

But I am curious as to what Anaris's thoughts upon implementing tdd into his volunteer dev time would be because I honestly do think we need unit testing, I just also realize the opportunity cost of implementation.

[Jens Namtrah]

TDD is not Unit Testing; at this point, most of your code is written and needs Unit Testing as you "fix and tweak" to help avoid breaking  things as you fix, and confirming that what you intended is what will actually occur.

Yes, it will require a lot of refactoring as you go to make things testable. Yes, that's a bonus, not a time sink.

People don't realize how much time they waste by not "having time" to set up a good foundation.

[Anaris]

It really is past time to learn about Unit Testing

This is a short and excellent series by a friend of mine that can get some simple stuff started:

https://jtreminio.com/2013/03/unit-testing-tutorial-introduction-to-phpunit/

Why, yes. Let me stop all current development and bugfixing, and spend a year or two doing nothing but writing unit tests for code which ranges in ages from 1 week to 10 years, with all the various cruft involved in that.

Sorry, Miskel, but it's just not practical for this project—not when I'm the only active dev.

If you want to join the dev team to do that, and have the skills required, then I'd be willing to bring you on at least on a provisional basis. (Only Tom can make the final approval of dev team members.)

[Anaris]

But I am curious as to what Anaris's thoughts upon implementing tdd into his volunteer dev time would be because I honestly do think we need unit testing, I just also realize the opportunity cost of implementation.

First of all, let me say that while I understand the usefulness of unit testing in general, it is not something that I have ever actually learned. It was not taught to me in my college courses, and once I graduated, I was in a position where time was far too much of the essence for me to be able to justify to my non-technical bosses spending the amount of time required to a) learn unit testing, b) refactor the existing codebase to include it, and c) spend a significant portion of my time going forward writing unit tests.

Second of all, as I understand it (and please correct me if this is not the case, since as I said, I have never actually used unit testing myself), we would only be able to create meaningful unit tests for the portion of the BattleMaster codebase that has been Doctrinified—and even that would require some extensive restructuring to properly support the unit tests. And that doesn't even get into the issues involved with how unit testing and the database would interact.

Third of all, and this is particularly directed at Miskel, I don't think unit testing would have done a blind bit of good in this case, for multiple reasons. First, because the problem here isn't a bug, per se, but rather new behaviour that was being tried out, that turned out to have undesirable effects. Second, because those effects could not become obvious based on any immediate testing: they, like many of the behaviours in BattleMaster, were long-term effects, due at least in part to the interaction of many different factors.

This game is full of nontrivial effects like that, and even emergent behaviours that aren't a property of any one piece of code, but rather several systems acting in concert, tied together by the actions of the humans running them—whose behaviour, while it can be predicted to a certain extent, is not subject to unit testing.

So no, I'm not willing to just drop everything and spend, like I said, multiple RL years refitting the entire codebase with unit tests. If Tom or I were willing to accept that kind of timeline for coding that is, to the players, a complete no-op, we would have started rewriting the game from scratch when I first came onto the dev team 6 years ago, and have a very different BattleMaster now.

[Jens Namtrah]

You are way off on what Unit Testing is, and how it works, and what you need to do to start applying it.

You could add your first simple test TODAY on any bit of code that you isolated into a testable unit. It takes a little bit of time to get the idea of, like anything else.

Furthermore, Unit Testing is more than simply catching bugs - it is also about confirming that the desired output is being returned. Unit Tests and other types of testing can handle receiving multiple "moving parts" and tell you what outcomes are happening. Far more complex code that BattleMaster relies on testing to stay online.

(BTW - it has nothing to do with Doctrine. If anything Doctrine can make it more difficult sometimes, as everything has to be mocked. I would recommend you skip the db areas for now and look for small bits of code that can be refactored to functions, then learn how to write a few tests on those until you get steadier on your feet with it. It takes time, but there's a huge Open Source community willing to help )

I highly recommend that you take a Sat. afternoon off and play with it for an hour or two and understand what it can do for you. It even the short-term, it can save you many hours of having to go back and constantly fix small things - so it adds up to a huge savings very quickly.

[Anaris]

You could add your first simple test TODAY on any bit of code that you isolated into a testable unit. It takes a little bit of time to get the idea of, like anything else.

Furthermore, Unit Testing is more than simply catching bugs - it is also about confirming that the desired output is being returned. Unit Tests and other types of testing can handle receiving multiple "moving parts" and tell you what outcomes are happening. Far more complex code that BattleMaster relies on testing to stay online.

But, again, bugs like the one described here would have exactly 0 chance of being caught by unit testing. I would write the code, write the test, run the test, and observe that the results match what I expect then and there...and then six months down the road, people actually using the code, enmeshed with all the rest of the game's code, would find that it has unexpected and undesirable interactions when used over long periods of time.

(BTW - it has nothing to do with Doctrine. If anything Doctrine can make it more difficult sometimes, as everything has to be mocked. I would recommend you skip the db areas for now and look for small bits of code that can be refactored to functions, then learn how to write a few tests on those until you get steadier on your feet with it. It takes time, but there's a huge Open Source community willing to help )

The point about Doctrine was that the code that has been Doctrinified has also been migrated over to OOP, and is much more modular and less crufty.

I highly recommend that you take a Sat. afternoon off and play with it for an hour or two and understand what it can do for you. It even the short-term, it can save you many hours of having to go back and constantly fix small things - so it adds up to a huge savings very quickly.

I may end up doing so at some point, though not necessarily for BattleMaster. I do write various smaller projects (both for myself and for my Real Work™) that could probably benefit from unit testing.

In the end, BattleMaster just has more than enough work to do for its part-time volunteer developers without trying to add unit tests while also learning how unit testing itself works.