Build an Online Game In a Simple Database

All you do is write code. You don't do any infrastructure and you just say space-time publish and your code goes and it runs and we we figure out the rest of how to do that. For Bitcraft, the entire back end of uh the game is only spacetime DB. So all the player movement, the positions of players, the positions of trees, the positions of terrain, all the timer state, all of the buildings, everything 100% stored in Space TV and manipulated by Space. any game that doesn't do uh physics is is almost trivial in in Space Energies.
It's always been a big dream of mine to write my own serverside code for my games because it allows it to do a lot of really cool Unfortunately, it has always felt unapproachable for me as an indie developer. But this has recently changed as I have discovered space-time DB which promises to solve this problem. In this conversation, I'm talking to Tyler Cluty, the head of Clockworks Labs. What I believe the dream should be instead is the cloud is a giant computer. It runs an operating

system. I take my program and I run it on that operating system and I'm done. There's something very very magical about that. As soon as you have to be like, "Oh, I got to open up, you know, I got to like open up AWS panel again." Magic lost.
They're currently working on an MMO called Bitcraft Online and on a product for developers which is called Spacetime DB. I'm very excited about this one. We'll try to figure out is it all hype? Is it real? What's behind it? Let's dive right in.
Spacetime DB uh is a general purpose relational database. It's a little bit different than other relational databases.
Can you quickly explain what a relational database is?
Certainly. Uh so a relational database um was originally invented by Edgar Cod back in 1970 I believe. And essentially what it is is it organizes your data uh information essentially into tables. And the nice thing about the relational algebra is that you just operate in the space of sets and through those

operations you can select certain data, you can aggregate data and so on. In practice it's uh messier I think than it sounds. Uh but that is fundamentally what a relational database is.
Everything is stored in a table. So also for example your the entire game you're working on like it's called Bitcraft online right is it's all everything's just tables.
Yes. So for BitCraft the entire back end of uh the game is only space time DB. So all the player movement the positions of players the positions of trees the positions of terrain um all the timer state all of the buildings everything 100% stored in space DB and manipulated by Space DB. The other thing I'll say about the relational model uh and relational databases that I think is important is there is one fundamental difference between sort of a a rust or crructruct and table. Uh and there's many ways to put it but one simple way to put it is there's no pointers. So a pointer is a very interesting piece of

data. A pointer is data which leaks the physical storage location of your data into your data model. Right? So it is a number that is in your data that um actually represents where something is stored. The the whole reason that Edgar FCOD came up with the relational model uh in the beginning was that on hard drives people were storing data in sort of complex data structures and the only way to get that data out of those data of those data structures on disk was to write a program that essentially walks those physical locations and collects all the data together. So if you wanted to change your query, you had to change your program, which was not great. In the relational model, what it does is it says we're not going to put pointers in our data. What we're going to do is we're going to have ids that can reference other data, but those ids are unrelated to where the data is stored. And this is um I believe called I can't remember exactly the name of it is, but

it's basically um physical independence or something thereabout. I don't remember exactly what the the term is. Um, which just means my data is in no way connected or related to the physical location of where that data is. And that's a really important aspect of relational databases. And that's sort of the the fundamental difference in some ways between the hey, I have just a bunch of strrus floating around in my memory
and um a relational model. I will say it is surprising to me that we in the 1970s did this transformation for discs, hard drive discs, but we never did it for memory RAM for some reason. It's unclear to me why in Space TV is sort of an attempt in a way to actually go the final step and also apply it to in-memory data.
God, could it be that it's um maybe a little less efficient? because the way it sounds to me is that instead of knowing exactly where to look, I basically just get an ID and I need to find the correct place, right? So, it's maybe a little more expensive to to find

the place. Um I mean there can be but if you think about um what I am saying it's sort of it's sort of like saying well you can have an ID which is backed by a pointer in a way right so
in fact uh I'll get into this a little bit but that is exactly what um the ECS model in games does and I'll have to take it aside to just talk about what ECS is. So ECS is a uh model of programming that is popular in sort of data oriented design um that game developers came up with because the uh the sort of collection of pointers memory model was not working very well for games in terms of performance on modern CPUs. So ECS stands for entity component system where an entity is just an ID. So in this case it's the ids that we're talking about like like in the relational model. Components are strrus. So they're just data, pure data, no no functions. And systems are uh sets of pro of programs that operate on sets of those strcts. And the reason that game

developers use the ECS model is because um instead of hopping around all around in memory, which is very very slow on modern CPUs because of cache invalidation. So you're sort of loading a bunch of memory into your cache and then throwing it all away and going somewhere else in memory and loading a bunch. They can set up an array of all of these values and run over them all very very quickly because the computer is prefetching them into the cache.
Yeah. Yeah. I see.
And so in a lot of ways actually the relational model for modern hardware is much much more efficient than the old programming model that we have. So they use in in that case the um entity ID as actually it is also the physical pointer but it's not a pointer that's specific to your memory. It's a pointer that's relative to the start of an array. So it's part of the data itself and in that way you can kind of squint your eyes and it's very very similar to the relational model.
Got it. Okay. I see the similarities to

ECS. So for for example, what you're saying on the server side, doing something like looping through all of the players and updating their positions is essentially like ECS, right? Cuz you
That's exactly right. You're just looking at a table and you're going over all the pages and as you go all the pages, you do a transformation on each row.
Okay, there was uh So what differentiates DB from other relational databases? That's where we left off.
Yes, that's where we started. The first thing is is this part and it's very important which is um it eliminates all of this. It it brings your database into memory into your program's memory. So you don't have to do any of that coordination where you're translating between like one data model uh on your server and then serializing it and then going across the network and then unserializing it and then processing all of that. Um, not only is it a lot easier to handle because in Spacetime DB, you're sort of implicitly in a transactional context. So, you don't have to think about any of that stuff, but it's also way way faster because you don't have to go across the the network to talk to your database and serialize things back and forth. I would say

probably the vast majority of the work that a web or game server does is serialization.
Um, and so we're eliminating a huge portion of that work just by putting them together.
So, that's that's one thing it solves. The next thing it solves is also very important because the clients connect directly to the database. We can do all of the uh serialization and messaging and publishing to your clients directly without you having to do any work. So you write your program, you upload it to run in the database. It communicates with the database. Your clients can query the database and as the data changes, they will actually get pushed updates in real time. And that's relatively complex code that you no longer no longer have to write. It used to be I mean well before Space MDB that if you wanted to write a game that's real time it's like okay well in the beginning there were sockets and you had to connect the sockets and then define a a binary protocol for your messages and then send the messages across the network and serialize and deserialize

them on both sides and then you could start writing your program. with Space NB you just don't have to do that because we've sort of inverted the the relationship of the database and the and the server. So, so that's um problem number two that we solved. And then problem number three is because you don't have to because you're uploading your program to run inside of the database. Again, we can just do all of the deployment and infrastructure for you. So, all you do is write code. you don't do any infrastructure and you just say space-time publish and your code goes and it runs uh on on the computer and we we figure out the rest of how to do that of all the persistence of the storage and the state and and all of that stuff and what I will say is I believe that that is where the cloud should be. So if you look at like your desktop operating system for example uh you write a program you call a bunch of sis calls in your desktop operating system and it handles all the hardware coordination and making sure it gets to disk and so on. It gives you a file system and sort of all these sort of

highlevel uh abstractions. If you then go to the cloud uh and you want to write a program for the cloud um it's not a single computer where it's like an operating system where you run things actually it's like oh I got to do route 53 and I have to get an EC2 machine
and I have to put my data in S3 or Aurora or whatever it is and I'm picking just Amazon but it's the same for all of them. and it's a collection of like 200 services
and then you have to run Kubernetes which is going to coordinate between all of your services and make sure they're written but it doesn't really handle state so you have to set up all your state and write to specific sort of hard drives and figure all of that out and what I believe the dream should be instead is the cloud is a giant computer it runs an operating system I take my program and I run it on that operating system and I'm done and so that is the the third uh promise that uh deliver on which is just get rid of the infrastructure.
If you had to write like a or a list of things that Space DB is very good and

suitable for and a list of things that it's maybe not so suitable for, how would that list look like?
It's a good question. Um I would say let me talk about it in two parts. So I will talk about it first conceptually and then second um where we are today and like what sort of practical reality do we have in terms of what uh SDKs and so on are available. So uh as a concept if you are building an application where all or most of the state is in a relational database already it's a fantastic use case for it. So a normal web server that kind of thing uh very suitable for it. All of your state lives in a relational database anyway. Now it's just going to be more performant. It's going to be easier to deploy and you're going to have to do less work. That's triply true for the same application that does any real-time synchronization with clients. So if you have live updating data for example you have stock tickers or you have people doing like sort of a multiplayer application like Figma or something like that where you have state and you want to see it updating in real

time as other people doing it that is going to be also very very suitable for space envy because we're going to do all of the synchronization for you. you're just going to write queries from your clients that kind of the the ultimate form of that is in some sense a game, right? So a game is all of that plus um you have state in your game server and then you also need to do real-time uh synchronization. So any game that doesn't do uh physics is is almost trivial in in space MDB. So, if you want to make a chess game or in our case an MMO, um I would not call it trivial per se to make an MMO even with Spacetime DB, but uh it makes it a hell of a lot easier. I will say that that is also very suitable. The things that are the trickiest to currently do in Spacetime DB right now um or just in general is if you have to do a physics simulation. So let's imagine you wanted to use the Unreal backend physics simulation and all the path finding and so on and you wanted uh to have your state stored in spacetime DB. You what you really need

to do is you need to you can't do that physics simulation inside of spacetime DB using the Unreal Engine's uh APIs partially for licensing reasons partially for technical reasons. Um, so what you'll have to do is do the Unreal physics sim outside and then sort of publish changes uh into your SpaceAC NDB state which then you can synchronize with clients. Um, you can of course do your own physics simulation inside of Space NDB. That's not a problem. We have people that are that are doing that. Um, but it's difficult to pull in sort of external things. So that's that's like conceptually what works in space and what doesn't. It's really good at things like social networks where something like for example Twitter if you wanted to make something like that because you or real-time chat something like Discord is actually sort of perfect uh because you have this real-time chat you have complex permissions and I can talk about the permissions model later uh where you really need to be very granular about things and you need to have complex relationships like oh if if I'm friends

