SpriteDX

In Phase 1, we built a proof of concept playground which uses Cloudflare Durable Object to support online multiplayer co-presence.

https://youtu.be/VQLYngGVQEw

What do I think? So far, I’m happy with what I am seeing. The demo looks pretty basic and nothing to brag about but just sending the user keyboard states over to Cloudflare DO and having it compute the updates and broadcast it across all users was rather simple to achieve and had a pretty decent latency.

Cost? All this was done without paying a penny to Cloudflare, and I’m quite happy with the free-tier options. The best thing about Cloudflare DO is that it allows for true scale-to-zero experience where I don’t have to pay for anything unless I get real users.

What are the learnings? I think going the route of supporting multiplayer playground is a good move. The ability to “show off“ your character to other people logged in seems like a good community feature that will help with stickiness.

What are some challenges? Instantly, the generated character is shared with other people. People may not want this for various reasons. They want to create it but don’t show it in a public forum.

In my mind, the playground should start in a personal space — a personal room a stage.

Then, we allow them to “go out“ and join public rooms upon their discretion.

Positioning? There is a bit of risk to branding. If SpriteDX becomes a place where people play mini-games, it will have hard time being recognized as a professional tool.

To prevent that, I will approach it with caution and build the private stage first.

Public stage is something we can still support but we would want to keep it minimal as more of a “showcase“ rather than a “hub.”

What are your next steps? My next step is to build a generic private playground.

This playground will host a dark dim lit stage. The character movements can be tested there.

Then I will also make it so that users can tweak lighting parameters and background colors so that they can see their character in different backgrounds. This should help in validating characters.

Plus 1 Features? Instead of having the playground solely be a lonely planet, I can have users share code-sandbox style embed links. This will allow people to share their creations in blog posts. Or just invite other people to see and validate the generated characters.

How would users get to private playground? Entrypoint will be where ever the character entity.json exists. We will add inviting button that ask whether they want to “Play“ their character.

How would users get to public playground? Once they are in private playground, there is a little portal to the public playground. Or may be it is a button. They can “connect“ to the internet and be present in the shared world.

What is number one blocker? There are more than one blocker.

First, our SpriteDX pipelines don’t generate entity.json files which contains animation states. To support playground feature, we will need this.
Secondly, we need a mechanism to load character from OPFS. This way users can load the characters from their local cache.
Thirdly, we need a mechanism to upload the character. Otherwise, the public playground won’t be able to load it easily.
Finally, we also need to build an elegant but simple private stage that is abstract enough and generic enough to fit various validation needs.

Today, I will work on the first part.

Here is the entity.schema.json which defines the schema format for entity.

{
  /** Schema */
  "$schema": "schema/entity.schema.json",
  /** For character controller */
  "kind": "humanoid",
  /** World constrains character style and animation states */
  "world": "machi",
  /** Textures and animations */
  "textures": [{
    "meta": {
      "image": "char-idle-sheet.png",
      "size": { "w": 1024, "h": 768 },
      "scale": "1"
    },
    "frames": {
      "idle_0": { "frame": { "x": 0,   "y": 0,   "w": 256, "h": 256 }, "duration": 2000 },
      …
    },
    "animations": {
      "idle": [
        "idle_0",
        ...
      ]
    }
  }, {
    "meta": {
      "image": "char-run-sheet.png",
      "size": { "w": 1024, "h": 768 },
      "scale": "1"
    },
    "frames": {
      "run_0":  { "frame": { "x": 0,   "y": 0,   "w": 256, "h": 256 }, "duration": 42 },
      …
    },
    "animations": {
      "run": [
        "run_0",
        ...
      ],
      "jump": [
        "run_0"
      ]
    }
  }]
}

I tried adding the computed output to support building of entity.json. However, honestly, I’m getting stuck.

There is a big blocker where the worker-runpod-comfy only treats images as outputs. So, we will need a mechanism to output things like number of frames for each sprite sheets.

Also, the forEach semantics is quite complex. I need to re-think about the architecture here.

It is incredibly limiting to define the schema in pure JSON and perhaps it is a good opportunity to think about control flow using code. We provide pipeline.runner.js file which is pure function that will run each of the pieces. That is it will contain the function to run the pipeline control flow.

And, I ran out of time. Let’s try this again tomorrow.

— Sprited Dev 🌱