Nope, it's based on the lexicographical ordering of the key

Oh okay that makes a lot of sense, time to move from nanoid to ulids 😅

That's also actually quite nice since now I don't need to actually 'wait' before it's stored to emit it back into the chatroom

uilds would work - sometimes its useful to do your own key scheme in case you ever need to use

prefix

filtering as an optimization

What do you mean? I do

entity:ID

now as a key-scheme.

ah then you already are doing it : ) entity sounds like your

prefix

filter

totally application-specific tho

Yeah exactly haha, yeah in my DO for the chatrooms I do

message:ID

, probably have to purge the current storages somehow though now 😅

or you could do

message2:newid

if you want to keep the old data around for migration - but it looks like you are building something new so probably nothing major to keep

No nothing major, any tips on clearing that store?

deleteAll

https://developers.cloudflare.com/workers/runtime-apis/durable-objects

but that will nuke everything for that DO instance

if you just want to clear

message:

you will need to

list

with a

prefix

then make

delete(keys)

calls

Yeah maybe I'll just use another prefix

announcing Durable Object Stored Procedures

Hey, I hope this is the right place for me to ask if Workers and durable-objects are the right choice for me 🙂 I want to code a game like Durable World(https://blog.cloudflare.com/building-real-time-games-using-workers-durable-objects-and-unity/) but without the client, which will be replaced by my Twitch Chat for input to the game. I only need to show what's happening in the game on my stream from a browser window, no input here. The viewers in chat from Twitch will be able to interact and decide what can happen in this "world". I'm confident I can get the Twitch part work one way or another, but I'm not sure about Workers or Pages. Thanks for reading.

That will probably work depending on the size of your Twitch viewers. The thing is that the DO will be created closest to the request initiating the DO, and Twitch will probably output all these messages from only 1 specific location.

So if DO's are the right use-case? Maybe not. There is a runtime memory limit of only 128MB, and since you'll only be able to utilize a 'few' DOs depending on how you structure this it might run out quick depending on the heaviness of the game server and the amount of users.

It might be worth trying though, since Twitch will probably be the 'only' one connected to your DO, since the messages probably come from their API right?

Apparently Twitch supports Pubsub on certain events through Websockets, which you can connect to in your Durable Object. (https://dev.twitch.tv/docs/pubsub#topics)

Thank you, that helped me a lot to understand this more 🙂 Yes, I will use the API or https://tmijs.com/ if possible. What if I wanted to spawn a character they can control from chat, will that create a DO for every character or?

You'll need the durable objects to 'save' the game state, take input and communicate some output back to workers or other clients.

Having a DO for each character will make that 'harder' since you wan to know where that character is.

It sounds like there is only 1 client (Twitch chat?) and 1 output client (your browser)?

Maybe I misread

If I'm reading that right, your only limiting factor is really the amount of messages sent from the Twitch chat. Assuming you wanted to use 1 object for your game state

Sounds like they want each Twitch user in chat to have their own character? Something needs to connect to Twitch to get the chat or a Twitch plugin to accept commands. I don't think a DO can stay running reading the Twitch chat, so they'll need an always-on solution like a VPS to follow the chat? Can be a small VPS. A Twitch plugin could just talk directly to a Cloudflare worker though. I assume a DO per character would work to manage their game data and then a central DO that the characters send updates to manage the overall game state that is transferred the program being rendered to the video stream somehow (websocket?). Each character DO would store info inside itself but also maybe also a KV record per character to store information more permanently or as a backup.

@User's

deleteAll()

will delete everything for that DO instance.. if you want to delete all the data in every DO, things get a bit more complex. If I remember correctly deleting the namespace is the way to go (but I can't remember if you also needed to wait for DOs to be evicted).. If you wanted to start from scratch, I would probably just delete the old binding and start over with a new binding name.

We have the absolutely best community here.. 🙂 But first things first.. how many people do you think would be playing the game at any one time? Which you can translate into how many commands would be going into the DO. Some internal tests we were doing on one of our own projects showed that a single DO could handle 200+ requests/second with relatively little latency if the time it takes to process that message is small enough. And the other limitation would be the 128MB of memory, but I don't think that necessarily has to be a big issue, assuming that a lot of the rendering logic will be done in the browser app and the DO is mostly used for storing state and passing messages from the chat to the browser?

Do DO work with Worker Sites, yet? I asked 6+ months ago and it wasn’t ready.