|
Welcome to MUGS ⚄♠♞🏹 (Multi-User Gaming Services)! | github.com/Raku-MUGS | v0.1.1 has been released! (github.com/Raku-MUGS/MUGS/blob/mai...v0.1.1.md) Set by japhb on 16 April 2021. |
|||
| japhb | [Coke]: PTAL at github.com/Raku-MUGS/MUGS/tree/main/docs and the quick start "Install MUGS" guide linked from it. | 00:09 | |
| (Any others, I'd be happy to hear from y'all as well | |||
| ) | |||
| If this seems roughly in the right direction, I'll make more of these guides. | 00:10 | ||
| (And put a README in each doc dir, and point to the general docs/README from each repo README) | 00:11 | ||
| Two more WIP howto docs added, for porting a game and making a new UI plugin. Both are rougher than the MUGS install guide above. | 06:26 | ||
| (But hey, partial docs are better than no docs, as long as they are actually accurate ....) | 06:27 | ||
| [Coke] | japhb: thanks. | 14:27 | |
| so, if we wanted to have various Poker styles (at least: texas hold 'em; omaha; omaha hi/lo), with various betting styles: limit, no limit, pot limit, I assume we'd want to have a generic poker server, with specific games for the variants, each of which could have a different betting set of rules. | 15:21 | ||
| Those 3 are pretty similar in structure, but there are other poker variants (e.g. stud) that have a different layout, but still similar betting variants, hand rules, etc. | 15:22 | ||
| if you already have "deck of cards", that informs a bunch of other things. | |||
| also, as you know: searching for raku mugs is extremely difficult | 15:23 | ||
| You had mentioned cards in chat, but I don't see anythging under Raku-MUGS | 15:26 | ||
| japhb | [Coke]: Yeah, the card stuff is in my local working dir, because I wasn't totally satisfied by how I was doing it. I can push it up for you to comment on if you'd like | 16:05 | |
| MUGS has a hierarchy of genres -- so you'd probably have TurnBased > CardGame > Poker > HoldEm or so. | 16:06 | ||
| Yeah, the SEO is poor, I know. Its frustrating, but I don't have an idea for something better right now. | 16:07 | ||
| Looked at the search engine results. [raku mugs games] seems to work as a search (MUGS has the top spot in both Google and DDG) | 17:13 | ||
| Uploaded the beginnings of my thoughts about the CardGame genre. It's honestly not much as I've been working in other areas of the code for a few weeks, but here you go: github.com/Raku-MUGS/MUGS-Games/bl...me.rakumod | 17:20 | ||
| [Coke]: Let me know which things would be most helpful to you (chat, howto docs, more work on CardGame genre, etc.) | 17:32 | ||
| [Coke] | does a cardgame need to know how many players it has, or is that something more fundamental? | 17:43 | |
| (and if more fundamental, what about min/max player numbers?) | |||
| raydiak | glad those docs are starting to exist! especially the porting and ui ones. if you don't mind a bit of constructive feedback...there is a small book worth of english docs, which is great to have, but they still contain nothing concrete in the technical sense: code examples, api specs, tests, that sort of thing | 17:59 | |
| you've clearly thought a lot about separation of concerns, but that also means a single small game is split across several files when you consider the game client, server, genera, the parent generas, and the parts of MUGS they use or call. which makes the flow hard to follow and figure out for yourself | |||
| just as one example, I had to search across the entire github org and look through all the results to the very last one just to figure out what a MUGS::Character is, for instance. we're really lacking in techincal documentation, not english documents. lots aimed at users and contributors and the design philosophies they should be following, but none that help people actually *become* users/contributors in the | 18:00 | ||
| first place | |||
| [Coke] | Note: I'm very happy to be concentrating on the "business logic" and not any of the infrastructure. :) | 18:02 | |
| raydiak | japhb: also a status update, I am still poking at a web game as I'm able. would you believe the JS world has changed a bit since I last used it heavily at work most of a decade ago? :) the physics is also somewhat high-reaching for a multiplayer game, so some simple things that are often simple...aren't. but proper acceleration/momentum helps smooth over lag issues (and feels slick when used right), so it ought | 18:44 | |
| to be worth it in the end | |||
| japhb | Sorry, was offline for a bit. Reading back ... | 21:09 | |
| [Coke]: Games always know their own participant list. | |||
| Games will not start until they hit the greater of (min-players, start-players), and they won't allow more players to join if at max-players. You can also specify whether players are allowed to join after the game officially starts. | 21:10 | ||
| In the case of poker, interestingly enough, because a real poker table can have people come and go in between hands, it probably needs the one extra stricture that people can't join *during* a hand, and if they leave during a hand they auto-fold. | 21:11 | ||
| [Coke] | they also might have "stand up" (stop playing but still watch the table) "sit out" - keep game state but get skipped on deals... | 21:12 | |
| japhb | raydiak: Feedback taken about docs. | ||
| [Coke]: Ooh, that's interesting, hadn't thought of that. | 21:13 | ||
| raydiak: I'm not sure if I'm understanding your point about the physics (mostly, whether *you* are working on the physics, or you want *MUGS* to include that), but I've been working on lag compensation and numerical integration of pointlike kinetic motion. Took me a while to slog through wikipedia about numerical integration, sheesh. | 21:15 | ||
| [Coke] | Where would utility stuff go for a game. Genre? | ||
| like if I wanted a method to get the name of a hand, or a method to compare two hands? (or a method to return the best 5 card hand given hole cards/common card) | 21:16 | ||
| japhb | [Coke]: Generally speaking, yes. Though I often end up writing two games in a genre and only then refactoring out the common code into the genre itself. I only started writing CardGame because I knew that would be useful and wanted to compare it to BoardGame in terms of common functionality -- but got sidetracked before that happened. | 21:17 | |
| [Coke]: Yeah, I would put that in the Poker genre. | |||
| BTW, I *super* appreciate y'all taking the time to slog through in the early days. I know using a 0.1 version API is pretty much a research project, and I really appreciate it. | 21:18 | ||
| [Coke] | what about things that could be on both client and server? | 21:34 | |
| I could imagine "name of hand" might be something you'd put in a log or game event, like "threes full of eights" | 21:37 | ||
| japhb | [Coke]: Ah yes, I actually was just thinking about that problem a couple days ago, as it had finally come up in one of my WIP modules | 22:11 | |
| So I'm thinking lib/MUGS/Common/{Genre,Game}/... as common modules that can be loaded by both Client and Server (and UI, I suppose, if that's helpful) | 22:12 | ||
| The only thing (in the longer run) is making sure that version skew doesn't become a problem if people are using a different MUGS version on the client and (remote) server | 22:13 | ||
| raydiak | japhb: just meant that's one of the reasons I'm taking a while. I can see an argument for building in a time sync algorithm when you get to proper real-time support, but besides that no, not suggesting any wild physics/collision additions to MUGS itself | 23:06 | |
| mainly just wanted you to know I haven't forgotten or abandoned it, just taking time | 23:07 | ||
| japhb | That's totally fine. Just the feedback y'all have given me so far has given me a lot to work on. | 23:15 | |
| On the plus side, jnthn++ just released Cro 0.8.5, and I'm currently testing a full build. With that out, I can start bumping dependencies and getting Cro::CBOR released and such. Between the performance improvements I made that jnthn merged into Cro, and the performance improvement that CBOR brings over JSON for packed data, real-time gets a LOT more reasonable. | 23:17 | ||
| raydiak | nicely done :) I know performance of that was a pretty steep hill to climb at first | 23:22 | |
| wrt docs I hope it's clear that I don't mean to be critical. I worry that you'll put out so much creative energy and not get adopters and be discouraged. so I hoped to help avoid that is all | 23:23 | ||
| japhb | No worries, I understood your intent. :-) | 23:27 | |
| I was feeling a bit down about the slow uptake because I didn't understand what I was missing, which is why I appreciate y'all telling me. Things I can fix are way better than unknown unknowns. | 23:28 | ||
| OOC, is the MUGS install guide at an appropriate level of detail, so that I can use that as a comparison point for the other technical docs? Too high? Too low? Off to the side? | 23:29 | ||
| raydiak | I think the install guide is good, I like how it covers common pitfalls e.g. how you might have to install in multiple steps instead of one ginat run with all the dependencies. that wouldn't have been immediately obvious to me. I think it's about at the right level for its audience (that being anyone who didn't succeed at first with the steps in the synopsis) | 23:54 | |
| japhb | OK, cool, thank you. | 23:57 | |
| raydiak | for developer-oriented docs, I'd like to see a similar level of detail or more. high-level code examples of "here's how you implement common patterns and architecture", and then full API docs that cover each class, describe the concept it represents, and usage of each important method for each of those classes | 23:59 | |