[POiNTx]

That's what I did with: https://territoriez.io/

It's a clone of https://generals.io/

It's built with LiveSvelte. It doesn't need any predictive features as it's basically a board game and runs at 2 ticks per second. It does use optimistic updates to show game state before it actually updates on the server. The server overrides the game state if they're not in sync.

All game logic is done inside Elixir. To do predictive correctly, you'd need to share logic between the server and the client. Otherwise you're writing your logic twice and that's just a recipe for disaster.

One possible solution which I didn't investigate, but should work, is to write all game logic in gleam (https://gleam.run/). Gleam is compatible with Elixir, AND it also can compile to js, so you could in theory run the same code on the server and the client.

Now this is a big mess to understand, you could say "why don't write it all in js and be done with it" and you'd make a very good point and I'd probably agree. The main advantage you get is that you can use the BEAM and all it's very nice features, especially when it comes to real time distributed systems. It's perfect for multiplayer games, as long as you don't take into account the frontend :)

[rytill]

Hey, about your clone of https://generals.io - why not make it a better designed version of that game instead of just a clone? Perhaps you have plans to. There are things about the original that kind of suck.

1) Spawning closer to the center is just strictly significantly worse, corners are best. It's essentially an auto-lose to spawn anywhere but an edge or corner in a FFA.

2) Getting literally all of someone's armies when you kill them is so good that it pushes players to just try to all-in the first person they meet every single time. There is no way to "fast expand" once you've met another player because of the first factor, and also that 40-50 armies on a neutral castle is very high. I think the "early-game" can be much better designed.

3) Perhaps you should be able to change your capital, which could solve problem 1.

4) There are many ways you could keep the simplicity of play, but boost the richness and depth of the actual gameplay. For instance, more chokepoints that would allow actual strategic use of territory and army positioning. Different tiles which have different advantages to owning. Borrowing from something like civ - forests or hills which have a defensive boost when you're inside. Rivers which attacking across is disadvantageous.

Just some feedback from someone who enjoys games like Chess and Starcraft, and thinks the core gameplay loop of generals.io is really fun, but believes that it is seriously lacking in strategic depth.

[POiNTx]

It's a little bit different from generals.io but the points you mention are very valid. I originally started working on it as a showcase of LiveSvelte + I like generals.io a lot and thought it could be improved visually + UX wise. Then afterwards started thinking a bit about the game design and what I could improve, but eventually burned out on the project. Was also at a time when I wasn't working but am working again.

Maybe I'll pick it up at some point, but also open to other people working on it if they're interested. I'd be open to partner up with someone to eventually make it monetized. It's not open source as I wanted to add paid features (cosmetic features, not pay to win).

A solution for most of these issues is a modifier system. I have a basic one in place and wanted to experiment with different modifiers. A modifier can be anything, like prevent spawning in the center, to increasing rewards for capturing cities, to even allow crossing the border of the map into the other side, like pacman (which could address point 1). Then the goal would be to see which modifiers stick with the player base, and make them the default, while still allowing for custom games with different modifiers. Generals has a similar system in place and they sometimes make the modifier the default for the day, which I like a lot.

[djbberko42]

As someone who started using Elixir this year (for work) this is really cool. I have had some ideas for some SPAs and games just like these io ones and it'd be great to use Elixir for them. Do you think a top down fps io game would be plausible with this setup? There would need to be at least 60 ticks per second I'd think.

[POiNTx]

Definitely possible. Tick rate isn't the problem, Elixir is very performant. Just the predictive elements are an issue if you're working with 2 different languages. I'd go with Gleam from the start and look into compiling to js.

[spiderice]

Don't you lose a lot of the niceties of Elixir when switching to Gleam, just because Gleam is a younger project? LiveView would be the big one I'm thinking of. Do you see that as a worthy trade?

[POiNTx]

You can still use LiveView/Phoenix/Elixir, but have your game logic be in Gleam. I haven't used it though so I could be wrong here.

A little bit more about it here: https://katafrakt.me/2021/10/13/app-with-elixir-business-log...

You'd call Gleam code like this inside Elixir:

`:game.move(game, player_1, :left)`

And you'd receive an Elixir map `%Game{}` which you can then use in LiveView. If that makes sense.

[buzzerbetrayed]

Cool! I'm going to have to look more into Gleam. I saw it hit v1.0.0 on ElixirForum last month, but I figured it was an alternative to Elixir rather than something that played so nicely with it.

[ElFitz]

> To do predictive correctly, you'd need to share logic between the server and the client. > > One possible solution […] is to write all game logic in gleam […]

Rust, with Uniffi, can also be a good candidate. You’d be targeting WebAssembly.

[shirogane86x]

Is there a way to emit WebAssembly with Uniffi? I looked for it before, but I couldn't find it (I'm using it in a project to share login between the backend and Kotlin/Swift apps. I wanted to share it with JS for a web frontend, but didn't find any docs mentioning it)