Player wants to play Eon Altar, a game where their phone connects to their PC. However, they're at University, or they otherwise don't control the router/network they're connected to, and the PC/phone can't see each other, and therefore they cannot currently play.
The game heavily relies on the network being really fast (low latency), and going through the Internet could possibly make the experience extremely poor. So we--the developers--when designing the game, decided that it should only work over local area network (LAN), which clearly prevents our player from playing.So here's the catch: do we create a solution where they can directly type in an IP Address on their phone to connect to the PC, at the risk that we have way less control over the experience, and the latency might make the game unplayable (and result in an unhappy player, and thus bad reviews/word-of-mouth); or do we just leave it be and tell the user, "Sorry, no dice?" (and result in an unhappy player, and thus bad reviews/word-of-mouth).
We know how the experience will degrade: we saw this at PAX Prime, with 60,000+ techno-savvy geeks all on our mobile/wifi devices. Despite having our own routers, the radio interference made the game frustrating. Your movement marker wouldn't react cleanly or smoothly and dialogue responses would sometimes hang briefly. Pressing and holding for free-running was frustrating because it would take 200ms - 500ms for your character to start running, and stopping also took that long, so you'd overshoot, constantly. It all made the game feel really unresponsive--because, well, in the context of a extremely high latency network, it really was unresponsive.
There are in-between options here. We could bury the Connect Directly to IP Address under a help menu as a last resort kind of thing, with big warning signs on it saying the game wasn't really designed for over-Internet play, but is that really helpful? Are we still going to get slagged, even with a warning message?
There's also a maintenance cost and a support cost. If the Direct to IP doesn't work for whatever reason, we (and by 'we' I mean 'I' as I'm the technical guy) will have another thing to possibly have to troubleshoot remotely via forum/email, but on the other hand, it is a workaround tool we could have built into the game. However, it means that I likely won't be able to fix some other unknown subset of bugs/features because I'll be spending my time implementing this feature.
But having players who can't play the game is frustrating on our end, too. We want people to play Eon Altar, and anything that gets in the way of that--short of not having a capable mobile device, sorry, but that's required as part of the vision of our product--should be fixed with prejudice if possible.
So, do we, or don't we? #IndieDev, #EonAltar
That is a tough one, but I am leaning towards "don't do it." We like to stretch to accommodate the customer, but I have been burned enough times allowing exceptions only to have the user come back and complain that it wasn't good enough and now they have an expectation that I will make it better that I am okay with drawing lines and saying certain things just won't be supported.
ReplyDeleteDo you want people complaining that they cannot play the game or writing reviews that the game is bad because you allowed them to play with a problematic configuration? I'd prefer to just say sorry, the game was designed only to function under specific circumstances.
That's my big fear. We don't exactly have a plethora of programmers to make it work super awesome if it turns out to be a bad idea, and removing a feature like that--even in Early Access--might be a Bad Idea™ as users might get really upset they could play, but then I took it away from them.
DeleteVery good points overall.
How about make it possible to enter an IP address, but if the latency is too high, pop up an error message instead of letting them play the game with bad latency. Maybe put up a message like 'Checking network latency' for a couple seconds while you test the speed.
ReplyDeleteWe currently have no tech to check for latency, though it wouldn't be that hard to build--a day of work to plan, build, test, then probably another 2 - 3 days to figure out UI (planning, building, testing). My estimate might be a big on the long side, though.
DeleteAnd perhaps we should, as it gives users a way to check if the game is performing correctly rather than throwing us under the bus if their router is half-cocked.
The problem is latency is variable, a one-time check wouldn't be sufficient--how frustrating would it be if we prevented you from playing if you just had a lag spike? Or later you get lag spikes, but we allowed the game to go forward. Far less likely on your own router (though not impossible, mind!) than over the Internet. The Internet throws all sorts of spanners in the machine.
Still, a latency monitor in general is a good idea, regardless of the Direct to IP Address issue. Something to think about.
I wouldn't do Direct IP. For one thing, you'll have an unfun time dealing with NAT traversal and other antics in network topology. You'll end up with a service that works in more cases than now, but still fails in a lot of cases.
ReplyDeletePerhaps consider a central server relay. The game signs into the relay and is assigned a hash. Phone clients sign in and use the same hash to connect. Your relay just routes packets from the game to the phones and vice versa.
Pros: this is almost certainly guaranteed to work, regardless of network hassles. Your connection issues will be minimal, as long as both sides have access to the internet.
Cons: latency will increase, but will be within internet norms. The big one is that you'll have to pay for this service, which includes a server and bandwidth.
Internet norm latency is too high still, generally. That's part of the problem :( Hence why we're on a LAN. We need near real-time communication between the phones and the PC to get the reaction fidelity required for smooth movement marker usage. Or at least as low as we can possibly get. We also can't really afford to pay for a central service at this point either.
DeleteBoth cons are currently insurmountable, which probably tells me I should just leave it as is and say, "Sorry, no dice."
Your point about NAT and network topology is also spot-on, another reason to say "Sorry, no dice."
All excellent ideas/points!
It also occurred to me that Direct IP won't solve your canonical example of the issue. The university wifi and wired networks are separate logical networks.
DeleteBut they will also be separate internal networks behind gateways. There won't be an IP that the student can type in and access from the other network. And the student has no control over the gateway, so forwarding ports and similar tricks won't work.
So basically, Direct IP can't solve your base user story for the issue, making it a bad solution overall.
Realistically, the only solution for the student would be to get his own wireless router, and then put the computer and the phones on the same logical network behind the router.
+1, agreed. LAN or central server, or bust.
Delete