with this person then I can edit this if I'm friends with this person and I am an owner of this um server then I can add a tag to them or whatever it is that I need to be able to do uh in discord with complex permissions. Um that is something that works really well for spacetime DB. That's sort of conceptually where it is. I can then talk about sort of where we are today. So one of the the current current limitations of Facetime DB which we are rapidly working on fixing uh is that you cannot from within the what we call the server module or the piece of code that you upload you cannot make web or connections outside of it. So it's sort of this pure blob of code that runs fully within the database. Um, very shortly we're going to be releasing a new feature which will allow you to do HTTP calls from within the module. And that frees you up to do, oh, I want to send an email or I want to
call the Stripe APIs or some some kind of a thing like this. That's the that's the type of thing that right now what you do is you actually spin up like what

we call a sidecar service
and you subscribe to the data and you sort of relay things out.
Uh, but that is unfortunate. You should really be able to do that inside. And then the other thing is we want to provide more SDKs. So right now we don't have a Swift SDK. We don't have an Android SDK. We don't technically have an Unreal Engine SDK, although that is coming very, very soon. So, for people out there who have been looking for that, um, it's coming, I suppose. Lastly, we'd like to do more in the way of providing libraries to people. So, physics libraries, if you need to do that or,
hey, I just want to make a chat application. Can I pull in a chat library? And then I just have
all of that stuff ready to go.
So, I I roughly know how it works. I I've done my research. I've tried to build some stuff with it, right? But like for the people who haven't seen it before, maybe can we quickly explain how you use it? Like let's say I want to start building with it like what what are the main concepts I would have to know and understand to start building. Gotcha. So um the first one is is the one we talked about a little bit which is the module. So the the module is the

the sort of ground truth of your application. It's all of the code that's going to run inside spaceb. it defines your database schema and the reason for that is we want the types of your schema to match directly with the types in your code so that always when you're dealing with the uh the data in your database you have a typed version whatever language you're using so that currently is in web assembly we are going to be adding more languages to that we're also going to be adding TypeScript so you'll be able to just write your your thing there right now today you can use Rust and C so in your module, you'll define your set of tables. Uh your tables are just sort of it's similar to like an OM, the way you would define a table in an OM if you're defining it from a code first perspective. Um where you set up a strct and then each field would be a column and then you can also add different modifiers to that like this is a primary key or this has an index or this is a unique column

and so on and you can also add indexes to the overall table um and that kind of thing. So that's that's one thing and then we have the concept of a reducer and a reducer is a function that you write inside of your module which is exposed to clients. So this is sort of like a public API for your application and uh fundamentally it's kind of like an RPC call. So you have your client, they're going to call your reducer. Your reducer is going to execute. It will modify rows in the database. It will check authentication. It'll check authorization. Can this person do this type of thing? uh and then just like you would on your normal server pretty much and then it will make modifications to the database and then it will complete. Notably uh reducers are uh atomic. So what that means is they run in a transaction and if you fail for any reason so if you return an error or you panic or something like this that transaction will get fully rolled back and nothing is applied to the database. So if you're going through and you have very very

complex logic and then at the very end you do some kind of assertion and it didn't turn out the way you expected, you can just assert that and and you'll roll everything back.
And this is really really important uh in a lot of security scenarios where you don't want people you don't want people to get your database out of sync or in a sort of a bad state.
So you always want to know you're fully transitioning from state A through a valid transition into state B and there's no halfway point. Um, and the example I would give of this is a lot of MMOs historically have had gold dupe bugs. And there's a lot of reasons for that, but one of the main classes is incomplete transitions from state to state. So if I am trading with you, uh, the way you program that is you take my inventory items, you might put them in your inventory and then delete them from my inventory. But if you put them in your inventory and then a user figures out a way to throw an error uh, and never delete them from my inventory, you've got a gold. M yeah.
Um or worse, you did it the other way around and I deleted the items from my

inventory and put them in your inventory and now I've got a problem because I've got customer service being called all the time about people losing their items,
right? And you did not have those kind of problems in Bitcraft online so far or did you at least not being caused in this exact way I guess?
Yes. So we do not have we cannot possibly have gold due bug bugs of that character. We actually have had gold do bugs but they are of the character in this case uh where we had a uh an integer overflow.
People figured out how to do that and we resolved that.
Um so I guess that that takes me to the next uh part of uh understanding how to use spaceb which is publishing a module. So if you get your module you define it you get all your functions ready. Uh what you can then do is you publish the module uh to the database. So that just is spaceime publish. That's a command you run on the command line up. It goes to the database. Um, one of the really cool things that we can do is we can actually modify the code of your

application. It's running in the server without disconnecting any clients because they're connected to the database. So, we can swap out the logic of your application and nobody is the wiser. So, when we had Gold Dugs, we could very easily just change the reducer code and republish the module and we didn't have to take the game down or anything. So, you can do it like 30 seconds after you discover the bug. Oh, that's crazy,
right?
Uh, which is pretty exciting. Um, so that's the that's I suppose the second part. And then the last part is clients. How do they interact with the database? So, we already talked they can call reducers. That is actually the only way that they are able to modify the database state. And this is pretty important because store procedures have been a thing for a long time. Um, they have, you know, uh, a troubled history of being able to operate them easily. Partially that's because they're all separate and uh who knows which who updated which ones when right in space you have the whole module it's your whole program you just upload it it's the whole version it's very easy to to uh maintain um but then also you know

the permissions are very complex in in something like postgress you have user role based permissions so I'm not going to give my users access to the tables I can kind of try to set things up so it's maybe okay but there's a lot of security problems with that you have SQL injection and so on So in spac you actually cannot modify the data as a client unless you call a function which is conceptually almost exactly the same as how you've set up your servers in the past right typical server sits in between your database uh and your clients and really all that it functionally does is reduce the set of operations that you can do to the database um it doesn't usually increase them in any meaningful way it just sort of eliminates the bad
okay that's where the term reducer comes from Um it's actually not although it maybe it should be it does only reduce. So the reason it's called a reducer I actually stole that from react redux.
Okay.
So the reason it's called a reducer is you take the database state
and a a set of arguments or in this case a request and you reduce like like a map

reduce you reduce that request into the database state and you get a new state and you sort of just do this one after another to transition from valid state to valid state as you go. And that's actually where the term reducer from React Redux comes from originally where you're sort of taking your state and you're transitioning it through a bunch of reductions. Um, if that makes any sense.
So users can write to the database using reducers you wrote that kind of verify if you're allowed to write and what you're allowed to write and so on and so forth. How do clients get data from the database?
Okay, so this is a great question. So clients get data from the database uh by subscribing uh to the data. What this essentially means is they they make something like a SQL query against the database. But the interesting thing about that is it's read only of course and then also uh we do streaming data. So it's not just that you get the result of the database but any time that query

changes you get the changes to that query as well if they match your query. So you could say select star from players where position affected I mean it would be a longer query but where position is around my character and then anytime a player walks in or out of range of my character I will hear about that player on my client and the what it lets you do is basically create your client make your client sort of a read replica of the servers database state and the cool thing about this is that not only can you do it for your normal game clients but now you can have all kinds kinds of clients, right? So, you can have a client that's an admin client or you can have a client that's an AI agent client and it subscribes to different things and it sends different uh RPC calls, but you didn't have to write any new server code. So, historically, like, oh, I made my game client. Well, that's the only client that connects to it because the server needs to know what data do I send it. Um, and so that's usually built into the server. And with Space NDB, now it's actually built into the client. So,

different clients can have different things and you don't have to write another line of code to be able to do that. It's sort of like the difference between a GraphQL versus a regular uh API thing that you would set up in your website, right? If you have an API, you got to do you got to think about everything from the beginning that you might want to query from your from your API and you're sort of rebuilding a query engine
in a sense when you define that API. And GraphQL says just let the clients define what they want uh and we will determine if they can do that.
So then that brings you to permissions on read permissions. So uh couple things with read permissions. One is you can have private tables. Those cannot be read by anyone. By default, tables are private. So you have to explicitly say I'm going to make them public. If they are public, uh they're subject to uh rowle security rules. And what that is essentially is you write uh a view in your server which defines what clients are allowed to query and it restricts the set of them. There's other ways of doing that as well and we want to add those as well. So you can also imagine basically a function that you would call

that's written in procedural code that sends data down to clients uh when you call it and keeps that data up to date. That is really cool. It's really useful. Um there are certain situations in that version where uh it's not performant enough. Uh basically if you do scanning and that kind of thing because of you have to calculate the dependencies of what data has changed uh you might have to send more than you actually really truly need to and if you define it as a query inside of your database we can actually take the the uh like the derivative essentially of that query and only send you the changes that are happening.
So we're doing both. Uh but that is how you define the the read uh the read queries in the read permissions in space.
Got it. But basically the simple answer is you subscribe to the data that you want to have and then you automatically receive updates plus that's right plus a couple of caveats for for the specifics and security stuff and so on. Where are the limits of of this entire system? Like for example, you mentioned the

entire thing is stored in memory, right? So the entire database is stored in memory. So does that mean RAM? Does that mean I'm sort of limited to 8 to 64 GB or something or what's what's sort of the limit on that?
Yeah. Um it's a good question. Uh so right now space time to be a single database is limited to the RAM of a machine. That is to say the whole database lives in RAM. Important points about that. That's how it is today. There's nothing that would prevent us from uh also writing it to disk. Uh that's just the the way we have written it because we knew for games like you cannot afford to add a bunch of random latency. Um but if you think about RAM, it's just a cache for disk which is just a cache for S3. Uh so you can go all the way back um to uh to whatever you want as a backing store. Um we think you can achieve an incredible performance with RAM. So that is what we've restricted it to for now. I think the way we would add

