Express for the API/Game Cooridinator/File Server. Games MUST register themsevlves with it
A Lit web component base for the frontend find/join game. Games SHOULD register themselves with it (TBD).
| // Basically just a typed facade around PubSub, but the basic goal | |
| // is the same regardless of the backing implmentation | |
| export default class MessageBridge<MessageMap> | |
| { | |
| // ... snip | |
| public subscribe<MessageName extends keyof MessageMap>( | |
| messageName : MessageName, | |
| listener : (message : MessageMap[MessageName]) => void |
| // factory included just to be silly | |
| class ApiClientFactory | |
| { | |
| options; | |
| defaultOptions = { | |
| "apiClientClass" : "ApiClientPrecheck", | |
| "clientOptions" : { | |
| "tokenLife" : 400, | |
| "someDeepConfig" : { | |
| "foo" : 10, |
| // yeaaaah | |
| #include "includes/streamfx.effect" | |
| uniform float minPass< | |
| string name = "Minimum alpha to let through"; | |
| string field_type = "slider"; | |
| float minimum = 0.0; | |
| float maximum = 1.0; | |
| float step = 0.001; |
| <?php | |
| interface IThingy | |
| { | |
| function getClassifier() : string; | |
| } | |
| class DynamicMethodHost | |
| { | |
| private string $methodPrefix = "__handle"; |
| using System.Collections.Generic; | |
| using Zenject; | |
| using SMG.EventBus.Interfaces; | |
| using SMG.Proximity.Players; | |
| namespace SMG.Proximity.GameFlow | |
| { |
| using System; | |
| using System.Collections.Generic; | |
| using UnityEngine; | |
| using Unity.UIElements.Runtime; | |
| using UnityEngine.UIElements; | |
| using Zenject; | |
| using SMG.Common.Exceptions; | |
| /// <summary> |
| polerin [12:08 PM] | |
| Well, lets discuss something. I'm not saying I'm right y'all. Just that I have... opinions. | |
| heh | |
| OK, so the general subject is this: Immutability/static behavior in OOP | |
| As I mentioned in #ideabin, I find it frustrating when objects change state through method calls that don't seem like they should do that. | |
| it introduces a lot of variability and potential for unexpected behavior. | |
| polerin [12:10 PM] | |
| So I feel like there are two general categories of classes/objects in what I'd consider a well structured OO environment. | |
| Data containment/manipulation objects, and command/functional objects. |
| // Copy the below and use it to create a bookmarklet, or paste it into the developer console for the page. | |
| // This should be used after the video is playing. | |
| (function() { | |
| var playerFrame = document.getElementsByTagName("iframe")[0]; | |
| console.log("changing size of iframe:", playerFrame); | |
| playerFrame.style.width = "100%"; | |
| playerFrame.style.height = "100%"; | |
| console.log("changing max width of container"); |
| /** | |
| * New pattern, pseudo-enum. | |
| * Benefits: | |
| * - no magic strings! | |
| * - possible IDE completion | |
| * - easier to track down what values are allowable (explicit list location) | |
| * - better self documenting (container naming describes the intent of the field) | |
| * - easy to inspect the object and see valid states in dev tools | |
| * - possibly better on memory? Need to check references |