japhb What do you mean by "where the game starts"? 02:57
And yes, a large portion of the reason for splitting Client from UI is to allow test automation, NPC AIs that operate as a special Client, etc. 02:59
(Other reasons of course are to give the various UIs a consistent clean interface to control, provide on-the-wire consistency, provide a single point for data validity verification, etc.) 03:00
greenfork By "where the game starts" I mean that I don't have a clear idea about what code is called at what point in time 03:11
There's a document "life of a request" that helps with authentication and user management github.com/Raku-MUGS/MUGS/blob/mai...request.md 03:12
But the game is built on top of genres, and genres are built on top of a default Server implementation, so there's a lot more interaction 03:13
Most of the methods public, so in theory any of it can or should be redefined in the child class. So just a lot of things to keep in my head 03:14
I'd like to have an integration test, so I can go through all the steps of interaction 03:15
04:27 lizmat left 09:05 lizmat joined
japhb Can you push your latest work? I could take a look around and see if I can help you get started. :-) 15:05
greenfork That would be great, thank you 18:25
Here is my latest work: github.com/greenfork/rrp