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.
05:53 japhb left 05:55 japhb joined 21:24 raydiak joined
japhb me: Turns up update rate 21:29
MUGS: Immediately exposes race condition
*sigh* 21:30
... and now I know more about how object instantiation works. 21:45
Win, I guess?
raydiak have you tried googling "raku mugs"? that's quite an uphill SEO battle... 22:02
japhb raydiak: No worse than the one Raku itself already faces, I would think 22:05
But yeah, I recognized that problem. 22:06
raydiak maybe if you sold raku mugs that say "Raku MUGS" on them with a URL or other cute catchphrase. kinda plays well with the whole "broken coffee mug" perl 6 origin story, too 22:13
japhb Could do that with just the logo 22:23
But ... do I really want to open the champagne battle?
raydiak was about to say...you have a logo? 22:24
japhb The one at the top there: github.com/Raku-MUGS
It was meant to be temporary, but I kinda like it, so I haven't gone out and commissioned a new one. 22:25
raydiak oh, that's right. I like the style, though as it grows beyond console and text you might want to at least...spice it up a bit somehow 22:27
japhb raydiak: Yeah, agreed. That was pretty much what I could manage with a very zoomed in terminal window and a screenshot. :-) 22:29
Still, it has the advantage of actually working in Unicode text, so that's a nice benefit. 22:30
raydiak heh I guess that's why I like it, it feels...familiar
japhb But yeah, may need to upgrade the logo to include space ships and polar bears and FREAKIN' LASERS 22:31
Yeah, that was part of the intent. Comfy, but suggestive of the initial variety of genres.
raydiak lol or perhaps some balance between the two 22:32
btw I was thinking that a "how to write your own MUGS game" doc would probably accelerate adoption greatly. I'm still not entirely sure what the intended API looks (or will look) like
japhb raydiak: Yeah, I was planning to do that sometime around late 0.2 (the current dev milestone) or 0.3 (the next one) 22:33
As for the API, 0.1 was mostly proof of concept, so the API was "what felt halfway reasonable and ensured forward progress". Now that I'm working on 0.2, I'm getting more into the "serviceable protype" phase, so trying to fill in/clean up as I discover stuff that's too hackish. 22:37
raydiak Okay, I skimmed the roadmap so I don't give more extraneous feedback. I don't see any mention of 3D at any point... 22:38
japhb There've been surprisingly few major API changes, but quite a bit of nuance.
I kept that out of the roadmap for now just to avoid giving people the impression they'd be getting a scene graph or physics engine anytime soon. 22:39
I am aiming high, but I'm publicly aiming a bit less than stratospheric. :-)
raydiak for a gentler path towards 3d, it doesn't even need to be realtime. I had always wanted to make an online version of en.wikipedia.org/wiki/Score_Four 22:40
japhb Yeah, there are some 3D board game variants that could use a treatment like that 22:42
Still, I've got some ideas for very simple -- but still real time -- 3D games that I might be able to get going when I have a GL UI. 22:43
raydiak I look forward to seeing what you've got in mind 22:53
I still think WebGL would be a really low-resistance start for 3D. With three.js (MIT license) you could bang out some little demo in a day, and showcase it interactively on a website without players even needing raku. Or a full-fledged computer, for that matter 22:56
japhb raydiak: It isn't a matter of difficulty, it's a matter of an overfull brain. I'm juggling a lot in there right now. :-) 22:59
raydiak I was thinking if it'd be helpful, I might write a few little browser game demos, structured to allow easy future multiplayer support. Then you or me or whoever could adapt them to MUGS when it's ready. I'm not entirely sure though how much it would help, and how much of the client you'd want abstracted into a MUGS genre which would turn it into more of a rewrite intead of just "plug in the multiplayer 23:10
japhb raydiak: Those would be VERY useful. 23:20
Refactoring I can do without too much trouble.
The most important bits are separating out state and presentation; most people aren't used to having the state controlled by a (possibly) remote server, they want to have lots of game logic embedded in the rendering code. 23:21
And I can use the basic structure of the browser demo as the beginnings of a WebCanvas or WebGL UI plugin. 23:22
raydiak I've written a couple of multiplayer games before. I tend towards simple deterministic logic, so you can have an authoratitve server, but the client can be predictive for lag reasons. I even wrote one that was so predictive that it knew the entire rest of the future of the game world if nobody's input state changed. Knew when you'd get hit by a projectile in the future, knew if that hit would drop your health 23:25
enough to kill you, stuff like that
The real challenge was holding game time in precise sync across the clients in a way that was stable over fluctuating ping times 23:28
japhb raydiak: Yeah, I know that one's going to be an issue. Still cogitating how I want to deal with that, having lived through years of lag warping in the early Quake days 23:31
raydiak there isn't an easy answer, unfortunately. I think I ended up doing some rolling average ping measurement every few seconds or something along those lines 23:35
anyway, I've been looking for some way to make small-yet-fun contributions I could make in limited timeslices while the architecture is still so heavily under construction. Sounds like this ought to work. I'll let you know when I have something worth showing, get your feedback, make sure the structure is appropriate for whatever plans you have in mind 23:39
23:40 japhb left 23:52 japhb joined 23:53 japhb_ joined
japhb Back from loss of internet 23:53
23:55 japhb_ left, japhb left, japhb joined