allowing people to write to disk is we would um by default do RAM but then allow you to specify on a table this can be written to disk. So for example, if you have logged out players, you're not going to be you know when you they'll you'll pull them into RAM once when you log in. So you'll move them from the logged out players table and put them in the logged in players table and the loggedin players table will be um super super uh speedy because it's it's fully in RAM. Uh so there's there's no problem there. And we can even do complex things like you know sort of advanced caching like actually you just put all your tables as hard drive tables but it's fine because we are intelligent about which ones we have loaded into memory.
The other thing I'll say is the limit of uh RAM is actually not as limiting as you might imagine. You mentioned 64 GB, but you can regularly
get a machine with 1 TB or 2 TB of RAM these days. It's actually not very complicated. It's not much more expensive than you would normally have if you needed two terabytes of RAM anyway. So, you're either getting a bunch of different machines or one machine with a bunch of RAM. And then

the last point I'll make about that is that your applications uh can comprise multiple databases, right? So, there's no reason you need to have one database. Bitcraft actually has 10 that it operates on top of where we have sort of a a database that keeps track of the overall game state. So things like um usernames, anything that needs to be global to all players. Uh and then for the sort of the physics interactions in the world and the movement and things like that, those have a region database and that that um serves that particular region and you can move from region to region. So I was about to ask that's how you can scale uh space time to be horizontal.
So let's for example say I I would make a session based game right where maybe I would have a matchmaking server/ database and then
could I spin up a new module for every session so that I like for
Okay, so this is a great question.
Um let me tell you how it is now

and how you would do it now and then I'll tell you how we want it to be. So right now uh if you had a that kind of a thing, what you'd do is you'd have some kind of service uh on the side that would spin up the the sort of the ma matchmaker module and players would connect to that and they would make matches and then when you created a match you would uh call the spaceb API and you'd spin up a matchbased database just for them and then they would connect to that match and they would do their match and then when it was done you archived it or threw it away, whatever you want to do with that data um at the end of it and that would write back into the matchmaking server. What it should be and what it was sort of always intended to be is um actually from within a database you can start up another database. Very similar. I mean these are not new ideas. This is the same thing that Unix did in like 19 whatever the heck um where you should be able to uh spawn a new database from within a database programmatically at runtime dynamically. Um maybe even fork

a database. So just like you can fork a Unix process should be able to fork a database. Um and so the way you would do it then is you would uh just in your matchmaker the matchmaker would decide that that a match has been created and you would spin up a database and then you'd have your clients connect directly to database. No external servers needed to spin databases up and down. Uh so that is how you do a matchmaking thing. Um and I should also note uh we have interm module communication for bitcraft. We haven't released it live. We want to make sure we dial it in uh for everybody before we do that. Um but uh you can send messages between databases. So what it really is is it's actually an actor uh system. So sort of the actor model um much like Scola actors and and Scola aa actors I should say. um you where you can send uh messages between different actors in space to be each database is an actor and you can send messages between them as well
because obviously if you run it on multiple modules that would probably

also mean that you don't have to run everything on one machine right you can
certainly
and we do yeah for big craft we run it on I think nine machines
that's still not that much for for like an entire giant MMO world that's still
it's true well we've eliminated a huge amount of the work that normally is done which is all the serialization between the database. So
so that was the memory limit limitations like for the for the compute limitations how expensive can you make a reducer should they always be like very short or can I can I have reducers run for like multiple seconds or what's kind of the deal with that?
Yeah, so this is a this is a good question. Uh sort of a nuance answer. Um, so right now the way that Spacetimed DB works, we've actually tried several things, the fastest one so far is just big old lock on the database. Do your reducer, release the lock, continue on. And because the the code is actually executing in memory next to your data,

your transactions are typically quite short. Um, so something like a microcond or thereabout. You can of course write whatever logic you want. So it can get up to milliseconds. If you've written things very very poorly, it can get up to seconds and that will uh not allow others to uh write to the database at the same time. We have not had that problem. In the future um we certainly plan on doing um multi-version concurrency control uh for the database state. So as transactions are executing other ones can be executing at the same time and as long as they don't conflict, they will both commit. What we we actually implemented that originally, but what we found was very quickly the bookkeeping of MVCC can actually slow you down more than it speeds you up. And you want to be careful about that, especially since
um on a given machine, a lot of the work that you're going to be doing is actually not writing to the database or running your reduces at all. Most of it is computing subscription queries

because that's an N byNend problem. If you have one user next to nine other users,
then every time anybody moves, all the other users have to hear about it.
So you have, you know, a hund if you have each person making one change per second, you have 100 messages per second going out.
I see.
Uh so you just have to be cautious about that. Um, one thing you can do for that is although we would run your writing like your uh mutating part of the database on one machine in principle we could have multiple machines actually serving the subscription queries that are replicas,
right? So those don't have to happen on the same machine and in fact we plan on doing that as well. So that would allow you to scale up your game even further
or your game or application or whatever you're building much further because you're you're doing all the mutations and you don't have to lock the database or do anything to read data. you just didn't
got it. So for for the time being it's a better idea to basically keep the reducers short and what I've already sort of heard out of earlier answers is

that um the way you can kind of get around that is by con connecting your own machines to the server like let's for example say you have AI agents or something that are a little more expensive to run then you just run them on separate machines that connect to the database.
That's exactly right. So I think we do this uh in BitCraft maybe for some AI. So I don't mean AI
like LLMs. I mean traditional game AI.
We do some uh logic uh on the on a separate stateless machine just to make it so that we can do kind of whatever path finding complex logic we want. Um and then that will subscribe to data like any client and then write data like any client. Uh it just in this case it has different permissions because we know that there it's a special client.
Obviously the dream uh like if I can add something to the to the developer wish list which I'm sure is already quite long.
Obviously the dream would be to uh be able to spin something like this up on the on the cloud without having to worry

about it. Just be like okay this is like one of the like maybe a virtual machine connected to the database. I don't have to worry about it. Run that for me.
You mean the the the sort of the sidecar types?
Yeah. Yeah. Exactly. If I like for for example let's say I have some expensive AI stuff to run that I I don't want to block the database with that or
or for example one other example I can come up with is um I have a level generator that every day generates a new level and like the generation I don't know takes 10 seconds or something I don't want to block the data
clarify so if you can do it in space you can already do it today you need interm module communication so what you would do is so we have the the cloud we have we have a cloud service called main
cloud Um, it is currently free. It's going to have a free tier. Um, we're going to have a probably a few other types of tiers as well. Um, but what you can do is you can just say space time publish your main database and then space time publish your sort of side database and set it to be in memory only and then

that will just be there and it will be sending messages between your real database sort of your core database and your your expensive AI database. The two things that you're missing today to be able to do that are interm modle communication which we only have internally.
Got it. Okay.
Uh and you are missing um the ability to do API calls because maybe you want to call out to OpenAI or something like that.
Right. Right. Right. So I could for example I just I could spin up another module and that module generates a level for 10 seconds and nobody cares because nobody's connected to that database and
the two databases are connected. Yeah, I see. Okay.
That's exactly right. uh and um one thing I'll say is that it's it's in general a good idea to not do a lot of uh work uh on your servers
without releasing locks and things. So a lot of times what people will do is they'll open an interactive transaction with something like Postgress and they'll do a bunch of round trip times. So you know like oh I'm going to I'm going to like get this user out and then I'm going to modify this thing and then I'm going to get this other piece of data out and I'm going to modify this

thing. That whole time everything that that's touching if some other writer comes through you're locked on that. So you have to wait however many hundreds of milliseconds to be able to do that. So if if your workload actually tiger beetle had a really interesting video about this recently. Um but if you have a workload where um it's at all the paro distribution where most of your uh users want to access one particular piece of data for example a popular YouTube video where everybody's liking the same video
then you're going to have a really bad time because uh every one of your web servers is opening a connection to Postgress talking over an interactive connection locking that count while that's happening and then releasing it. Whereas in space time to be because you're so much closer, there is no roundtrip time and you can do things much much faster.
Okay. Interesting. That's interesting. I want to list you a couple of the like the the ideas I had of things I could make with the space time and just hear your thoughts on it. The first one
um that came to came to my mind is just

the leaderboards. Like I I had a look at your black hole IO example.
Yep.
It was too complicated for me and I need like a little more hands-on experience. like surely I can make uh leaderboards with this. So that's a my first my first space DB project is just a leaderboard. But what excites me about it is that I can um obviously customize it like for example I can add a timestamp for when it was added. I can add verification. I can for example hide the entire leaderboard and say this only becomes visible um at the end of the month or something.
Right? Then also like what what I mentioned earlier like the daily the daily levels for example every day the server splits on a new level or something. Also another thing is analytics. Do I'm sure you also use space time for analytics in Bitcraft right?
We do. So um a little bit of uh actually before we go into that I do I will want

to say uh there is for our game externally made not actually by us
um a website called bit jeta so it's bit t j i ta I think it's.com and uh they have built leaderboards for our game so we didn't even have to do that is one of the cool things
is because it's so easy to use spaceb other people have built sort of live updating data uh uh leaderboards for us so you can actually see who are the top players in Bitcraft and what are they doing and they've also built pretty complex things like um they have a a marketplace tab where you can they'll compute arbitrage opportunities. So they'll basically say hey there's this person selling this for 30 gold in this area and this person buying this for 40 gold in this area and they're this far apart. So you can look at the distances versus price difference and it will tell you like what is the best arbitrage opportunity which is pretty incredible and I have to say um very excited
and do that.
Do you just allow them to connect to your database or do how do they get the

