A few days ago I read about "php traits", fitting name, that are essentially mixins. I took the opportunity to remove some of the stuff from gameroom into a mixin. Mostly, it was all of the XML parsing functionality. I also moved RoomResult to its own module. This cut down the length of Gameroom by more than half; it was over 1000 lines long and becoming unweildy.
I then decided to try to build the command line room tester after all. I took a super hacky approach; I basically just copied code from the interface pages and the reset tools into a single file. So, when those things change, this file will break. But for now, it is really fast. I can enter in an arbitrary number of players and decisions, and add bots. It uses a fresh database in the "test" environment. Because I didn't over engineer it, it didn't take that long. That's going to be a game changer in room development.
Since I was working on the "test" environment, and doing maintenance, I thought I would revisit my unit tests. First thing I tried was to use the in memory sqlite PDO, but it turns out you need to use the exact same file handle variable every time you use it, otherwise it creates a new in memory instance. This is a problem because the codebase does not use dependency injection. I started adding it to some of the tools code, but when I realized that most of the modules grab the db handle on their own, I gave up. That's a very possible refactor, just adding the db handle as a constructor param, but that would be a pretty beefy refactor. I do want to rewrite most of the modules with stronger contracts and a less ad-hoc approach to database access, so I'd probably do it then (if I ever end up doing it).
I tried to get my tests running, but I had a hellish time getting PHPunit to work. I was on a very old version, so I upgraded it, and it wouldn't execute any tests. I ended up taking an example test down from the website, and it ran. I was then commenting out parts of my tests until they worked; there was something about setUp and tearDown that were causing it to silently die. It was really frustrating. Since there were barely any tests anyway, and phpunit was annoying me, I just moved the tests to dev/archive and figured, when I start writing tests again, I'll just write them from scratch. Now that I think of it, I should have tried to ramp up php CLI's error reporting. Funny how devlogs are.
Didn't make any progress on my list, but now that I have my room testing script I should be able to iterate much faster:
finish parsing rules for AI
rewrite rooms to support AI and a variable number of players. this means getting rid of certain types of rooms (ones that require strict ordering). I also want to take the opportunity to hone in on what rooms were fun (target rooms, consensus rooms) and ax what isn't fun (order rooms, trait rooms).
testing. lots of testing with the bots and maybe some pre-playtest with a person or two.
Deployment. game needs to be redeployed. This is fairly easy but probably a night or two of work.
4 hours
Last edit: dungeonsoffear 2021-04-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tonight was a big maintenance night.
A few days ago I read about "php traits", fitting name, that are essentially mixins. I took the opportunity to remove some of the stuff from gameroom into a mixin. Mostly, it was all of the XML parsing functionality. I also moved RoomResult to its own module. This cut down the length of Gameroom by more than half; it was over 1000 lines long and becoming unweildy.
I then decided to try to build the command line room tester after all. I took a super hacky approach; I basically just copied code from the interface pages and the reset tools into a single file. So, when those things change, this file will break. But for now, it is really fast. I can enter in an arbitrary number of players and decisions, and add bots. It uses a fresh database in the "test" environment. Because I didn't over engineer it, it didn't take that long. That's going to be a game changer in room development.
Since I was working on the "test" environment, and doing maintenance, I thought I would revisit my unit tests. First thing I tried was to use the in memory sqlite PDO, but it turns out you need to use the exact same file handle variable every time you use it, otherwise it creates a new in memory instance. This is a problem because the codebase does not use dependency injection. I started adding it to some of the tools code, but when I realized that most of the modules grab the db handle on their own, I gave up. That's a very possible refactor, just adding the db handle as a constructor param, but that would be a pretty beefy refactor. I do want to rewrite most of the modules with stronger contracts and a less ad-hoc approach to database access, so I'd probably do it then (if I ever end up doing it).
I tried to get my tests running, but I had a hellish time getting PHPunit to work. I was on a very old version, so I upgraded it, and it wouldn't execute any tests. I ended up taking an example test down from the website, and it ran. I was then commenting out parts of my tests until they worked; there was something about setUp and tearDown that were causing it to silently die. It was really frustrating. Since there were barely any tests anyway, and phpunit was annoying me, I just moved the tests to dev/archive and figured, when I start writing tests again, I'll just write them from scratch. Now that I think of it, I should have tried to ramp up php CLI's error reporting. Funny how devlogs are.
Didn't make any progress on my list, but now that I have my room testing script I should be able to iterate much faster:
4 hours
Last edit: dungeonsoffear 2021-04-22