|
Welcome to MUGS ⚄♠♞🏹 (Multi-User Gaming Services)! | github.com/Raku-MUGS | v0.1.0 'Proof-of-Concept' has been released! (github.com/Raku-MUGS/MUGS/blob/mai...v0.1.0.md) Set by japhb on 22 March 2021. |
|||
| jjatria | Hi all! Slightly off-topic, but I've just released the first public version of Pop: a Raku game framework I've been working on for the last couple of months. gitlab.com/jjatria/pop | 21:20 | |
| From what I understand of MUGS, it seems to me like they should be able to play nicely together, too: Pop is not so interested in the game service infrastructure as it is in providing tools on top of SDL to make games locally | 21:22 | ||
| So in that sense, it's closer to frameworks like LÖVE2D or Pico-8 | 21:24 | ||
| Here are a couple of simple sample games I made while working on it: gitlab.com/jjatria/pop-games | 21:28 | ||
| japhb | jjatria: Oh that's very cool. | 21:45 | |
| Yeah, MUGS's core systems fade out about where Pop seems to begin; in fact, a Pop UI would be an excellent UI plugin for MUGS. | 21:46 | ||
| Actually, there are a couple games that you've already implemented that would be good samples for that integration. | 21:47 | ||
| jjatria: I'm still skimming things over, but I think the big deal here will be handling inputs coming from the MUGS Connection layer (by default coming as a Supply, but of course it's trivial to conver that to a Channel or what have you). | 22:23 | ||
| Also, the updates (since they are server driven) aren't necessarily synchronous with client frames in any useful way; you can expect to take UI inputs, convert them to client actions, send them to the server, then asynchronously get state updates from the server to the client, and incorporate those into displayed/rendered state in the UI again. | 22:24 | ||
| jjatria: Are you open to PRs to implement any of this? Or would you rather do it yourself? | 22:25 | ||