When it’s chat in a mobile app.
Yeah, silly statement, but it’s true. Implementing Chat in a mobile or PC app these days is so much more than most people think it is.
Besides the mechanics of “this person has sent that person a message” and then displaying that message in a chat dialog (and there’s implications there, too), there’s a whole host of other issues that come with chat. I thought those following along at home might be interested in some of those issues that aren’t things that are obvious.
- Legal Implications – for example, if your app supports chat, South Korea requires you to remove all records of chat after 24 hours. However, Russia’s laws require you to keep chat around for 3 months. So… what to if you are an international app that has chat?
Well, in most cases, it’s South Korea that loses out. The reality is that you really do need to keep chat around for more than a day, just so if you get complaints about content being sent from one person to another (racist, nazi, suppressing terminology etc), you have it present to be able to examine it and make a judgement.
What actually happens is that most apps detect if the current location where the app is running is South Korea and if so, just removes the Chat button. It’s not elegant, but it gets around the legal requirement. - Right-to-Left languages. Certain languages are right-to-left in terms of reading. Hebrew, Arabic, even certain versions of Japanese – all right to left reading. So, while that’s fine for text since when displaying text, no one cares which direction it goes it, when writing it, that’s another thing entirely. So what to do about this? Well, in a word, nothing. Doing a language localization for something like Hebrew is not going to be cost effective in the first place, since it’s doubtful you’d sell enough to cover the cost, let alone re-writing the textbox input system to handle right-to-left input. In terms of Japanese, there are left to right versions, so just use that. That leaves Arabic.
At this point, we here aren’t committed to an arabic localization just yet – a problem to deal with down the line if/when we’ve made some money. Punt that can down the road! - Emoticons. What a bane those are. While the Unicode consortium have some global definitions, these change and are added to every year. But what’s worse is that different apps have different sets of Emojii’s they support – what’s there in Twitter might not be there in Facebook or Snapchat or Instagram. As a developer, deciding what to support is a nightmare, plus, you need to have these icons built for you by artists so they are available to use in app. It’s extra code to support them, and while engines like Unity do have Emojii packs available for import, the engine changes how to use them and support them. We are still debating if we should attempt to support Emjoii’s out of the box, of leave it for an update post ship.
- Profanity filters. Yes, people will swear and use nasty words in chat. While our backend does support plugging in profanity filters, these are generally 3rd party services, which cost money. And what’s more, they cost money per language. We intend to ship with 9 languages, and expand to another 5 post ship. This means we will be paying for 15 languages, which is not great. But what’s worse is that while we know the language each person is using – so if am using English and you are using French – the profanity filters are set per language, for that language. So basically it means that if you are in an English locale, but you swear in French, the profanity filter won’t pick it up. Which is a hassle. But the alternative is to check for every language possible, and in that situation it’s almost certain some words will be censored that should not, because their spelling in the same in different languages.
Again, we are undecided on implementing this out of the door – another thing to punt down the line. - Allowing multiple people per chat. While our backend allows for Discord like chat rooms, we aren’t implementing those out of the gate – strictly one on one for launch. But… what if we did want this to happen? It’s basically a mess of dialogs you have to produce of rooms, then people populating those rooms, rather than a simple 1 on 1 dialog. But it also opens the door to issues with blocking people, and people not being friends who can see chat and so on.
Discord already has issues with blocking people, people who are not friends seeing chat etc – trying to replicate that inside of an app (which you end up having to do, once you have the concept of friends, blocking friends, and people who aren’t friends communicating with you) is not something that is a fun thing to try and do. - Rich Text / links / Copy n Paste. This is another pandora’s box of code support. Rich Text means Underlining, italics, strikethrough, bold, links, different text sizes and possibly even different fonts and usually colors for foreground/background. Now, supporting that gets a bit complicated – each platform supports it differently and Unity’s support is not cross platform, which makes for issues if you want to support that. Plus, it means you now have to have an input ribbon on your dialogs, so you can allow the user to set all this. And that’s never easy, particularly on mobile. Again, something we aren’t going to deal with out of the box, if at all. We aren’t going to be a fully features chat system, the intent here is to just add a chat ability, but nothing hugely fancy. Support for these kinds of features can take a single engineer weeks per platform, and it’s just not worth the cost; No one is going to pass on buying Lassens Loop because it’s chat system doesn’t support underlining.
You can start to see how this can get a little out of hand fairly quickly when you go down this path – we just want to do as much and as little as makes sense out of the box, allows users to chat to each other, and then move back to the main game and spend our time and resources there.