data?
So all clients do already connect to the database.
Okay.
They're restricted in what they can see with rowle security rules. Right now we probably allow people to see more than we should but that is a business decision. It's not um a decision of
got it
uh technical uh requirements.
So they just have a game client running somewhere and uh getting all the data from that to update there.
Uh they they have their own client. It doesn't have to be a game client. Um okay. So it's it's
it's not our game client like our game. It's whatever game and they're just subscribing to the data with their own set of queries that they've determined and we determine whether they can or cannot see the data.
Oh, okay. Got it. But this one of the really cool things is people can build off of your game without having to you to make a bunch of complex documentation about what the APIs do. It's self-evident from uh from the you can read the spaceime DB documentation instead of having to build a whole bunch of Bitcraft specific API documentation and all of that stuff. And then like I said if if you haven't built in the

particular websocket protocol they have to use like a hacked normal game client. It's much much harder to build a leaderboard for a normal game
than it would be for Bigcraft because of space.
Interesting. Which uh sort of changing direction here for a second again, but also interesting topic is uh very verification how you identify users cuz for example I could also imagine scenarios where I'm like
I don't want just anybody to to be able to see this data and to call these reducers. I for example I only want Steam players to be able to connect to this. How would you do something like that?
So the way we do this uh is uh Space MDB has builtin compatibility with Open ID connect. Are you familiar? Well, I suppose for our listeners I'll just briefly go over what open ID connect is.
So open ID connect is effectively it's what you see when you see like sign in with Google or sign in with Facebook or sign in with Apple or whatever it is that is all going through open ID connect. It's built off of the OOTH 2.0

0 protocol. Notably, open ID connect is to be distinguished from open ID 2.0, which is not the same thing, and also open ID uh and OOTH 1. So, OOTH, Open ID Connect is built off of OOTH 2.0. It's a bunch of uh JSON web tokens that get passed around. But what it allows you to do is have somebody sign into your game with a particular identity issuer. That issuer can be Google, it can be you, it can be um what we're about to launch very soon called spacetime off which is sort of just another off provider that's integrated deeply with spacetime DB and you don't have to worry about it like you don't have to think about how that works. Um and then inside of your module you can uh get access to the uh the issuer. So you can find out who issued this token and restrict it restrict connections to only issuers that you approve. Um when clients connect via vit

be it by HTTP or by websocket you can check on connection that they have the appropriate uh credentials and if they don't you can deny the connection
and does that also support verification via steam for example?
So um steam is interesting because it uses open ID 2.0. The answer is a little bit more complex because of that. So, Open ID 2.0 is different from Open ID Connect. It's like the older version and they never updated it,
I guess, because they're Steam and they can do what they want. Um, but that's a situation.
Um, and so, uh, Spacetime DB doesn't support that by default, but we would like Spacetime off to do that.
No matter what, you can always get around it. You can do it yourself. So, for example, you can have be your own issuer issue your own tokens, and your issuer on your own servers can do whatever dance they want to do with Steam to make sure it works. We do something like this for Bitcraft because you can sign in. We have to verify that

you have bought the game on Steam to be able to play the game.
So, we already do this type of thing. That is going to be much much simpler when we release SpaceTime O, which will have built-in Steam support.
That goes on my wish list as well. Authentication with Steam.
Uh cuz obviously if if players logged into Steam, they don't want to log in again into into something else.
Yeah, exactly. I mean, that doesn't make sense at all. And I think what we're trying to do is we looked at okay so we've been at this now for I suppose 6 months or so terms of seeing what happens after 1.0. Um we've looked at what people have uh been doing and our number one goal is anything that people have felt the need to spin up their own infrastructure for or their own services or whatever that is we should be have the way for them to do it just directly in spaceime to be because that is really the magic when you can just spacetime publish and your app is just working. There's something very very magical about that. as soon as you have to be like, "Oh, I gotta open up, you know, I gotta like open up AWS panel again." Magic lost. So, we're just trying to hone in on that so that you never have

to do that. That's the goal.
Yeah, I'm very I'm very on board with that vision. Obviously, time will tell how how realistic of a vision it is. I I hope that that it is.
I think it can be much more real than it than it is today. So, we're gonna For sure.
I talked to um Eric from Photon recently. I'm not sure if you saw saw that podcast. I haven't actually. That one I definitely want to watch.
Yeah, it was a was an interesting one. Uh I I briefly mentioned spacetime DB something. He he didn't specifically talk about it. I don't want to put words in his mouth, but sort of what I reading between the lines what I heard from him is that he's a bit a bit skeptical skeptical about the the efficiency of these generalized solutions like these uh solutions that try to do it all right. It's like obviously Spacetime DB feels like a very generalized solution. It can do kind of almost anything except for maybe at the moment physics and so on. Wondering what your thoughts on this

is. Is space time do you see spacetime as a very general platform? Do you see it as a specialized platform? So I think there's two ways to do generalized uh platforms and one of them
is troublesome and one of them I think can be what it promises to be. So, uh I think one way to do a generalized platform is to say, hey, we're going to be a Swiss Army knife and we are going to like have all these appendages and like, oh, you want you want a multiplayer module, we'll add that on. Or you want um like a leaderboards, we'll implement the leaderboards for you and we're going to do all of this stuff for you. Uh and then we'll have like a separate thing for this. I would say AWS is for example one version of that where yeah if they need something new they just sort of add they append to it um in this kind of way
and then when you go into their backend interface as a first- time developer you you get a stroke because there are like so many
stroke but you cannot deny that it is

not general like there there is something for everyone
uh in there the other way I think to do a generalized solution is to think really hard um and try to boil the problem down to and it doesn't always work. It's like sometimes there is no general solution. It just there the situation is different. It's just very very complex and you can't actually do it. But sometimes rarely occasionally if you think very hard there is the appropriate abstraction that gets you so far and I guess the analogy I would use would be files in Unix, right? So they added system, you know, standard in and standard out. And they said like everything's a file and we're going to have these small programs that just manipulate files and the network is a file and everything's a file. And with plan 9, they wanted to go even further and make everything a file even more so. And that is something that bought them a huge amount of success. Uh it it was a really good abstraction

uh to get a lot done. And I would like to believe uh and I I do believe that uh the relational model has proven itself incredibly versatile over the last 50 to 60 years. Um and Spacetime DB is actually not even very innovative in some ways. It's just
taking it just just the last mile where it needs to go to be able to bring that abstraction sort of into the operating system level. So you know previously Unix you got files in spacetime to be basically an operating system. You take a program and you run it. Um but it manipulates tables instead.
Y
uh and that lets us do all the things like queries and real-time synchronization and mapping the data directly to your strrus as opposed to being like oh I have a file and I got to apply a binary format to it and all of that stuff. So he may be right. I'm not sure. But uh I believe that this is a this is an abstraction that has legs uh and that actually can in a lot of ways solve a lot of problems. There are things that we can do to make it better.

Uh so that like I think it's
it hasn't filled out the whole space yet. For example, one of the things we could do we do not currently do is we could take your server code the module and we could actually execute space time to be on your client as well. And then we could do client side prediction because we have your server code and we have a copy of the game state um or at least a portion of the game state. And if you have a um reducer that doesn't access any state that your uh your server has but your client does not have. So you would mark like a reducer like hey this is predictable. Then on the client you can actually just execute that and find out what would the server have said if it's got the same state and just do that thing before hearing back from the server. And then if you hear back from the server and it worked great. if you hear back from the server and it didn't work, you got to roll back and try to reapply or something like that.
So these are the types of things that like wow actually this abstraction has got way more to grow into but is um and I think it also has to come with

performance improvements.
Yeah.
Right. If it if it were just yeah it's a great abstraction but like it doesn't work with modern CPUs um that would also not be good. In this case, it seems to be a little no compromise, I have to say, uh, in terms of the the sort of the the right abstraction matches very well with how modern computers operate. I I'm not going to say we got anything but lucky there. So, uh, that's kind of
well, for for what it's worth, I I see the vision and I think from a developer perspective, at the very least at first glance, Spacetime DB feels very appealing because it it feels like the correct abstraction that you would want as a developer. like you have a a very nice website that shows basically this um very simple example of like a very simple reducer and you can and as a developer you you instantly get your mind spinning on all the the cool things you can can do with this like
that's exactly what we wanted to to portray and I think we're going to make that uh even better you know I would love for you to be able to edit that code and see it live updating in the

website so you have an application right there and you can modify your code and see like wow it actually changed the behavior of that application. I didn't have to do anything.
Uh, and I think we can get there as well. So, we got some things cooking.
Nice. Nice. Yeah. Which brings me back to my my awesome list of uh things I'm already imagining uh building. I'm I'm not sure if if there's like too much to say about it, but I'm I'm just going through it. Also, user generated content. How how do you think about um maybe using space DB to host user generated content? For example, I tried Steam Solution for one of my games in the past. Like Steam solution is of course a workshop, but it comes with a couple of annoying limitations that are a little annoying to work around and some games just require something custom. For example, maybe I want to do something like Geometry Dash or Mario Maker where people can vote on levels in games or maybe you get an automated queue or the server automatically like picks the level of the day that got like

the most traffic or something. Have Have you thought about those applications?
We have. um we've actually kind of thought I suppose one step past that I I would say into what I call user generated logic. So um let me take a step back. We'll do you will do UGC first.
So obviously since your client is just listening to tables and all of that stuff you can in principle allow players to write models and things directly into your tables do some validation on them uh and then actually string them down to your client and have them show up in your game. So like things like 3D models and that kind of thing. You can of course in spacetime DB also build whatever logic you want about the complex permissions you're describing where it's like oh if you're at the top of the leaderboard you get to be the person who determines the theme of the next game or whatever that is.
We actually want to take it sort of one step further uh which is you could make it so um the person who wins your game is actually able to modify the code for example. So you could have logic in your

application which says this person can publish the person who wins the game can actually publish the next module. So you could even have them
modify the code that you actually have there or you could do things like they have their own module that they've published which they've registered with yours and then you can delegate out to them to ask certain questions. So the example I would give for this is let's say in Bitcraft we have the concept of an empire or let's call it an alliance for people who are familiar with other other games. So you have an alliance and um or a guild. Same idea. What you could do is uh have um that guild give them the ability to upload their own module with an is allowed function on it. So what what would happen is the user playing your game would apply to join uh somebody's guild. Your module being the game developer calls out to their module to say like, "Hey, should should I allow this person into your guild?" that third party module runs through whatever checklist they have. They're above this level. They've never killed that uh guy.

