Hello, members! 
I was figuring out how to implement a system where desktop players in a game is with only desktop players, so basically in a game, I want to implement a feature where only a certain platform player with another one. The reason is because I want to figure out, why when a mobile player walk, it has movement lag for the desktop.
Any suggestions?
Fix the movement lag.
If you are having the same game, you’ll have to teleport people once they’re in, and that will be bad for user experience and a bit unreliable.
If you have separate games, you’ll confuse people.
You’re best way through is to solve the root problem.
I’ve found that due to Roblox not making places automatically non-Experimental when you add them, adding any place to said game will result in cross-platforming not working. Just make sure players cannot teleport to these places.
It’s sort of a hack, but it’s sort of caused by how Roblox handles place creation within universes still, and may not work in the future whenever Roblox finally decides to fix the issue.
It’s the only way I’ve found that works without harming the UX of your game, such as teleporting.
Of course, the other alternative is to have a matchmaking system within a hub world, and then do some checks to figure out their platform and teleport the players that way.
You can detect if a mobile user/console user has custom buttons using InputService and kick them, saying “go to mobile version” or “Your device is not compatible” or teleport them etc. etc. It would be more effective if we had a feature for similar platform players to be paired together in servers.
Please note that this may lead to false positives.
I’d firstly recommend fixing the issue at hand which is mobile users looking like they’re lagging to desktop players.
If you cannot then you can create 3 places under your game. A lobby and a version of your game for pc and mobile/tablet.
In the lobby you’ll want to detect what platform the user is on and then teleport them to the associated game using TeleportService.
This is an XY Problem. Turn your focus towards determining why your game has input or movement lag as opposed to circumventing it by pitting players against others only if they possess the same device.
You are generally encouraged not to do this kind of thing anyway. Checking the player’s device is fine, though input can change or not give you desired results (for example, touching the screen on a touch screen PC and a tablet or phone will both return you with Touch input results). Not only may you get uncertain results with checking for input, but this is pretty bad for UX. I, as a PC user, may want to play a game with my friend who only has a tablet. Now we can’t, because the game force-separates us.
Review your game and check what is causing the issue. Come back once you think you’ve found the problem. Use any debugging tools available or ask around about your code.
Generally, you should never kick a player for these kinds of reasons, especially noting the fact that you mentioned “false positives”. This is bad UX design. A player should not be kicked for the faults of a developer. Your code should be interrupting UX to a minimum, or if possible, not at all.
I can be using a PC and have an Xbox Controller plugged in. If my last input type is Xbox, it’ll send me there. Same goes with if I have a touch screen PC and I touch my screen. This is not a wise idea.
In the first place, that’d mean you’d have to maintain three separate copies of each relevant place. That means going into each one and editing that small little detail here or there and ensuring consistency amongst all added places. Even with the use of packages or game assets, this is hard on you and you are bound to make mistakes. Taking a stupid risk over not fixing the root problem is, of course, a bad idea.
I also mentioned teleporting them, so my idea isn’t entirely flawed. But yes I know there could be false positives.
Also, it is not necessarily bad UX if you tell the user the correct reason on why they were not let in the server.
Teleporting is still an interruption of gameplay though. Teleports have their own potential risks as it relates to UX - this includes failed teleports, wrong teleports or intermittent teleports midway through. Teleporting should only be done for moving between games and for good reason.
BenTech mentioned the root problem first off. I simply expanded on it and provided a useful resource that is helpful for asking questions in the future. I’m fully aware that you mentioned this already, though that is not what my concern in replying to your post is.
See my comment about the first sentence. As for the rest, there is a specific reason why I quoted and called some suggestions bad and that is because they are bad. Teleporting or kicking is not UX-friendly. You will be met with players of short patience who may possibly not even come back. You do not use teleports or kicking even as workarounds. You fix your game, period. Relying on band-aid fixes from the start can have impact on development and several other factors in the future.
If you have an issue with my post beyond responding to my criticisms, please DM me.
You can just redirect when the player joins so it doesn’t affect gameplay.
For instance, @Merely 's Trade Hangout does this feature when a MembershipType of a player is not BC+ and the player tries to join the BC version of Trade Hangout. They just get teleported to the NBC Version.
If teleportation errors are a priority, you could just retry teleporting the player until a certain time out. If it is not successful, we can just send a message to the player saying that the teleport failed, and just kick them stating that they need to join the associated server for their device.
What’s your game? Any reason as to why your mobile players seem to lagging for desktop users but actually aren’t?
There’s a difference between Trade Hangout’s application of such a system and OP’s use case, which is why it works for TH and not for OP.
As it relates to Trade Hangout, there exists two separate games (not places, both versions are Start Places of a separate game): the Builders Club version and the Non-Builders Club version. The teleport mechanic was implemented after the removal of BC-only game configurations in the game settings. MembershipType is guaranteed not to change on the server because it can’t be changed - it’s fetched from the website and it remains like that.
Once you settle into a server of Trade Hangout, chances of you hopping servers or needing to change games is highly unlikely. That’s why it’s fine in this use case. MembershipType is a static value that you know for sure is not variable or able to be changed. There are three concrete enums you can fetch from and you don’t have to worry about checking across several types. If you have Enum.MembershipType.None, you’re sent off to the NBC version, otherwise nothing is done.
For OP’s use case, what they are trying to do is teleport players to different versions of the game based on their device type.
First of all, there is no way to detect the device that a player is using. The way developers “check for devices” is by determining what input states are active or what the last input type was used, as available by the UserInputService (which is still not device checking, its input confirmation).
Input is variable and can be changed, unlike MembershipType which is purely a single value. That and there exists multiple input types which can be combined or standalone. In addition to this, you have to account for different input types that can be sent by the client. Even if you think you have it down (like some whack function combining KeyboardEnabled, TouchEnabled or whatever the Gamepad input type is), there’s still other cases you have to account for. To list as many as I can think of:
This in itself is quite a lot to account for. In the chance that any input type doesn’t go according to what your function thinks it knows, players can be teleported without knowledge to an offshoot of the game which the function assumes is the “proper type” of place to be placed at.
Now, given this, I’d also like to raise a secondary point that I’ve mentioned already. What happens then if OP has multiple places? The models above assume that the game is only comprised of one place, a Start Place. The method of teleporting between different types of the place could work (even though I visibly don’t recommend doing such), because it’s one place. You still have to maintain three copies of the exact same place: PC, mobile and Xbox or whatever combination of those you want. Why I don’t agree with this is because what happens if you have more than one place?
- Place1
- Place2
- Place3
- Place4
Now imagine that some kind of logic needs to be consistent amongst it and let’s assume that you’re not making use of any game assets (packages, LinkedSources, whatever). Now, you have to edit all of the above places. But wait! You have different versions of each game depending on the device type someone is using! Now I have to go back and modify all the places. What a disaster it’d be if I made a mistake!
- Lobby (depending on your game, might not even be desirable)
- Place1 (PC)
- Place1 (Mobile)
- Place1 (Xbox)
- Place2 (PC)
- Place2 (Mobile)
- Place2 (Xbox)
Even typing/copy-pasting that was just a little painful.
So on top of having to account for what kind of place someone should be at, you now also have to account for where someone needs to be. Even moreso, you can hit edge cases, such as throttled DataStores (do not forget DatsStore game limits and the six second wait between writes of the same key; if by some chance a player flips between two servers within those 6 seconds and you do not handle your DataStores properly, you’ve now got throttles and potentially lost data on your hands).
To address your second post,
That’s the problem I raised in my first post though. A player should not be kicked for the faults of a developer to properly fix their game or address a fundamental problem. This is fairly inconsiderate and just a band-aid workaround. Eventually it’ll get to a point where a player stops playing for some time or just doesn’t come back at all.
In the case that you have a lobby system as mentioned within the middle part of my response, they cannot join the “place associated with their device”. They need to go through said lobby first. If you have a device chooser in that lobby, then I understand and forgive me for being wrong; but that doesn’t sit well for UX, again. Teleporting is an interruption of experience and players are only patient for a certain amount of time, especially younger audiences.
Why should I need to go through a lobby to select a device just because a developer didn’t want to fix their game? When I join a game, I’m expecting to jump in without my experience being hindered or tampered by teleporting (which refreshes the DataModel for a new one, thus a loading screen), strange barriers, inconsistencies and/or possibly getting kicked for something I had no control over.
Furthermore, refer to my comment on social experiences (UX design).
I agree with your statements. However, mobile users constantly move slower when compared to desktop players across a variety of Roblox games.
This may either be because of the actual touch controls, a game issue or a Roblox issue (if it’s a Roblox issue and you can identify the root, make sure to post a bug report in Platform Feedback).
In terms of the actual touch controls, players are mainly a touch stick in a bottom corner of their screen for movement. Depending on how far the movement stick is dragged, a player will either move at a fraction of their full speed or meet their full speed (which is 16 studs per second). Slow movement is intended behaviour.
In terms of a game issue, I can only think of some kind of inefficient code being run on the client that’s slowing it down, or modified control scripts which need their code reviewed.
Beyond that, I have nothing.
This might be due to lag and that your game doesn’t run well on mobile.
Have you tested your game on your phone?
Many games have a lobby which you have to click play on and then you’re teleported to the actual game such as Booga Booga and SwordBurst 2. Both doing very well as games.
So I don’t think it’s right to rule out an option because you think something won’t fit well with UX.
Apoc Rising 1 also does the same and in it’s (before they started working on apoc 2) it was doing very well.
Again, like I stated in the beginning of my entire response, those games handle it differently, which is why it works in their use cases and not OP’s.
Booga Booga’s main menu is used to display update notes for the game and allow you to select between different maps.
SwordBurst 2’s main menu is just that - a main menu. It holds menus such as the credits menu, products for purchase and to launch into the game once you’ve viewed that information or decide there’s nothing you want to do.
Apocalypse Rising 1’s main menu is used for players to be able to make use of their purchased VIP servers as well as to select maps or servers. Again, it’s literally just that - a main menu. They aren’t doing anything extraneous.
In the use case that OP wants to apply it in, it doesn’t work, which I’ve explained heavily within my response (which is why I’m not going to reiterate it). I did not speak about it from just a UX standpoint. Read my response first please.
Alright, I tried making a teleport service, where it detects the platform then teleports them to another place.
To answer the question you posed, this works. But this is an anti-solution to what I’m trying to say in general. What I intended to have you understand is that what you’ve asked is an XY Problem wherein your solution to input lag is instead to force people to other games based on their device type over trying to fix your game or get an understanding as to why such input lag is happening.
This is not entirely true. There are a few ways to do that. The best one in my opinion is using math.random() along with a constant seed. It will return a different number for different types of devices.
Before you say that it isn’t guaranteed that two different pcs will return the same number for the same seed, I remember my friend @WaverlyCole used that method some time ago and it was able to tell the difference between device types, and had little to no false positives, so it is definetly possible.