In three decades of programming, I’ve never doubted ASCII. When faced with a mysterious bug, faithful single-byte ASCII has never betrayed my trust in its character. But variable-byte Unicode, well, that is a different story.
When localizing software strange and twisted things happen mysteriously. After the investigation, the actual cause is never exactly Unicode itself. No, it is too internationally respectable for that. Yet, frequently standing nearby in the dark shadows, Unicode is there, lurking time and again. What is this treachery?
The Treachery of Reliable Search
Consider using Regular Expressions to search a data set of artists for “René” to find the René Magritte.
The last character in René is an e-acute. Admittedly, changing the “é”character to an plain “e” may be tempting (Rene), but this approach will not do much for the tens of thousands of non-ASCII characters needed for localization. There are very good reasons why Unicode exists as an international standard. And it is somewhat disrespectful to René to intentionally misspell his name.
The four byte Unicode (UTF-32) representation of e-acute is u00E9. But there is also a two byte Unicode (UTF-16) representation of e-acute is u0301. This means that RegEx can miss matching “René” with “René”, if the e-acute uses these two different endings.
If the dataset has HTML encodings, it gets even more fun. The e-acute could be “é”, or the HTML encoded hex value for the UTF-32, or the HTML encoded decimal value for UTF-32. Add to this the capitalized e-acute: É. That gives ten variations of the same character to match.
One would like to think that foundational tools, such as RegEx, automatically handle this or there is a simple option to turn it on and the problem goes away. Unfortunately, that is not the case, at least not yet.
So beware of normally reliable search utilities to find Unicode characters.
The Treachery of Reliable Tools
Microsoft Excel is a great tools for localization. Put a key in the first column, the phrase to be translated in the second column, and give the third column to the translator for the target language phrase. Excel supports Unicode, so no problem, right? Well…not exactly.
To demonstrate the first problem with Excel and its support for Unicode, export a CSV (Comma Separated Values) file of Asian Unicode from Excel and then opening it back up in Excel. It converts the characters into little boxes to indicate your device doesn’t have a font to display the text. These boxes are known as tofu*.
Google appears to be eating Microsoft’s lunch (or at least its tofu) when it comes to successfully handling Unicode. A workaround is to copy the Excel worksheet and paste it into a Google Docs sheet, then export it from there to CSV. No tofu when imported into Unity3D and NGUI.
The second problem I encountered was with Chinese Unicode in Excel and quotes. The translator’s pipeline added a strange quote at the beginning and end of phrase, invisible to Excel. When pasted into Google Translate, the quote is visible (another i18n point for Google).
Both Excel and Word could not find the character in search (perhaps related to #1 above).When the translated phrase was imported into Unity3D and NGUI, all translated strings were broken.
So beware of normally reliable tools to translate Unicode.
* Note: Excel 2011 displays Korean in tofu on my Mac. These issues may have been fixed in a later version of Excel. But Unicode has been around since 1991. Just saying.
It is amazing how different the same textures and 3D models can look depending on how the scene is lit. Lighting can be used in game design to guide the player to the goal, to signal danger, and to hide enemies so they attack out of shadows.
Setting a light and changing its color and intensity is easy. However, to keep a mobile game from lagging, lights are like salt added to a meal. Too much and it becomes inedible (or in a game unplayable).
A design goal of Ratkey has been to motivate the player by showing glimpses of lower levels level from the current plane they are playing on. This also makes the current level more interesting by giving a sense of height and depth beyond the current walls.
Lanterns and torches are have been key elements as they give a bright focus for the scene and reason for why there is light there. Both the lanterns and torches are excellently crafted 3D models and are interesting to view close-up. As a result, they serve multiple points of interest to the player from a variety of distances. The player’s curiosity is satisfied as they get closer to lantern and torches.
Mazes are among the of oldest types of game elements, going back thousands of years. The ancient Greek story of Icarus flying out the maze built to hold the Minotaur inspired my first paper-based game levels of Dungeons and Dragons decades ago.
While building 3D games, there are a couple of modeling challenges that are in tension. Solving one problem can cause the other problem to occur. Recalls Icarus’ father telling him not to fly to close to the sea or to the sun.
The first challenge is collision detection. Collision detection can be a little tricky in 3D game maze construction. It is important to get the pieces to line up precisely. Too much overlap or too large of gap can allow the player to slip through a crack, even if the player’s collider shouldn’t fit through. Because the player can control their character to intersect the walls from a variety of angles, it is easy to create places where the player will rapidly jitter and then suddenly pop through the crack.
The second challenge with maze construction for 3D games is to avoid have two surfaces in the exactly the same space, resulting in rendering flicker between those surfaces. A difference of 0.01 is enough in X, Y, and/or Z to keep solid walls looking solid.
To help quickly build mazes in Unity3D, there is some great software available in the Unity Asset Store named QMaze, created by Smurov Sergey.
Set-up to get the basic walls in order took me several weeks, but once in place large mazes can be generated in a few seconds. QMaze is a powerful time saver.
Most of the mazes in Ratkey are under 20×20 cells. Anything bigger and the player can get hopelessly lost. Just to see what a crazy big maze might look like, I generated a 50×100 cell maze using QMaze. The images below are a close-up and top-down view.
More information about QMaze is available in the Unity Asset Store at https://www.assetstore.unity3d.com/en/#!/content/30600.