They are friends with these people. Literally, this turning complete. Sky is the limit. And then if they say yes, they write back into your module and then you uh allow them to join the the uh alliance or guild or what have you um in their in the game. So this is a way for you to actually have part of your application be written by third parties which we think can be very exciting.
Okay. So if you put the correct checks and balances then you can basically allow your game not just to connect to clients but basically to other servers that users run. Yeah. Okay.
Exactly. Right. And so that is a pretty cool thing you could do. And you can imagine I mean there's a lot of different ways you could do this. You could have like a bot battle type thing where you allow other people to register their bots and then you have some kind of a core game and they're all trying to play against each other and that could be pretty fun as well. It's more of a programming game.
That that does sound very fun.
Yeah. Yeah. I love all of the I love all of your ideas. Like you have a lot of cool ideas for where where this could

go, but you've only like how how much time have you spent working on this so far?
It's a good question. Um, it's hard to quantify because obviously we have been working on it uh in some part since we started building the game. At the time we didn't, I think know exactly what it was going to be. Um, although I I looked back one time because we were looking for for trademark purposes
and we mentioned Spacetime DV like way back like the name SpaceTime TV way way back further than I thought. So, I'm not sure what I what I remember exactly about when we did it, but um in 2018, we started building the game. I think in August, maybe 2019. Uh and I would say sometime around 2021, end of 2020, we decided like, all right, we're going to make this thing a proper database, this internal engine that we have, which we've been calling, I think we called it actually jank timed db because it was space, but it was janky.
Yeah.
Uh we're going to make this into a proper database and a proper product. Uh, so I guess from sometime in 2020, probably mid 2021 until now, we've been

working on making sure it's like very well productized and like super clean, nice abstractions. So not just a game engine back end, but a proper relational database.
Mhm.
Um, and uh, so that that I suppose is four yearsish now, something like that.
So have do you have part of your team that just works on spaceime and part of the team that works on the game or is it like mixed? Yeah, the company is is almost operates like two separate companies. So, it's BitCraft on one side, uh, who is a client of Spacetime DV on the other side. It's maybe not quite so clean in some cases because we collaborate very closely.
Um, the game's going to go live. We need to make sure we've got the resources and we've done the testing and all of that stuff. Bigcraft is really helpful for us to dog food spaceime DB. Y there's a lot of ideas in it that we've tested out in in um Bigcraft. Speakcraft has forced us to be very uh to optimize. Like I mean originally when we built space to be you could get like one user into the game

and it would take like a minute. Um but that was for silly unoptimized reasons. You can very much optimize. We're now around like 1,500 that you can get into one data one region um in the game. Uh so very stark differences between um where we started and where we are now in terms of authorization. And I think that's something you only do practically speaking if you actually need the performance right now. And so um that's something that's been very helpful there. And then also you mentioned like things like analytics that sort of a throwback to uh before um we you so one thing that spaceb does and this was at the end of the keynote I I threw this one on there as the one more thing. We actually store the full history of everything that has ever happened in the database and you can go back in time. that is also not uh like intermodzle communication not available externally because we want to make sure we get it right for people but um what we have done is like when we had that gold dupe bug that I talked about what

we were actually able to do is go back find everybody who duped the bug ex we're w guessing like we knew exactly who did what
um by looking at the transactions as they happened and then finding everybody that they traded with and we traced the money where it went and if you were sufficiently far away from the the dupers then we just said like here's a a finger wag like don't do that be careful about this and if you were the dupers or you were complicit with the dupers you got a perma ban
okay
so there is no escaping
uh space time db's um historical
and you I'm assuming you don't keep all of those records in memory as well you probably
no we don't so those get written to disk they get a written uh in the write ahead log it's the also the same thing that we use to persist all everything to disk where we periodically snapshot the database to make sure that we can restart quickly because you don't have to replay the entire log to get back to where you were for those of you who don't know I suppose a write ahead log

is uh a typical data structure in databases on disk it's append only you just add transactions and you use it so that um if your machine crashes you know exactly where you were in terms of processing
so you can come back up on the same state
so you say Bitcraft supports up to 1,500 100 players in one region, something like that.
Correct. Yep. About that.
Does that depend on what kind of game it is or is the sort of the like let's for example say just make a leaderboard. Would it would like would that behave behave differently or what's your take on that?
Yeah, that's a fantastic question. Yes, it's incredibly dependent on the game. So, if you have a chess game, I imagine like you could probably have typically I think you would probably create different databases for different matches in chess,
but it's up to you. if you put them all in one database, um, you know, you could probably have I think we would fall over on a different thing. So like maybe too many connections, but like because people are only doing actions every so often,
hundreds of thousands um, millions

maybe, I don't really know to be honest. We haven't tested it. I think we would we would run into some other resource constraint other than the one we'd run into with Bitcraft.
So yes, it's very dependent. A leaderboard, same thing. With a leaderboard, you can have very few writers and many many readers. And it's a small amount of data. Like in BitCraft, there's hundreds of tables that you subscribe to. Uh so it's because there's trees and there's timers and there's inventory state and trades and movement and boating and wind and all this stuff uh that uh exists in the game. U bunch of UI elements to um health and stamina and all of this. This is quite a lot.
Yeah.
But in a leaderboard, it's just one table. Uh see
I would be shocked and there's no joints. Joining is also
um a thing that requires careful optimization and we have done some of it. Uh so I think with leaderboard you get up to a couple hundred thousand as well would be my guess.
All right. And that's of course not in entries but in concurrent users

connected at the same time.
Concurrent connected users. Yeah. That are subscribed.
Yeah. Interesting. I mean, I'm I'm curious about the the bottlenecks, and I'm sure you'll you'll find more of them as time goes on. And
yeah, I think that's the other benefit of a generalized solution is that it's very complicated to get it all right. So, if you build your game and you put in millions and millions of dollars because you want to make an MMO,
you've really just optimized it for just your specific thing and if you want to then reuse all of that work and energy and time and money that you put into it, it doesn't really
translate.
Whereas, because Space 9b gives us the responsibility to do all of the query evaluation and the subscription, we can we can optimize it. And the more we optimize it, the more everybody else benefits. the more we we work on it, the more games we do, the more different applications we do, the better it gets. One interesting example, talking about abstractions going way too far.
Um, somebody built video calling over FaceTime DB. So, audio and video being

passed through the database in real time. I'm not going to lie to you, it wasn't amazing, but it does work. Uh, and I could actually send you a link to that
of somebody doing a video call over space. Um, I think we could make that kind of thing actually work properly. I can see I would never have thought of it, but now that they've done it, I can actually see the path to how we would do that. You know, you probably couldn't use websockets. You'd probably want to use um UDP and you'd want to do some fancy things. But that's all it all fits with the abstraction. None of it's counter to the abstraction. Um, we we want to thing called event tables. We actually want to do that anyway. But if we had all of that stuff, I think we could actually do video call over space.
I see. So, so you have a very very long road map for Space 7 DB already.
Very long, right? An infinite road map.
Yeah. Cool. And do you like do you do you think you'll have a long enough breath to to make all of that cool stuff happen?
Yeah, it's a good question. So, I think that depends on whether or not we can uh

make Spacetime DB the easiest way to build applications. If it is a no-brainer to pull space to be off the shelf and just slap it into your application, then we're going to have some substantial adoption. Um, I think it is a very powerful abstraction. I don't know that certainly I wouldn't build any other game that was multiplayer personally than using Space DB. I, you know, we'd like to make it so you wouldn't build any app. So, an iOS app, an Android app. Uh, I I have sort of a theoretical app that I talk about called Ice Screen. Mhm.
Uh which is imagine that you had an app, very simple. You open it up, there's a button, it says ice cream and you can scream for ice cream and then ice cream trucks in your area will hear about it and they are able to bring ice cream to you. It's, you know, it's kind of like Uber but for ice cream. Very simple to build on the client. You just have a button and it lets people know and then maybe for the ice cream trucks they have a map and they have a heat map on the back end. If you want to do that today, it's going to take you a while because

you got to do you got to hook into map APIs and have all the the synchronization of like positions in real time and have permissioning so people can't quite see where people are and you have to spin up server. It's it's gets complicated and you got to do websockets. The goal is for that take another the other hour. So you do the one hour on the front end, one hour on the back end, you're done. You've got ice cream going up.
Yeah. Yeah. And so I think it comes down to we're going to get adoption if we can make it easy and it's not quite there yet. I think there's some very cool things and we are that is our number one goal. So it's eliminating all of the sidecar services you need and making it so like it is one click like you basically can't end up on our website and not make an application. That's the goal.
Okay. Okay. I see. And um yeah, that's honestly that's also part of the part of the list of things that excite me, like the opportunity to not only write games with this, but to also write um some of my own applications with this. For example, I often times have like frustrations with with my calendar app

or something like that. I'm just like, I don't know, maybe maybe I'll just be able to to code something like this up. maybe VIP code it you know if if LM understand uh your framework which they probably do and
so this is very this is an interesting question so I guess two points on that one is I often see in applications weird state mismatches because this maybe the client's not quite in sync with the server because they're doing some poll based or pull based thing and you got to refresh the page spaceb eliminates all that because it's just getting streamed down to your client right so you just don't have to think about it uh and I think that's that's an important aspect of not only does it make it easier but it makes it better uh and so that's That's a really cool thing. And then you mentioned sort of vibe coding and AI and LLM.
So one of the hardest parts for LLM to do is infrastructure because it's not text. They make text and it's not text.
Yes,
the input to Space DB is just text, right? It's just your module. It's very straightforward.
Your a the AI can see your schema. They know exactly how it works. They know the API is very standard, right? It's not as

