Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

calvinflegal.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#21

Post by josefrichter »

zuzululu wrote: post #7

was expecting a bit more substance but always interesting to read different approaches. but I do wonder if BEAM is a bit of an overkill, even fly.io (known among developer threads to be very unreliable uptime) wouldn't be my first pick. Cloudflare Durable Objects really is generous, not often can you get replicated database and realtime sync for such low barrier in cost and implementation. I do wonder tho what Cloudf…

BEAM is rarely overkill. It’s fairly simple, once you grasp the concepts. It’s just from the outside people may think it’s rocket science.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#22

Post by cultofmetatron »

apt-apt-apt-apt wrote: post #9

Really interested in hearing more about the architecture. Especially (1) why you chose Elixir, Phoenix over TS (2) how you dealt with real-time multiplayer. Aside: The links to the web game in the post don't lead to being able to play.

not op either but I built my entire startup using elixir. We have a realtime sync component across a range of devices that sync data between them.

It (phoenix channels) worked out of the box. in the last 6 years of development and growth, not once have we ever had to even discuss scaling issues related to it.

It just works and when you're in a startup, the more you can focus on growing your product instead of scaling issues, the more you're winning.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#23

Post by ramchip »

frail_figure wrote: post #12
zuzululu wrote: post #7

was expecting a bit more substance but always interesting to read different approaches. but I do wonder if BEAM is a bit of an overkill, even fly.io (known among developer threads to be very unreliable uptime) wouldn't be my first pick. Cloudflare Durable Objects really is generous, not often can you get replicated database and realtime sync for such low barrier in cost and implementation. I do wonder tho what Cloudf…

> Cloudflare Durable Objects really is generous, not often can you get replicated database and realtime sync for such low barrier in cost and implementation. BEAM gives it to you for free, and you don't rely on an Internet-scale monopoly to run it.

I love the BEAM and programmed on it for many years, but it really does not provide anything like durable objects.

1) It's very difficult to ensure globally serialized ownership with strong consistency in a distributed Erlang cluster when nodes are allowed to fail. Stuff like Horde will let you do some rough "run an instance of this process somewhere in the cluster", but it's eventually consistent (you may have multiple instances at times) and doesn't deal with netsplits well.

2) Mnesia is fine to replicate state within a network switch or very reliable LAN, but not over WLAN/Internet. It can enter split brain conditions and require external reconciliation. RabbitMQ suffered from Mnesia problems for many years and ended up replacing it with their own DB implementation using the Raft protocol.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#24

Post by calflegal »

oezi wrote: post #8
calflegal wrote: post #3

I should've said more about the tech. I will later. The server is in NJ. If you're in the EU the game might really lag. Sorry!

You mention it is possible to play via Web, but all links just lead to pages which point to Apple's app store. Game over for Android and the web?

Yeah. Shortly after I wrote this I shut down the web client. I wanted to focus on the other clients. Sorry. Kind of ruined one of my points

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#25

Post by calflegal »

I'm sorry I took down the web client shortly after writing this post. Really ruins the point I made of being able to contrast web vs native performance, doesnt it? I realized I wanted to narrow my focus on client codebases. Fixing the post shortly.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#26

Post by jiggunjer »

colechristensen wrote: post #10
apt-apt-apt-apt wrote: post #9

Really interested in hearing more about the architecture. Especially (1) why you chose Elixir, Phoenix over TS (2) how you dealt with real-time multiplayer. Aside: The links to the web game in the post don't lead to being able to play.

Phoenix is delightfully fast and not having to deal with two entirely different application stacks where your application is split down the middle (or the javascript ecosystem) is a breath of fresh air.

Isn't split stack architectural, i.e. client heavy vs thin client. Not a hard TS feature?

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#27

Post by calflegal »

ipnon wrote: post #5
calflegal wrote: post #2

My post about my recent project, Migo Games

I’ve never thought about how the room model matches the LiveView socket model before. Which socket library are you using?

a room is a genserver. For the socket itself, https://github.com/davidstump/SwiftPhoenixClient

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#28

Post by calflegal »

ramchip wrote: post #23
frail_figure wrote: post #12

Earlier quoted context omitted.

> Cloudflare Durable Objects really is generous, not often can you get replicated database and realtime sync for such low barrier in cost and implementation. BEAM gives it to you for free, and you don't rely on an Internet-scale monopoly to run it.

I love the BEAM and programmed on it for many years, but it really does not provide anything like durable objects. 1) It's very difficult to ensure globally serialized ownership with strong consistency in a distributed Erlang cluster when nodes are allowed to fail. Stuff like Horde will let you do some rough "run an instance of this process somewhere in the cluster", but it's eventually consistent (you may have multi…

See these are things I did not know. This is why I said I was 'not qualified', in the post, haha. I do use Horde for the matchmaking. I have 2 hosts in the cluster.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#29

Post by calflegal »

apt-apt-apt-apt wrote: post #9

Really interested in hearing more about the architecture. Especially (1) why you chose Elixir, Phoenix over TS (2) how you dealt with real-time multiplayer. Aside: The links to the web game in the post don't lead to being able to play.

Hi! I'm sorry I took down the web client shortly after I write this in order to narrow my focus on the client codebase. I realize I ruined my point about being able to compare the client performance. I'm editing the post shortly.

I've been curious about elixir for years. Since maybe 2016. I tried in the days before AI, but I couldn't really get over the hump of syntax and BEAM and all of that.

I'd read it was the kind of thing that would be good for games, but I didn't really understand why until AI helped me build this.

A room is a GenServer. Which means its a process. Which means the unit of gameplay matches the unit of compute, kinda. That's really great. You can't really do that with node. Well, I guess with Durable Objects / PartyKit you have a closer match there.

There is a matchmaker process that runs. It assigns your socket to a room. But yeah, after that, your socket is exchanging messages with that room.

Because arrow physics are simple, the client predicts how it thinks the server will say things will be, and reconciles if / when wrong when it hears from the server about the room state.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#30

Post by calflegal »

Doohickey-d wrote: post #18

A question for OP: why did you choose Crunchy Data for your database, instead of Fly's own managed postgres offering? Because the latency between Fly and Crunchy Data must be quite high, given that they are probably not in the same datacenter.

Honestly? It's cheaper. hahaha.
Post reply on HN