Show HN: I'm open-sourcing my game engine(github.com)
github.com
Show HN: I'm open-sourcing my game engine
https://github.com/moddio/moddio2
93 comments
The android app sign up page seems to want me to enter my Google username and password _inside the app,_ in what looks like a web form, but as a user I have no way to tell if the app is snooping on my password.
It seems like Apps usually navigate away to a sign in, and then navigate back. Is that pattern hard to implement? Is the issue about cross platform support? Thanks
It seems like Apps usually navigate away to a sign in, and then navigate back. Is that pattern hard to implement? Is the issue about cross platform support? Thanks
I should have started out by saying this looks really neat, which is why I downloaded it to try out on my phone! :) thanks for sharing! Sorry my only comment was a criticism/question.
Looking forward to trying it out on the computer instead!
Looking forward to trying it out on the computer instead!
It's not super hard in principle. I work with car manufacturers, we have to let the user login via their OEM account. In theory they say it's all compliant, but then many parts don't work and take ages for them to get fixed.
What you described should really not happen though, I thought Google forbid this already
What you described should really not happen though, I thought Google forbid this already
This is called OAuth 2.0 and is trivial to implement with something like Okta.
Or we could not encourage depending on a constantly-breached centralized “security” authority. https://hn.algolia.com/?q=okta
This feels a bit like NIH syndrome to me. Maintaining your own authentication solution is not trivial, especially for small/one-person operation.
Edit: Re-reading, I guess this is specifically targeted at Okta, who have had their share of problems.
Edit: Re-reading, I guess this is specifically targeted at Okta, who have had their share of problems.
Yeah it is known that one should use a library for authentication. It's also observed that they keep getting breached. The two sentiments "Best practice is use Okta" and "Okta keeps falling over" are inconsistent but the industry doesn't seem to have worked out what to do about this yet.
> Yeah it is known that one should use a library for authentication.
A library, yes, but a library is not a service. If you self host your auth stack with trusted primitives from a well known crypto library, you're much better off than if you outsource the very security of your platform to a company that has time and time again shown that they are incapable of preserving the security of even their own employee's personal info, much less anyone else's. At this point it would be arguably criminally negligent to rely on them to protect any sort of private information for your customers.
If you self host, someone needs to personally pick you as a target and find a flaw you made to get into your system. With Okta, they in all likelihood already have access. I know this industry loves learned helplessness (especially when the solution is “you don’t have to know the fundamentals, just pay us every month and we’ll do them for you!”), but come on.
A library, yes, but a library is not a service. If you self host your auth stack with trusted primitives from a well known crypto library, you're much better off than if you outsource the very security of your platform to a company that has time and time again shown that they are incapable of preserving the security of even their own employee's personal info, much less anyone else's. At this point it would be arguably criminally negligent to rely on them to protect any sort of private information for your customers.
If you self host, someone needs to personally pick you as a target and find a flaw you made to get into your system. With Okta, they in all likelihood already have access. I know this industry loves learned helplessness (especially when the solution is “you don’t have to know the fundamentals, just pay us every month and we’ll do them for you!”), but come on.
Is there really a better alternative? Using a centralized service is certainly more secure than every company implementing a bespoke auth system.
Also, there are super strong incentives to hack Okta, so naturally more people will try to hack Okta.
Also, there are super strong incentives to hack Okta, so naturally more people will try to hack Okta.
I always thought it would be cool to have everybody carry around a private key on some device, and that key signs all data to prove authenticity. Instead of creating user accounts on a forum, posts would be signed with a key and a hash would be appended to the username, so you know that this John Smith is the same one as the last post because he has the same hash appended. Kind of like what 4chan does with tripcodes
You'd instantly have to deal with people losing their keys, people damaging their keys, people's pets eating, digesting and defecating the keys, fire/floodwater/storms/earthquakes/other natural or man-made disasters destroying the keys, keys getting damaged by ESD or cosmic radiation, people stealing other people's keys for extortion or abuse... spread any technology over millions of people and you will experience all sorts of failure modes that you haven't even thought of.
All of these failure modes need some sort of "customer support" to work out, otherwise they'll not be used by users at all or they'll lead to shitstorms when people are locked out of their identity. And if the customer support makes errors or gets bribed, you'll get shitstormed too.
And allowing people to back-up their keys isn't an option either because that defeats the purpose of why you have an HSM anyway.
Security is hard, PKI is even harder.
All of these failure modes need some sort of "customer support" to work out, otherwise they'll not be used by users at all or they'll lead to shitstorms when people are locked out of their identity. And if the customer support makes errors or gets bribed, you'll get shitstormed too.
And allowing people to back-up their keys isn't an option either because that defeats the purpose of why you have an HSM anyway.
Security is hard, PKI is even harder.
I also personally believe identity online should be transient. Getting locked out of your identity should be as simply fixed as creating a new identity
> is certainly more secure than every company implementing a bespoke auth system.
That's certainly what they want you to think. But hooking into a system where every support engineer's full contact info (and every other employee besides) is already leaked to hackers to do all the social engineering/extortion they might want, is faaaaarrrrr more insecure than using some trusted crypto primitives to validate a password, or send an email.
If you can get away with it, just email magic links or bog standard username/password that everyone knows and every credential manager can trivially incorporate with. If you need SSO (for your big enterprise contract to go through), the story is a bit different because in all likelihood every other thing they interface with is already using Okta, but that doesn't mean you must use them too.
> Also, there are super strong incentives to hack Okta, so naturally more people will try to hack Okta.
Why would you purposefully pick such a massive target? Especially one that is currently compromised, and can't even be trusted to protect themselves? Just last month hackers got all the personal information of all Okta employees.
That's certainly what they want you to think. But hooking into a system where every support engineer's full contact info (and every other employee besides) is already leaked to hackers to do all the social engineering/extortion they might want, is faaaaarrrrr more insecure than using some trusted crypto primitives to validate a password, or send an email.
If you can get away with it, just email magic links or bog standard username/password that everyone knows and every credential manager can trivially incorporate with. If you need SSO (for your big enterprise contract to go through), the story is a bit different because in all likelihood every other thing they interface with is already using Okta, but that doesn't mean you must use them too.
> Also, there are super strong incentives to hack Okta, so naturally more people will try to hack Okta.
Why would you purposefully pick such a massive target? Especially one that is currently compromised, and can't even be trusted to protect themselves? Just last month hackers got all the personal information of all Okta employees.
There are enough solid systems (such as keycloak) that implement standard mechanisms (such as OAuth2 or OIDC) that using a service that continually has issues (as noted by the gp) should be justified, not assumed (having an SSO system should not be conflated with a specific provider).
Rolling your own is rolling the dice, but using something like Okta is guranteed (to leak).
Why would you need Okta for a simple Google sign in? A simple traditional Google OAuth flow should work just fine.
It is no short feat getting users to adopt your game engine, especially closed source. How did you manage to do that so well so far with the gallery of games you have on your site? Are those just a few friends or is there a pretty active community?
A combination of good capabilities, ease of learning, and low commitment (casual, a few days or even hours of effort to meaningful result) can go a long way. Remember Flash.
This is pretty much spot on. Having a low barrier of entry (no download/signup/paywall) + being easy to use certainly helps.
We have an active community who are creating between 150 to 300 new games every day. Having a low-barrier of entry for both game devs & players def helps. (No download/signup required)
I wasn't expecting this to be modd.io when I saw the title. It's a popular framework/platform for building IO games.
I play a lot of games and sold some in the past, but I’ve never heard the term. What is an IO game?
IO game is a catch all term for these types of mechanically simple, multiplayer, web-based games . The name comes from the fact that many of these games are hosted on .io domains. Well known examples are agar.io and slither.io.
And the biggest platform for them all, itch.io.
Itch is not exactly a platform for IO games, sure you can put them there, but it hosts a lot of other stuff such as experimental and "extremely indie" games, software tools... It is a platform, storefront and community for things game developers make.
IO games on the other hand are usually characterised by being (sometimes only allegedly) multiplayer web browser games with super minimal friction, just open a page and play.
Put differently, I wouldn't call a supermarket a toothpaste store even though that is indeed an item supermarkets sell.
IO games on the other hand are usually characterised by being (sometimes only allegedly) multiplayer web browser games with super minimal friction, just open a page and play.
Put differently, I wouldn't call a supermarket a toothpaste store even though that is indeed an item supermarkets sell.
Maybe this was meant as joke, but this isn't true at all.
I believe it refers to casual multiplayer browser-based games.
I joined one of the Brains server and was curious what the experience was for 50~ players. The movement was a bit janky, as expected from websockets. I was also curious about the networking compression, because I'm doing something similar.
I'm not sure if just doing LZ-string compression is enough. 50 players use about 20KB/sec data. Comparing that to Warzone at 150 players uses only 48KB/sec data. Unless you have unlimited data, that could be costly in cloud bandwidth.
It was also curious that the compressed buffer of bytes look like this: 埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼
I wasn't sure if that is how LZ-string compression just ends up, but its a bit jarring.
In any case, there is lots of room for improvement on the networking side to reduce potential costs.
The whole project is very impressive, so great job!
I'm not sure if just doing LZ-string compression is enough. 50 players use about 20KB/sec data. Comparing that to Warzone at 150 players uses only 48KB/sec data. Unless you have unlimited data, that could be costly in cloud bandwidth.
It was also curious that the compressed buffer of bytes look like this: 埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼
I wasn't sure if that is how LZ-string compression just ends up, but its a bit jarring.
In any case, there is lots of room for improvement on the networking side to reduce potential costs.
The whole project is very impressive, so great job!
Movements pretty tight in our websockets:
https://gooberdash.winterpixel.io/
It's all about the client side prediction & roll back networking algorithm. Our game states end up being ~1kb at 30hz, which typically fits into a single packet, so websockets aren't terrible. An unreliable protocol would be better, of course.
https://gooberdash.winterpixel.io/
It's all about the client side prediction & roll back networking algorithm. Our game states end up being ~1kb at 30hz, which typically fits into a single packet, so websockets aren't terrible. An unreliable protocol would be better, of course.
>client side prediction & roll back networking algorithm.
I need to look into this! I made a little networked 2D physics thing (just bouncing balls) and I was surprised how well it stays in sync, because of course both machines just simulate the same result.
I added some interactivity and simulated lag / packet loss, at that point I added an interpolation function so an entity could have a "target" and gradually slide there over a few frames. I've seen some other games do that as well.
I haven't gone very in depth on this, but VALVE has an excellent article on the subject, also covering input prediction and lag compensation:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
I need to look into this! I made a little networked 2D physics thing (just bouncing balls) and I was surprised how well it stays in sync, because of course both machines just simulate the same result.
I added some interactivity and simulated lag / packet loss, at that point I added an interpolation function so an entity could have a "target" and gradually slide there over a few frames. I've seen some other games do that as well.
I haven't gone very in depth on this, but VALVE has an excellent article on the subject, also covering input prediction and lag compensation:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
There's an awesome talk by someone in the overwatch team in youtube. It's about ECS but it has a big section on networking that had some useful tips.
Edit: here it is - https://www.youtube.com/watch?v=W3aieHjyNvw
Edit: here it is - https://www.youtube.com/watch?v=W3aieHjyNvw
This one's good but pretty advanced. We haven't implemented a lot of these techniques in our games. This is a great starting point:
https://gafferongames.com/post/introduction_to_networked_phy...
https://gafferongames.com/post/introduction_to_networked_phy...
>The movement was a bit janky, as expected from websockets
Could you elaborate on this? I played a few "io games" and it seemed pretty smooth (except for the occasional laggy player).
On the other hand, I did a bit of testing with WebSockets a few months ago. If I understand correctly, there are significant downsides to using TCP for games (or any latency sensitive communications for that matter): TCP header being >2x bigger than UDP, additional control packets, and TCP delays transmission of new data while old (stale) data is retransmitted. So WebSockets have these same downsides, due to being hosted over TCP.
Despite all that (TCP supposedly guaranteeing delivery of WebSocket messages), I was able to produce packet loss. So you have the downsides, and as far as I can tell you don't really have the upside, since if you actually want guaranteed delivery you still need to build your own thing on top of it (which you could have just done on top of UDP in the first place, at least for messages that need it!)
(Take this with a grain of salt, aside from a bit of dabbling I have close to zero knowledge and experience with networking.)
Could you elaborate on this? I played a few "io games" and it seemed pretty smooth (except for the occasional laggy player).
On the other hand, I did a bit of testing with WebSockets a few months ago. If I understand correctly, there are significant downsides to using TCP for games (or any latency sensitive communications for that matter): TCP header being >2x bigger than UDP, additional control packets, and TCP delays transmission of new data while old (stale) data is retransmitted. So WebSockets have these same downsides, due to being hosted over TCP.
Despite all that (TCP supposedly guaranteeing delivery of WebSocket messages), I was able to produce packet loss. So you have the downsides, and as far as I can tell you don't really have the upside, since if you actually want guaranteed delivery you still need to build your own thing on top of it (which you could have just done on top of UDP in the first place, at least for messages that need it!)
(Take this with a grain of salt, aside from a bit of dabbling I have close to zero knowledge and experience with networking.)
CJK characters occupy a vast portion of the printable Unicode characters. [1] Two of the largest blocks include
* U+3400 to U+4DBF
* U+4E00 to U+9FFF
Your string decodes to \u57d2\u6111\u48d4\u6a64\u3930\u3099\u37cd\u7a26\u7366\u0999\u60dd\u44c7\u5f37\u681b\u4ccc\u06ec\u4303\u0329\u4f7c
[1] https://en.wikipedia.org/wiki/CJK_Unified_Ideographs
* U+3400 to U+4DBF
* U+4E00 to U+9FFF
Your string decodes to \u57d2\u6111\u48d4\u6a64\u3930\u3099\u37cd\u7a26\u7366\u0999\u60dd\u44c7\u5f37\u681b\u4ccc\u06ec\u4303\u0329\u4f7c
[1] https://en.wikipedia.org/wiki/CJK_Unified_Ideographs
A sure way to never finish a game is to start by writing an engine.
You can absolutely make your own tech but at every step that tech should be tailored for your project, as opposed just a general game platform.
You can absolutely make your own tech but at every step that tech should be tailored for your project, as opposed just a general game platform.
I'm going to start a blog!
And by "start a blog" I mean write a whole new blog engine entirely from the ground up...
And by "start a blog" I mean write a whole new blog engine entirely from the ground up...
Maybe not a great example, you can make a simple blog from scratch in like 20 lines of PHP/MySQL. I did this as a young teenager by copy-pasting some example code from Tizag's MySQL tutorial (which amazingly is still up, in its original condition![0])
(I wish I could share the original code, but I don't have it here.)
[0] http://www.tizag.com/mysqlTutorial/
(I wish I could share the original code, but I don't have it here.)
[0] http://www.tizag.com/mysqlTutorial/
I've fallen into this trap so many times... Last time I decided to do the absolute minimum. I just glued together some Markdown library with Jinja for a total of ~50 lines of Python. Turns out you can do a lot with just that.
You can comparably do a lot by making your own engine, if you know what you're doing. Stardew Valley was written in XNA but other than that there's no engine. Lots of games written in monogame, SDL, SFML, PyGame, and other "frameworks". People also think that a 3D engine is absurdly hard but that's because they spend most of their time implementing PBR and a full featured level editor in their own custom UI framework. If you use off the shelf parts for things like physics, UI, and implement common file formats for levels then you can focus on the things you find interesting and still make a game. I'd wager there's a lot more unfished unity projects than unfinished game engine projects
I bet you're a much better developer for going that route. So many lessons to learn with diy.
I mean it only takes an afternoon if you're just making it for yourself.
Can you elaborate on what part of moddio you're referring to? Was it a product of a failed attempt to create a game?
I had the same initial response, but I think what parent us saying is that people should consider using this engine, rather than spinning their own?
I'm not sure I agree, as many great games are built on in-house, bespoke engines, or else custom modifications to existing engines. But for the purpose of rapid prototyping, the intended use of this engine, it definitely makes sense to use a preexisting engine in most cases.
I could be wrong about parent's intending meaning though.
I'm not sure I agree, as many great games are built on in-house, bespoke engines, or else custom modifications to existing engines. But for the purpose of rapid prototyping, the intended use of this engine, it definitely makes sense to use a preexisting engine in most cases.
I could be wrong about parent's intending meaning though.
[deleted]
Most people who write engines probably don't actually want to make games in the first place and would rather be making engines anyway.
I agree. However there is another trap with that. Engines which haven't made a game usually haven't solved the hard problems yet. It's just easy or fun code that works well in convenient circumstances.
amen to that! (own experience)
I find that node js based multiplayer backends will eventually slow to a crawl as the number of connections goes up. How have you solved this problem? Wouldn’t something like Go be a better alternative here?
I don’t see why. Connection-wise, the node event would loop make I/o blocking from the http request / response side a non issue. I doubt the backend is doing physics heavy stuff for the front end.
You must perform physics calculations on the backend if they are significant features that influence player positions.
Node also only works off a single core.
Node also only works off a single core.
Node of course can work on multiple cores, using worker threads [1]. You can even share large data efficiently using a SharedArrayBuffer.
[1]: https://nodejs.org/api/worker_threads.html
[1]: https://nodejs.org/api/worker_threads.html
It isn’t trivial to just split up a game into múltiple worker threads and keep everything in sync. With Go, it’s much easier.
Can you expand on the low hanging fruit of splitting a game into multiple goroutines?
What lends itself well to this?
What lends itself well to this?
goroutines
There is still considerable overhead turning things into buffers and back. Was there ever a good reason given as to why passing an object to a worker normally has to convert everything to string and back? It is just so completely idiotic.
I see. That makes sense.
They use uWebSockets (https://github.com/uNetworking/uWebSockets), which was written in C, but has an interface to use in NodeJS. It's been really performant for me in my simple tests compared to other popular websocket libs that slow down fairly quickly.
I get the feeling that the bottleneck in most IO games is the IO (no pun intended, the genre name comes from the TLD), which makes Node a good choice.
Scaling can indeed become a consideration, especially with a large number of connections. In our case, we've optimized our backend to handle a substantial number of concurrent connections efficiently. Also, each game is limited to 64 players max, although we tested up to 100+ connections and didn't notice any performance issues. Each game runs in isolated containers.
What's your motivation for building a new engine?
Seems like you've built in some really specific things (from the README);
- Weapon system (melee & projectile)
- Shops
- Client-side predicted projectile + unit movement
- ETC
Why did you decide to bake those into the engine instead of "copyable" plug-ins? Of course lots of games dont need these things - is this a game engine? or is this a FPS/RPG/Else game engine?
I dont hate on tech, but im still left asking "why"? What's it for? Why would I use this over "Three.js" and my own server? :) (I ask only to get your take)
Seems like you've built in some really specific things (from the README);
- Weapon system (melee & projectile)
- Shops
- Client-side predicted projectile + unit movement
- ETC
Why did you decide to bake those into the engine instead of "copyable" plug-ins? Of course lots of games dont need these things - is this a game engine? or is this a FPS/RPG/Else game engine?
I dont hate on tech, but im still left asking "why"? What's it for? Why would I use this over "Three.js" and my own server? :) (I ask only to get your take)
Thanks for the question. We consciously decided to make our engine more opinionated compared to other modular alternatives, because we want to be extremely fast at developing 2D multiplayer games. For example, I made a simple MMORPG in 2 hours (https://www.youtube.com/watch?v=GZVsxkALR5U).
I believe that there's an inverse correlation between ease-of-use and level-of-customization. We chose the former to address the gap between casual game devs and multiplayer games which are known to be difficult to build.
I believe that there's an inverse correlation between ease-of-use and level-of-customization. We chose the former to address the gap between casual game devs and multiplayer games which are known to be difficult to build.
"What's it for?"
Apparently not for you, but people who want to build such a specific game. Not every engine is general purpose.
Apparently not for you, but people who want to build such a specific game. Not every engine is general purpose.
This is a fantastic project to open source, thank you so much! I’m going to be pouring over the code during the EOY holidays!
sounds exciting! let us know if you have any questions. we have a Discord link on our homepage as well.
I've had some hobby projects that seem like a good fit here. The low-code and interactive editor make it nice for a hobbyist, even though I can code... there's a certain concentration I just don't feel like when I'm doing a hobby project.
For me personally the thing I've excited about is generating maps and worlds. It looks like the best way to do this is to export the game as JSON, programmatically edit it, and then import?
I'm a little intimidated though... the unedited tutorial world is 3500 lines of JSON. There's a lot to try to understand there.
My first idea at how to do that is to make deliberate edits and see how that changes the JSON (I also need to look up a nice JSON diff viewer). This will help point to the parts I want to touch. I'm also guessing I'll do things like collect assets and map tiles in the interactive editor.
Is this a reasonable approach? Are there tools to help here?
For me personally the thing I've excited about is generating maps and worlds. It looks like the best way to do this is to export the game as JSON, programmatically edit it, and then import?
I'm a little intimidated though... the unedited tutorial world is 3500 lines of JSON. There's a lot to try to understand there.
My first idea at how to do that is to make deliberate edits and see how that changes the JSON (I also need to look up a nice JSON diff viewer). This will help point to the parts I want to touch. I'm also guessing I'll do things like collect assets and map tiles in the interactive editor.
Is this a reasonable approach? Are there tools to help here?
I wouldn't recommend you modify the JSON directly, as it's quite illegible and bloated. There are actions in modd.io that allow you to modify the map directly. One creator in our community is dynamically generating the map using ChatGPT. He's building a hide & seek sends a prompt to generate 2D map JSON then loads it in the map every time the new game round begins. I'd share the game, but he hasn't published it yet.
Also, there is a community member who's building an interpreter for our game JSON such as https://pypi.org/project/pymodd/
Also, there is a community member who's building an interpreter for our game JSON such as https://pypi.org/project/pymodd/
Glad to see more open source projects like this out there. Surprised it has under 100 stars on GitHub.
Please don't get it the wrong way, this is genuine question. Why is under 100 stars on GitHub surprising?
It's generally correlated with overall popularity would be my guess?
Perhaps because they just made it public?
I'm trying to make NPCs out of AI agents so this would be really useful to me. Thanks for open sourcing the work!
Oh, I've already done this! Happy to help. Feel free to DM me here on Discord. (I should probably make a YouTube tutorial for this)
I couldn't figure out how to DM you on HN, so I'll send you an email. Thanks!
I see it says "Credits: Isogenic Game Engine" is it based off that or just throwing it a name drop?
Unless it’s as advanced as Unity, is it possible to even sell an engine these days?
Something like this is expected to be free
Something like this is expected to be free
It's an extremely bad idea to go and build from scratch a do-everything game engine with AAA 3D capabilities, but there is absolutely space for engines with a very specific focus.
If you want to make a VN, would you rather open up a blank project in Unity or just use Ren'Py?
In the commercial space, RPG Maker and GameMaker continue to exist.
If you want to make a VN, would you rather open up a blank project in Unity or just use Ren'Py?
In the commercial space, RPG Maker and GameMaker continue to exist.
[deleted]
With Unity, the trust is gone. I don't think there's ever been a good time to be in the game engine business but this is probably the best time.
This is an unfair comparison imo. Just because Dewalt (or similar) sell a comprehensive toolbox does not mean people won't pay for a standalone screwdriver. It all depends on what people feel they need.
I looked at, at least 8 different moddio games. They're all top down Newgrounds games with painfully obvious similarities. The only exception was one where you control a fish. In that one the water splash animation occurred on the grass leaving me to believe the game was pushing the envelope of what the engine could do.
One trick pony engines worked in the 90's because something like an FPS required rare personnel to develop given the limited hardware. That's why you'd get weird kids stuff like Nerf Arena Blast (Unreal 1) and Super 3D Noah's Ark (Wolfenstein 3D engine). Eventually you had Renderware, but that was like the Unity of the 2000s.
There's a world of JS game engines, more advanced, for free today https://github.com/collections/javascript-game-engines
Moddio has built in multiplayer server support that seems pretty intuitive, that's definitely something special. But a screwdriver that makes Stick RPG clones isn't very profitiable.
One trick pony engines worked in the 90's because something like an FPS required rare personnel to develop given the limited hardware. That's why you'd get weird kids stuff like Nerf Arena Blast (Unreal 1) and Super 3D Noah's Ark (Wolfenstein 3D engine). Eventually you had Renderware, but that was like the Unity of the 2000s.
There's a world of JS game engines, more advanced, for free today https://github.com/collections/javascript-game-engines
Moddio has built in multiplayer server support that seems pretty intuitive, that's definitely something special. But a screwdriver that makes Stick RPG clones isn't very profitiable.
fwiw they're called "IO games" and they're - even still - not-unpopular games
[deleted]
[deleted]
I'm surprised it's not written in Rust :thinking:
We made this engine low-code and multiplayer-first, so developeres can quickly prototype casual multiplayer games.
I hope some of you guys will find this useful. Would love to hear feedback also. Thank you.
Engine Demo: https://www.modd.io