if, oh, I have to do your personal API. It's just a regular API and it can just use the exact sort of same template. And then on top of that, all it has to think about is one reducer at a time. We had no idea that this was going to be good for LM, but we knew it would be good for people, right? If you just have to reason about one piece of code per at at a time,
it's going to make it much easier. It turns out that's very powerful for LLMs as well.
And on top of that, because it's um a transactional context, if the LLM throws an error or something, it's going to back out. um and it can reason about that much much more clearly. Again, we built that for humans, but it turns out it helps for LLMs, too. So, the interesting thing is, you know, L the code that LLMs can write is becoming more and more ubiquitous. The code that LLM's can't write, uh is becoming more and more valuable.
Yeah.
Uh and so, um I think that that's that's an important aspect of
Yeah, I I 100% see that. Yeah. Cuz as you said, the the infrastructure is

always the difficult thing. If I'm like I want to host my own password manager, I'm like, "Oh, okay. What do I use for the back end?" Just having a a simple solution where I'm like, "Okay, I just need one table with with the passwords. I need I write my maybe I have my own way of encrypting them so I can be very sure they they're secure on your server." That's something exactly right.
Sounds very very appealing. For sure.
And yeah, as you mentioned,
I think I'm incredibly excited. We have the resources to do it. Uh we have the time to do it. We got to be fast. You know, we want to make sure that people can do this.
Um, as you can I mean, you can obviously use Space NDB today. We want to shave off
a couple of the rough edges and I think that's going to unlock
uh things. You know, maybe we'll do I'm going to try and write an application, you know, once a week and see how much easier it's getting. That's the point.
I see. I see. Well, obviously there are some companies trying similar things, right? there there are other databases but it's like would you say I guess the question is how is spacetime different

from the competitors that are currently out there because I I know there are some uh databases that also allow you to run serverside code basically
uh I mean superbase has like they've got so firebase you know they're spiritually similar to spacetime DB in that the idea is like hey you know why are we doing all of this infrastructure like why don't you just take your thing and upload it I think Like Versel is even spiritually similar, right? It's like I I actually I was doing a demo for Space Envy and I I needed to deploy a version of my app and it literally took me one minute from like signing up to deploying the app.
I was like A+ Versel, great job. Like this is what I want.
Um we just don't have the same thing for state. So Superbase does have that. You can have like cloud functions in Firebase. You can have like cloud functions, but they're it's not um they're kind of one they're sort of like store procedures. They have similar problems. They're you do them one at a time, you upload them, they like edit them in the UI. They're not in Git. Exactly. Um they have a bunch of

latency, so you're con constrained in the types of applications you can make. Would love to see them do more uh in that space. I think we I'm just trying to get us out of this
hole that we're in. But I but there's nothing that's quite like spacetime DB where you're unconstrained in terms of what you can build all the way up to an MMO.
So it's not like oh hey I have a Firebase project but as soon as I get over
500 users now I have to rebuild it in something else.
Yeah.
Or whatever the that's maybe a little low for Firebase but you see what I mean. You know you can go all the way up to an MMO. You can do real time. So you can do games. You can do drawing applications. We've had people do that kind of thing. uh and you can do just sort of regular apps that have updating data and I I think that that is the power. It is a one-stop shop uh for what you want to go with.
Got it. So I I guess from what I can see what makes it unique is that it sits on top of the data and therefore allows you to do very fast uh real time or are

there any competitors that do that kind of stuff?
Not that I'm aware of. Not that are as general. Um like obviously you mentioned photon they have like photon quantum and they have uh photon
they have fusion. Um but obviously I think they are very very different but because they they're like purely focused on real time. They don't have uh from what I can see they don't have any persistent databases.
Yeah.
And that's the problem that we ran into actually is why we built space in the first place. I'll I'll just go over that briefly kind of like what where was my head when I was when we were thinking about building this cuz
we didn't want to we wanted to build our game.
Um and we looked at there's like all the web solutions they couldn't work right. They're just way too slow. They're they're not related to games uh enough in terms of like the performance requirements. It's really performance requirements and also some of the design of how the server works. And then there were all the game solutions. And the game solutions were like there was what is it called? uh improbable was making a thing called

spatial OS um if you remember that. Um, and there were there's things like photon uh I think photon quantum was a thing at the time.
And the problem with all the game solutions they didn't deal with persistence and um storing the data, right? So uh spatial OS which had they got they I think it probably got like $600 million in funding. We were going to build our MMO on them. It was going to be expensive and then their abstract they didn't really solve the problem that we had to solve. Like our game requires a lot of persistence, building buildings and changing the terrain and keeping the trees that you cut down cut down and all of that stuff. And we would have had to have done all of that anyway. So we would had to have coordinated with the database.
So that wasn't really a great solution. And then you look on the other side, well the web apps have the persistence, but they don't have any of the stuff that the games app has. So I was thinking like is there a way that I could unify this
so that we could have something with persistence like like a web app like Facebook, right? Facebook if if you squint very hard is an MMO.

Yeah.
Um so I wanted that aspect of it, but I wanted to be able to do the real-time part of it and there was nothing that could do that. So we put them together.
I one thing that we didn't mention yet which maybe just should just briefly mention is that you can also schedule reducers, right? They don't have to be called by a user. So you can do things like um you can basically have a server tick rate by just scheduling a reducer to run every 60 times per second, 30 times per second. I assume for an MMO you probably can get away with with a lot less, right?
So wi with an MMO you can get away with a lot less. And actually in our case I don't know that I would redo it. There are trade-offs. It kind of depends. But in Bigcraft there is no tick rate. actually every time you move we do a transaction in the database uh and we move your player.
Okay.
Um interestingly uh so you actually that was another thing I was like you know all these game solutions they have t like I I'm just immediately I'm required to have a tick.
Yeah.
And in web like I can't have a tick or

it's weird and and I wanted to make it so I could have a system where I could choose to have a tick or I could choose not to have a tick or I could have multiple different different ticks.
So I could have like an AI tick and I could have a whatever tick and we could do this differently. So yeah, uh with scheduled reducers in Space 9B, they're just normal tables. So basically what you have a scheduled table and that scheduled table has rows in it and they call reducers when they when the time elapses. The really cool thing about that is you can SQL query all your timers. So you can say like, hey, I'm I want to debug what's happening with myuler. SQL select from my timer table. Bam. I've got all my timers. I can see exactly when they're going to expire. Uh and I can delete them and I can insert them. That was a real eye openener when we did that one. Like, okay, now now we're cooking. This is really good stuff.
Yep. So, the timers as well are just a table. Everything is tables.
Everything is a table. If Unix is everything is a file in Space MDB, everything is a table.
So, next on my list of exciting things

that I might want to build. Uh, I al already briefly mentioned this, but maybe we can go a bit more into depth is is like a matchmaking. Let's for example say um I really like photon quantum solution for real-time multiplayer but they don't have the type of matchmaking that I want. Could do you think I could for example combine different systems or for example use spacetime for matchmaking and account management stuff and sort of pair it with with other networking solutions.
So you certainly could um and that's what um games actually have done. Uh I was supposed to have a meeting with somebody yesterday who are using space to be as a matchmaker for their game. Um, the game has overwhelmingly positive reviews on um, Steam. I don't know. I haven't talked to them yet, so I don't know if I want to shout them out or if they want me to or not. They probably do. Uh, but um, I don't know.
You can shout them out now and tell me in hindsight. I'll just edit it out.
Okay, that's actually a great point. So, uh, let me see. The game is Underdogs VR.
Mhm.
And it's by one Hamza. And they, uh, are

have that game on Steam. It's $30. Check it out. overwhelmingly positive reviews with almost 2,000 reviews, 97% positive all time. Uh, and they have decided to use Spacetime DB specifically for uh, the matchmaking aspect of their game. So, they do whatever they want on the side and they do matchmaking there. You certainly could use it with Photon uh, Quantum and Photon Fusion. There's probably cases where that makes a lot of sense. Matchmaking games, especially where you have full knowledge of the game state with Photon Quantum is what you need. So,
you could do something like that. The cool thing about spacetimed is that it fails safe is what I would call it to Postgress and actually we're about to also release Postgress wire format. So you will literally be able to connect to it as though it were a Postgress instance with like Psql and do Postgress type stuff. So um it has way more capabilities than that. It also doesn't have all the capabilities of Postgress. I want to be clear about that yet. So there's kind of a long tale of random

Postgress things to do but it will sort of superficially seem uh very much like Postgress and then also we have the ability to subscribe to the data and we have the ability to run your application inside of the database. Uh so you can just you can use it if if you don't want to drink the Kool-Aid you can have just a little sip
I guess is what I would say and that's one of the cool things too about the abstraction. Yeah, because there are not not really any solutions that offer very customizable matchmaking. Like the the best you can get from out out of the shelf is maybe you attach some meta data to your lobbies and then you s search for specific lobbies, but that's kind of the the best out of the box matchmaking you you'll get. Maybe you do like a if you want to do a leak system or something cool like that, then there's not really anything like that. One of the cool things I think also about Space 7DB um is that because the code comes in such a standard format of like hey I have these tables and I do this certainly somebody can create a library

and then share it around in a way that you can't normally like oh if I have a matchmaking system well it's like specific to my AWS deployment and like I can't spin up the matchmaking system without also like the Kubernetes deploy and all of that stuff. With SpaceMDB, we could do the matchmaker code and just have bam, that's a library that you just import and now you just use the matchmaker. Um, we haven't done that yet. I think uh the community has done some really cool things. We're going to be putting something on our website that's going to encourage people to sort of share those things a little bit more
um so that we can get some like standardized, hey, if you want a matchmaker, just pull it off the shelf and then customize it, right? Just change it however you want. Add tables, remove tables, whoever you want.
That was cool. Even like before before I found Spacetime, I didn't even really have an idea of how to write something like a matchmaker and now now it's like the first time that I can imagine a way to do it, right? So that alone is already kind of cool.
That's very gratifying to hear.
And also obviously we've already

