| 13 Apr 2024 | |||
| greenfork | I will soon try out the newer version, will see if this is connected to the Star distribution | 17:26 | |
| japhb | Sounds good, thank you! | 17:27 | |
| greenfork | One more about MUGS: when there's some error in my server code for a new game, and I run it with mugs-cli <my-game-name>, I get an error like this | ||
| Died with the exception: Request invalid: Game type 'rrp' is unknown | |||
| And several stack traces pointing to MUGS::App::LocalUI | 17:28 | ||
| Can I improve error reporting somehow? This one happened because I referenced a variable that was not defined in my server code | |||
| japhb | Oh, syntax errors in the game code? That may be causing a failure to load the plugin. | ||
| I'm using a plugin-loader module as a dependency. I'll have to take a look at what can be done about the failure mode there. | 17:29 | ||
| But for myself, I usually have a t/00-use.rakutest that consists of just use'ing all the modules in my distro in dependency order, and I run that test *often*, with verbose test output. It's a canary for "oops, you broke one of the modules not actually involved in startup". | 17:30 | ||
| greenfork | Sounds nice, I will do that too | 17:31 | |
| japhb | If you have an editor that can run tests on file save, that's probably a good thing to hook up to at least the use test. | 17:54 | |
| greenfork | Hmm this is an interesting idea | 18:01 | |
| 14 Apr 2024 | |||
| japhb: Could you comment on the use of := operator, I see it sprinkled in some places, e.g. here github.com/Raku-MUGS/MUGS-Games/bl...kumod#L217 | 09:41 | ||
| Is this to just avoid containerization-decontainerization overhead for a little bit of performance? | 09:42 | ||
| lizmat | yes, that's basically the reason for using := | 09:47 | |
| greenfork: in the case of %has := foo it also means that "foo" is returning a hash | 09:48 | ||
| using := in that case means preventing a (relatively slow) copying of the hash | |||
| greenfork | Got it, thank you | 09:49 | |
| 15 Apr 2024 | |||
| japhb | Thanks for replying, lizmat! I've been mostly AFK today .... | 04:22 | |
| greenfork | I have a primitive game for starters, now I'd like to reap the benefits of testability, since it is not dependable on UI | 17:44 | |
| I assume I want to set up a Client-Server integration testing somehow? | |||
| I already can test smaller components, but Client/UI/Server split is not necessary for unit tests | 17:45 | ||
| I also kind of lack the concept of where the game starts, I think testing should help with that too. How would I start? | 17:46 | ||
| 16 Apr 2024 | |||
| 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 | ||
| 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 | |||
| 19 Apr 2024 | |||
| japhb | OK so: I've had a bit of time to look through the rrp repo. It seems that the first problem you solved (string translation) was actually the problem that I had recently spent a lot of time solving for MUGS-UI-TUI (and a somewhat more advanced form in Terminal-Widgets, which MUGS-UI-TUI is based on). | 04:39 | |
| I hadn't had a chance yet to merge all the functionality of that back to MUGS-UI-CLI, but for an example of what it looks like now, see: github.com/Raku-MUGS/MUGS-UI-TUI/b...nu.rakumod | 04:43 | ||
| Note the ¿ marks -- those are strings marked as translatable, and automatically translated when used. | |||
| However, because I wanted to look at the UI translation problem without a lot of history, I started from scratch in my file design. Your use of POFile is a good point though -- I should provide a way to simply load a POFile for the user's current language (user locale is switchable on the fly in Terminal-Widgets) and use that for translation. | 04:45 | ||
| As a general note, in MUGS the Client and Server should not have any *internal* translation needs, unless you plan for *developers* and *server admins* to be able to do so entirely in their native language. Otherwise every error string or status update or whatever should be sent back and forth as a semantic value (perhaps an enum or a moniker) that is translated in the UI. | 04:49 | ||
| And even if you do want server admins to be able to do so in their native language, it would be better to design an admin app that does that, rather than having Server or Client classes do translation. | 04:51 | ||
| (The one exception that I can see for the above is offering a plugin that runs in the server context and does online translation (via e.g. Google Translate API) for messages sent between players ... but that's not actually translating anything in the Server or Client Game, just offering a plugin to massage human messages sent *through* the Server.) | 04:54 | ||
| All of which is to say: My biggest suggestion would be to focus on the game's *semantics* so that I can have time to take the translation system that I designed for MUGS-UI-TUI/Terminal-Widgets and port it to MUGS-UI-CLI. I expect it will save you lots of mess in the long run. | 04:56 | ||
| And as for testing, I think the main trick will be to test the Server Game's behavior in isolation, the Client Game's behavior in isolation, and then do your first integration test with: Test Suite <-> Client Game <-> Server Game | 04:58 | ||
| That way you can test the semantics of the game completely separately from any UI. | 04:59 | ||
| Once those are trustworthy, *then* you can start testing one (or more) of the UIs. :-) | |||
| greenfork | It's a good point that translation should happen on the UI layer | 05:45 | |
| I think I intend to use the Pop game engine as a UI layer. I want to ship games to Windows, so any terminal interaction is not going to be easily digestible | 05:47 | ||
| I saw some work on the Pop UI layer, I will probably try to start there once I get Pop installed, so far I can't gitlab.com/jjatria/pop/-/issues/1 | 05:48 | ||
| About testing: I think I will need a barebones example of how to do integration testing. I can unit test specific parts of my Client or Server implementation | 05:50 | ||
| but I don't fully understand what the entry points are to the whole program | 05:51 | ||
| If you could provie an example, it would be very appreciated, I can start from there | |||
| patrickb | that pop error seems to be a rakudo or even MoarVM bug. | 07:16 | |
| greenfork | patrickb: Okay, I will ask in the main channel, thanks for looking into it | 12:11 | |