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…
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.
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?
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.
Or we could not encourage depending on a constantly-breached centralized “security” authority. https://hn.algolia.com/?q=okta
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.
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).
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…
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.
Or we could not encourage depending on a constantly-breached centralized “security” authority. https://hn.algolia.com/?q=okta
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.
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
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...
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
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.
Most people who write engines probably don't actually want to make games in the first place and would rather be making engines anyway.
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.
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.
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.
Can you elaborate on what part of moddio you're referring to? Was it a product of a failed attempt to create a game?