mentioned asynchronous multiplayer is probably also a very good use case for for space time. If you have like turn-based things like chess or maybe you have something like the the supercell kind of games like Clash of Clans where you build up a base and then you can raid other bases and stuff like that.
Yeah, absolutely. Uh those are great because you need the persistence.
In some sense it was inspired by that. So I used to work at a company called Machine Zone which is was a direct competitor to Supercell. Supercell is one of our earliest investors actually. Actually they are I think the earliest investor who put in the first money. Um, and the way that that happened is I worked for machine zone. Um, and machine zone was sort of very monolithic and and top down. Uh, but Supercell is called Supercell because it's a collection of these little cells. I thought that was so interesting. So, I reached out to the CEO and I said like, "Hey, this is really interesting. I used to work at Machine Zone. Curious to know questions." And at the end of the call that he uh set up, I said like, "By the

way, we're making a game. Um, this is what it is." And he passed me off to their investment department. And that's kind of how the whole thing got rolling. Um, so space is largely inspired by my time at machine zone and and in particular some of the data analytic stuff. So I was on the data science and d platform team. They were always trying to reconstruct this historical data.
Yeah.
Because they wanted to be able to predict like, you know, what is this user going to do and so on.
And it's very hard to append it on after the fact. So with spacetime DB, I wanted to make sure I always had it from the beginning and that it was a minimal amount of data and that we could do sort of arbitrary uh analysis on it.
Right. That's for that's why you store the entire track record of of
That's exactly right. That's that's where that came from.
But their their game I say all that to say that their game was much like Supercell's games.
Uh asynchronous. Yeah. They were asynchronous citybuilding games.
I think there's still a ton of untapped potential in asynchronous multiplayer. I think the reason why there aren't a lot of games like this is because they're difficult to make. So,

it's hard.
Indies don't really make them.
Yeah. And the the back end of uh a game like I don't know Supercell to be frank, but Machine Zone the back end was more like a web server
than it was a game server.
It was sort of like a web server with some stuff added on and kind of hacked on to make it a little bit real time in certain cases.
Yeah.
Um and it took a lot of people to build. I think that took 80 people to build that game.
Yeah.
The the original Game of War game.
Yeah. Obviously, um you know, some some requirements might might shift as like if you have a game at super cell scale with like millions and millions of players, then obviously may maybe your back end has some very has some extra requirements probably that make it uh everything maybe a bit more difficult.
You would. Yeah, that's true. But I think you would also be surprised at how much
computers can do and how strung together with duct tape and wire

some of these larger things are.
Um,
machine zone used PHP. It was very slow. I remember we did the math one time and I think they had like two users per core CCU or something like that.
Um, that was particularly inefficient because of I think they owned the data center and they had to rent a bunch of machines. Uh but I think with Space MDB it would be much much more efficient and you could do a much larger set of users on a smaller number of machines.
Sure. Obviously efficiency is also not just about how efficiently does it run. It's also about how efficiently can you build it which is arguably in some cases even more important.
It is they're both important. I think it's you can't sort of just just take one without the other.
I believe that with Space MDB we we make it both more efficient to run and both more effic and efficient to build as well. That's the goal. I I think if you just focus on one of those, you get into not great places.
Let's quickly talk about your free tier. So, one thing that I also found interesting is that you pretty much

allow self-hosting out of the box, right? So, if I if I'm not interested in paying you a single scent, I can just self-host immediately and go from there basically. Or how does that business model work exactly? What's the idea and the reasoning behind this?
Yeah. So, um it's a good question. Uh first thing I'll say is very soon we're going to be transitioning to also make u main cloud have a free tier. So you'll be able to deploy to main cloud just no problem. And for most developers they'll never have to pay anything. So we're going a little bit more free than we than we currently have on the website. With respect to self-hosting the idea is um there are a couple scenarios where we don't really want to restrict people from just building things. So one is if you're making a small thing uh you know like a sort of a non-commercial thing um or even a commercial thing but it's somewhat small we want people to be able to host their own version of space time DB partially because with interm module communication we want to be able to connect all these clusters together and

have sort of an internet or ecosystem of a bunch of different spaceime DB we don't want to be the only one in town which is why we called our cloud main cloud as opposed to just cloud
um because we want ours to be the main one and then other people can connect to it and add their own stuff by running their own hardware um on the site. We also want it to just be easy to run in development on your own machine locally. So very it's very easy to run especially if you have the source. You can build it from source, you can make modifications um you can contribute back if you want to uh and you can run it locally uh in development. So we want you to be able to deploy small things in production, run it in development. We also don't want you to restrict shipping it to clients to like users if they run one, right? So, um, you can imagine like if if we were to do the client side prediction thing, uh, where we're actually executing space on your client, we want people to be able to do that.
We also want people to be able to do peer-to-peer stuff, right? Like if you're not operating the servers, we're we don't want to have to charge you a license or that you have to be concerned that we're going to come after you

because you're running it, whatever. We just want that to be something that you can do. Uh, so the business model really comes down to if you don't want to do infrastructure, use main cloud. uh it'll be great. It'll scale. So if you're if you're a a serious business and you don't want to deal with infrastructure, maincloud is your bet and uh that is our business model. If you are a developer who's just messing around or somebody who's building something small or someone who doesn't mind putting in a bunch of leg work to do infrastructure, then you can do stand one and that's how that works. So the the tech is kind of free probably with some limitations on what you're allowed to do but uh the the business model is basically just the infrastructure. So tech is kind of
to clarify the license is basically so here's what the license says. The license says if you run one node you can do whatever you want with it.
Modify it, run it, do whatever you want with it, no problem. If you're going to make a clusterized version of uh Spacetime DB, then you need to wait four

years before it becomes open source, like fully open source. So, it's it's source available.
And there's a four-year like lockup um before the actual thing becomes uh you can do whatever you want. So, you can run a clusterized version, you can do you can resell it as a service, you can
it's an anti-AWS clause is really what it is. And so AWS can't take spaceime, run it in AWS, and then charge users for it. Yes. Um but we build it.
Okay, that makes sense.
Mhm.
That's the that's the idea. And then we have internally a private version uh which is clusterized already. So it requires no modification. It's already clusterized. And if we if you have a a large client, if we have a large client, we can either run an on-prem installation for them. But in the vast majority of cases, we can give you like dedicated nodes on main cloud or just a shared node on main cloud and you can go to town on there.
Got it. So, and the the fouryear delay basically applies to all of the updates you do as well. So, there's like always a four delay four years delay on everything you add basically or how does
there is. Yeah. So, if you if you want

to if you want to resell it as a service or run a clusterized version, you need to wait four years per version.
Mhm. Okay. Got it.
If that makes sense.
I think um that sounds fantastic. like that that is kind of as open as you can get without um harming your own business model, right? I I think that's very good.
That's that's essentially what we thought as well. We wanted to go right up into the line where um and you know, I think there's a world in which depending on how things go, we just say like, hey, single node is fully open source.
Uh we have the clusterized version. That's the deal. Um I think we're waiting to see what the adoption looks like. Are we concerned that AWS is just going to run like AWS Spaceime DV and then we'll be sad? Yeah.
Yeah. Yeah, I see that.
Um yeah, but it it really helps to take some of those typical developer fears which are like um what what if they suddenly shut down their servers and so on like and also like conserving games

for the future, making sure they're still playable.
Uh 20 years.
I think it's a very real and important concern for any game developers. you want to know you're going to have this thing around. I mean, spatial OS, right? A lot of people went all in on spatial OS and then they stopped supporting it. Um, and people had to figure out what to do.
Uh, and no matter how much guidance and help you provide, that is not great for your business, uh, in games, which are already pretty
pretty intent as it is.
Um, do you want to maybe take another, I don't know, 20 minutes to talk about BitCraft a bit more because I think that's also quite interesting.
Sure, happy to.
Awesome. So spa entirety of spacetime was basically created as a as a tool to create the game.
That's correct.
So the game was first.
The game was absolutely first. Yep. I don't think we would have had the idea for Spaceime TV without the game.
And then somewhere halfway through you realized, oh, this would make for a good standalone product.
Yes. Again, I don't really remember when

that was because I I I thought it was later, but then I looked back and it was we had it in like our earliest materials. So, it might have been I don't remember exactly what my mind was, but at some point we saw hey this is a database
and then further we saw like this is a database that we should release externally because it's it's in some sense the you know certainly if you're a developer it's the more exciting product. If you're a gamer obviously the game is more exciting but
yeah. All right. So what was the idea for for Bitcraft? Like certainly it already started out with quite some ambitious plans already, right?
Yeah, it did. Um the idea was in essence it went through transformations. You know, at the beginning it was a little bit more of like a mobile game look. In fact, you can actually probably look and find some of the old mobile game looking uh UI and things. Um, and it was meant to be a little bit more asynchronous, but the more we built it, the more we thought like we should turn this into a proper MMO.
Uh, and the main inspirations for

Bitcraft were Minecraft, obviously. So, you can,
it was a survival game. You can modify the world. You can build roads and things.
But then we wanted the long-term progression and free trade economies of old school Runescape and Eve Online. Mhm.
So, um, old school Runescape is an inspiration from for like the control scheme, uh, and, um, the skilling and all of that stuff. And then Eve Online for some of the trade obviously also pick old school for some of the trade, but also like the empire system in Eve Online, the sort of the very big scale social system where people are buying for power was a cool sort of layer to add on top. But the idea generally with Bitcraft is that everyone is working together to rebuild civilization from the ground up and that that takes a long time and that's very meaningful. If you see somebody walking around took them several months to get something that should be impressive. So that's where the game came from.
So I think you can still see some of the idle game nature in the game, right? I

checked out some some reviews and trailers and stuff and there's still some tasks in the game that like take a really long time. for example, like you saw some wood or you plant some seeds and there's like a it's not something you'll actively sit through all of the time. Maybe you'll grab a snack or have it run on a second screen,
something like that.
That's right. Um and that was so that's as designed. Um I think the thing is when you're a small company of small amount of resources,
you need um we needed the progression, we need the content, we need people to be there. It's an MMO, so you need people to be there for for a long time.
But also, the waiting and the dedication to creating a thing is what makes it valuable.
If you I think a lot of um teams over time forget that because people want the things and so they'll they'll shout loudly like I want the things. But if you make it too easy to get the things, they're no longer meaningful. Mhm.
But with a small team, what you first need to build is you build a skeleton and then you add flesh to it over time.

