| 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 | |||