Show HN: I'm open-sourcing my game engine(github.com) Modd.io is a collaborative game editor that runs in browser. It's kind of like Figma for game dev. 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 |
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
Looking forward to trying it out on the computer instead!
What you described should really not happen though, I thought Google forbid this already
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!
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.
And by "start a blog" I mean write a whole new blog engine entirely from the ground up...
(I wish I could share the original code, but I don't have it here.)
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.
Node also only works off a single core.
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)
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.
Apparently not for you, but people who want to build such a specific game. Not every engine is general purpose.
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?
Also, there is a community member who's building an interpreter for our game JSON such as https://pypi.org/project/pymodd/
Something like this is expected to be free
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.
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.
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.
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_...
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.)
* 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
Edit: here it is - https://www.youtube.com/watch?v=W3aieHjyNvw
https://gafferongames.com/post/introduction_to_networked_phy...
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.
What lends itself well to this?
Edit: Re-reading, I guess this is specifically targeted at Okta, who have had their share of problems.
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.
Also, there are super strong incentives to hack Okta, so naturally more people will try to hack Okta.
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.
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.