And we've added some, but there's a lot more. So, we want it to be that, hey, I can do a thing idly or if I want to play the game actively, I can go play the game actively. And I think that's something that Runescape has gotten really, really correct.
They have the long-term progression. They have the more idle gameplay. They also have, I can go, I can go fight a boss. I can go do a quest that's fun. I can go talk to people in town. I can do kind of whatever I want. And I think it's that mixture that is the the important component. And we absolutely have plans to continue to make that mixture more uh exciting and to grow. The I I would give the example of like it's I don't know if you've ever seen, but they have these things like forever stews uh where you make a stew and every day you add new ingredients and it changes the flavor of the stew and it gets better and better. It's kind of like that with MMOs. They they start out pretty bland, a little bland. Um, but you know, over the course of 10, 20 years, they become a rich complex flavor of different things. And I think that's that's where we want.
So, you've set out to create two very

very long-term projects. Like both Bitcraft as well as SpaceTime are like
That's right. We're we're here and we like here to stay.
Yeah. Cool. Uh I I checked out some of the Bitcraft reviews of course and one thing that struck me as kind of interesting was that a lot of the negative reviews are from people who've spent a lot of time in it, right? Like if you check out the negative reviews, it's almost always like 100 hours plus.
Yes. I mean, we got a couple like 900 plus hours. Um
and those kind of hurt my soul a little bit. uh uh because like
you know you spent 900 hours here but here's the thing they leave good feedback. It's useful feedback.
It's more useful feedback in some sense than somebody who comes in and just says like ah it's not for me. Uh because we know this is for them.
Uh and we can then work on it and improve it. And I think the thing is if you spend 900 hours in it there's something in it that you like and

usually you leave because there was something that happened that you didn't like. And I think that means it's fixable uh in those cases and we can bring people in again.
Y
you taste the stew every day. You see how it's going
and you you add the missing ingredients.
Yeah, it's it's interesting. Um I also talked to Ben like at the someone from Tipsoft. They also make MMOs. They made Tibia. Uh I talked to him a lot, not just on the podcast but also on on random events where I keep meeting him. And one one of the things he told me was that they're trying to get people through the progression system almost like kind of as quickly as possible because the people want to get to the end game. So they want to get people to the end game as as quickly as possible.
Classic.
I think that's also an approach you can go for, right? to if people say it's too grindy, you maybe try to find a way to tone down the the the grindiness a bit and find a satisfying end game that people can play, which is like trade wars or waging wars against each other where they burn resources and have

motivation to craft new things and so on.
This is intentionally something that we're not going to do and we're not going to do it because there are plenty of games that do do it. play World of Warcraft.
They'll wipe your progress every year when they do the new expansion. Basically, they'll make everything you did not meaningful and you go do the new thing.
Um, and you can pay, I think, $60 to skip through all of the first however many levels and get to the end game.
That is fine. I mean, you can make a game like that. It's the most successful MMO probably of all time. Um, but it's not the type of game that we want to make. So, we want to we want to make Runescape not WoW. Um,
and I think the thing is if you do that, right, it is true that you can get people through the content faster to get to the end game, but then I would ask I guess why do you have the beginning game if people are just trying to get through it? You might as well just make just the end game. And I think you'd have a better game. Personally,
that's a fair question. Yeah.
Um, and I think in in our case, what is

interesting about Runescape, right, is that people who are just and a lot of people are now just discovering old school Runescape. It's had a huge resurgence. I think it had the highest CCU it's ever had a couple of days ago if I'm not mistaken. The cool thing is that all of the old content that they built 20 years ago is still relevant and they modernize it and they improve it. But it's not as if you know I'm skipping past Enixia because like there's literally like why would I even bother uh in World of Warcraft to do all the old bosses when it's all about the new stuff. Um, and so what I think is important is that when somebody sees a piece of armor that you're wearing and they know it's high level, as soon as you make it easier for somebody to get, it just cheapens it. It just cheapens it massively.
Uh, and so I like I I don't think it's a I don't think you can't build the game that way. I think that's exactly what World Warcraft did. And again, I think it's most successful and I think it's just not where we want to go. I think we'd rather go the Runescape route.
Mhm. And because also your entire world is modifiable and you can build in the world, you you don't want that to be

cheap. You want it to be meaningful. Like every stone that was placed was like you can know that
effort was put into this. Like if if you see a know that cost something.
Exactly. You kind of need to even as a balance question for for a modifiable world. Otherwise, I don't know if you've heard of like the Minecraft server 2B2T.
Uh it's an anarchy server. You can do whatever you want, but if you spawn in, the spawn areas are dystopian hellscapes because people have just modified it and we want the world to feel like a real world Olympic craft. So, it does need to be timeconuming to build a road
otherwise there's going to be just you know
as far as I can see.
That makes sense. Yeah. What what have been the main challenges you've run into developing this game and how are you tackling them?
Uh there's a lot. Um, it's hard to go over them in a short amount of time. I would say
one of the hardest things about Bitcraft is
you can't just balance it at a point in time

because the game world changes over time. So, you have to balance it across like the life cycle of all the players that are going to play it. So, when you first start, nobody's built anything. But by now, there are cities that are sort of very high tier eight, nine, tier nine.
And so, the game today is different than when it was created with World of Warcraft. Not so right like the game is the game and it stays the same and people go up in level but fundamentally the world is not changing and that is that is very tricky to do. I think also getting the population density correct is very tricky to do. So you need to get
enough players close together that they can trade but not so many that they're stepping all over each other and they can't build and and create what they want. Uh, and that is a function not only of like deciding what's the scale of the buildings and the players and all of that, but also how quickly they can travel. If I give you the ability to teleport all around, I immediately shrink the world down functionally, but you still want people to be able to trade and have different prices in

different areas so you can do arbitrage, like you can bring the the logs from place A to place B. That is very tricky to do. We're we're just kind of getting into the places that other MMOs sort of start from. So like improving our combat, I think that's uh something that we have not shouldn't say we haven't invested a lot of time. We have, but um it's not been the main focus of what we're trying to build. Um, so I think doing it now, like adding to the richness of the stew requires a slightly different set of uh skills than um maybe at the beginning when you're
adding the meat and the potatoes.
And then obviously you have the the typical challenge of the the game's already running and you need to find a way to update the game without alienating the players that like it the way it's now.
That's right.
It's like always
it's very hard and that's how you get, you know, 900 hours and a bad review. Um, so it's challenging. I mean, we've had things where we push out things on a preview branch and people were like, "Oh my god, I can't believe a bug. We push out bugs on the preview branch.
People like, I can't believe they are so

dumb as to do this." And it was like, "It's a bug. We're going to fix it."
Um, that was not intentional. And then we do fix them.
But yeah, it's it's true. It's very challenging. And I think the thing is, you try it, you get it wrong, you fix it.
You try it, you get it right. Some people don't like it. You strike a balance. It's just there's not an easy answer. I think you just have to be committed.
I see. So, is Bitcraft mostly a game about resource management and trading or what what is it specifically about? Is it about a game about simulating civilization? Is it a game about simulating trade? Like what was like the the core identity of it? You say
it's a game about sim simulating civilization. I don't think you could say it's about resource management cuz why don't you play, you know, an RTS like a like a sort of a single player RT play City Skylines.
Um, it isn't about just social stuff cuz you you have to do the logistics and plan it out.

Um, it isn't about going and killing monsters and survival, although you need to do that as well.
It's really about civilization in all of those aspects. So, the fact that you do need to do resource management and you do need to negotiate um with other players and build friends and meaningful relationships. One of the coolest things I've seen in BitCraft is that people actually meet friends in the game in a way that I think you might not do in a matchmaking game because you're not spending as much time with the same people over and over again to work towards a shared goal as what you do in Bitcraft. I've had people before even the game was released, they would say to me like, "Thank you for making Bitcraft." And I was like, "Hey, let's release it first before we start thanking me." And they said like, "No, you don't understand." Like, I met my girlfriend and my best friends in the Discord servers about talking about the game.
Yeah.
And I said, "Okay, that's I didn't have that context, but that's that's very rewarding."
Yeah. So, the the main content of an MMO is uh often times the communities that

form in it, right?
Absolutely. And I'm I'm very proud and happy with our community. I think they do an amazing job. People um mention, you can see in the Steam reviews, it's a it's a very welcoming and um it's an amazing community. And you know, in some ways, I think it delivers on the promise of social networks that social networks never did.
Most people don't make new friends on Facebook. They don't make new friends on Instagram, but they do make new friends in in our game. So
games are a good environment to make new friends because you instantly have something to talk about and a way to interact and like you have a collaboration point for sure. It's in some ways Bigcraft is a chat box with a reason to be talking to people.
Obviously um one thing that I found with selling games on Steam is also that a lot of the art is um in expectation management. Just making sure that uh players know what they're getting into. for example, like if somebody downloads Bitcraft and they think it's like a combat focused MMO or something like

that, they'll probably be disappointed, right? So setting setting correct expectations is is quite important and also quite quite difficult.
It is. And and I think we could do better on that as well. We've tried. Um it's challenging,
but I also think MMOs are particularly hard because everybody has an idea for what they want in an MMO and the the category is so broad
that it encompasses uh quite a lot. And so they come in with um hopes and dreams and we do our best to fulfill them. Um but we you know we can't always and I think day by day we'll do more and more. Cool.
Awesome. Awesome. I think we'll leave it at that. I think it was a very very interesting all in all. I want to thank you again for for taking the time really fun and insightful chat and as mentioned I'm very thank you so much for having me.
You're welcome. I'm excited for what you build and I I wish you good luck. I'll just stop the recording there and then we'll
Thank you so much.