I’d certainly prefer to use an app rather than having to hunt for quarters. If the app didn’t exist, I’d probably have to go to a bank to get quarters or an ATM to withdraw cash and beg the closest convenience store to give me change.
Granted, there are probably better solutions that require neither quarters nor a mobile app, but between those two, the mobile app wins for me.
There is an in between. Our buildings laundry has a payment machine that takes credit cards and either gives you a credit card sized laundry card or recharges it. You tap the card to start that machine. You can also use the smart phone app, but I don’t think it’s used by many.
It works pretty well.
Parking meters are another thing that seems to be going the app route. I use one locally but when I travel it’s usually not the same network so its figure out how to do it.. (website, payment kiosk, another app…)
Apps tend to be a pretty good solution for regular local users. They're less good when you're dealing with different apps/kiosks/etc., with different interfaces, and different ways of storing value in different cities.
Adding app operation alongside coin operation would have been an improvement in useability. Replacing coins with apps is just making it suck in a different way.
From the consumer perspective, probably. But from a laundromat's perspective, even if only a fraction of users use coins, they still need to deal with coins.
Once you're below some use threshold, a lot of places would prefer to ditch cash entirely.
It reminds me of the cycle of enshittification: once you have a captive audience, you start bumping the profits at the cost of the user experience.
It looks like something similar is in effect here: instead of meeting the different customers where the customers alrady are, it's the company's preferred way or the highway.
It is an either or for some businesses. Coins in the USA are in a massive shortage the last few years. Change machines aren’t cheap and repairs can be costly. It makes financial sense to switch to these apps or people wouldn’t do it.
Yeah, getting quarters is a real problem, especially when all of the banks in your area are only open during business hours and not on weekends. That said, I'd personally prefer quarters over an app, since quarters are much more fail-safe. The system that I'd prefer overall though would be some kind of prepaid account and an NFC card. UCLA had this system when I was a grad student there and it was really easy to use. You just tap your card on the reader by the door and select what machine to use. Everything ran smoothly.
We're using Depot at Hathora, and it's enabled us to focus on our platform development instead of worrying about CI/build pipelines. We're very happy with the speed improvements we're noticing.
Hathora Cloud is still very young and iterating quickly. We've been in a private beta with select design partners and we're onboarding users slowly via signups.
When we make it generally available, we will definitely make pricing front and center!
Is Hathora a product? The blog post mentions a free tier, which is great, but I can't find any references to any pricing or tier information at all, or even a link to buy something. There's documentation showing how to run a dev server locally, but, like...what happens then?
Does Hathora have any customers? It says "scale to millions." Has anyone ever used Hathora to scale to millions of something?
Not dsiddharth, but for what it's worth I am using Hathora for my upcoming game (it's almost complete!). Their product still very new, but they have been extremely helpful with every step of the process building with Hathora.
They have two products - an open-source dev framework (free) and a cloud-hosting product (paid).
My games will likely never reach millions players, but my first two games led to over 1,000 sign-ups and I've made over $1k in revenue (which I'm super proud of). I can report back with how my newest game does after it launches.
My first two games were built with my own hacky web sockets implementation. From a software perspective it's pretty messy, but it gets the job done haha.
I actually had built an alpha version of my 3rd game with my own networking code, but because it is more of a real-time game, there were tons of bugs. Switching to use Hathora for the back-end logic has made the game much more stable so I can finally work to release the game.
You can check out my first two games here: https://gomobo.app/. They play kind of similar to Jackbox games, but with more strategy board game elements. Would love to hear what you think!
So this is basically a fancy game-specific VPN isn't it? How is it different from Steam Networking which lets players connect to their closest endpoint and routes traffic through Valve's backbone? The only way this service could offer any benefit over Valve's is if you can run edge processing right at the gateway for a Matrix.org-esq protocol for a distributed-authority netcode so that the gameclient's physics/hit-prediction length is only the latency to its gateway rather than all the way to the central authoritative server. But then this would need gamedevs to actually know what they're doing regarding how to re-architect netcode, which, given the quality of Riot's Valorant supposedly being the shining beacon of engineering among gamedevs, is not a very auspicious prospect.
I'm not too familiar with Steam Networking, but at a glance here are some differences:
- Steam Networking seems mostly for peer-to-peer messaging, so it's closer to a STUN server (used by WebRTC for sending UDP datagrams). It's excellent for sending messages over high-quality links, but if you want to run server side logic, it doesn't seem like Steam Networking will help much.
- On the flip side Hathora is a server-authoritative framework, which can run arbitrary game code on our infrastructure. This is closer to a cloud provider. The difference between us and just using AWS or DO is that we're providing the "Steam Networking"-like edge network out of the box and tailoring our use case to the needs of game devs.
- Lastly, we can actually spin up compute infra at the edge if enough of your users are originating from a location far from the rest of your servers. Let's say your game starts to go popular in Asia today, our routing layer is smart enough to launch a server in Singapore instead of connecting users to far away game servers.
You're missing the external requirements a game might have. Multiplatform? Multiplatform with shared online play? Publisher wants certain services? Publisher already has its own services? Service sucks to actually work with?
Well, matchmaking and lobby is at least as important as connectivity ; not every multiplayer game requires absolutely flawless connectivity and pings in tens of ms, but every multiplayer game requires some kind of a player profile , and many of those games have a notion of "match", and "players participating in a match", thus requiring a matchmaking based on some rules, most often those are player level and user location. Almost every game I, as an ops engineer, took part in launching and running, was implementing those two parts, with varying degrees of success and finesse
Can you enable ShowDead and answer XeonMC's question? Seems like a normal question, not sure how the user got in the spam filter. Happens a lot these days to otherwise normal questions.
Right now Hathora writes game data locally to disk. This is nice for the local dev experience since you don't need to have a db running locally.
For production use cases I've been mounting a networked drive (AWS EFS) to provide shared storage across nodes. It should be pretty easy add additional storage adapters (like Postgres) as well.
Granted, there are probably better solutions that require neither quarters nor a mobile app, but between those two, the mobile app wins for me.