Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

128 Neutral

About Sly

  • Rank
    Advanced Member
  1. I actually enjoy localization, and one of the reasons for enjoying it is that I avoid Excel spreadsheets at all costs. I've done several games for Microsoft, with up to 19 languages in the one title including Traditional Chinese, Simplified Chinese, Japanese and Korean. We use XML or RESX for localized text, one file per language. Microsoft loc teams specifically state that they do not want Excel spreadsheets for localization purposes. The big advantage is that you can easily diff text-based files in source control to see what changed. Spreadsheets are usually binary files that do not diff well, if at all. Our games use the XML or RESX files directly, so there is no copy/paste involved at any stage in the process. If you are copy/pasting text as part of the localization process, you're doing it wrong. That poses a large risk in copying something wrong (so easy to do from prior experience), and because the text is in a language that you usually cannot understand it is very difficult to see which strings you messed up. It is useful to include a short description of the string in the file to put it into context for the translator. This can help them understand how the text is used which may change how they translate it. It may be tempting to re-use the same strings for different purposes in your game, e.g. a screen title and for a button. Don't. Text that may be the same in your language for different purposes may be two or three different strings in other language, depending on the context of use. Provide a fall-back path. If you are supporting French, support the neutral culture "fr". Some strings may be different in Canada, so provide the Canadian-specific strings in a "fr-CA" culture. Strings not in this specific culture should fall back to using the neutral "fr" culture.
  2. We've used AngelCode's BMFont for several commercial titles on all modern platforms. It's safe to say we think it's damn good. Andreas has done very well.
  3. Just found proof for your argument. Recently released on the AppStore was iSplash, an "innovative app counts your poo splashes when you do your stuff, using sound recognition technology. It saves your high score and saves your recorded poo session so you can play it to your friends later." Or just do a search on the AppStore for "poo". Plenty of ammunition for your case.
  4. "...which is why stuff like classic game system emulators aren't available on an iPhone even if they don't use any "third party libraries"." While mostly true, it's not 100% true. After a few attempts, the C64 emulator is now available. "MTV Presents: Intellivision" was recently released for iPhone, along with "VH1 Classic Presents: Intellivision for iPad". You cannot load your own ROMs or disk images into these. You can only purchase games through the app itself.
  5. Sly


    Having used CodeWarrior extensively to develop PS2, Gamecube and Wii games, I wholeheartedly agree that it is effing useless. Not just in its optimisation attempts, but also in the IDE, user interface, automation, source control integration, and general usability.
  6. Sly

    Zip Wars!

    Several years ago, we moved from PowerArchiver to WinZip because PowerArchiver used signed integers for the file size whereas WinZip used unsigned integers or 64-bit integers. We hit this bug in PowerArchiver when our game builds exceeded 2GB. No idea if PowerArchiver have fixed that bug yet.
  7. Sly

    Weekly Sitrep

    If you make it to Australia, don't bring the knives. It's illegal to carry any concealed knives.
  8. Sly

    Havok Physics (Part 3) & Video Link

    Heya. Nice work on the physics engine integration. Do you have static collision on the trees? We're doing a multi-platform console title that has a large heightfield landscape with lots of trees. We're currently trying to decide between PhysX and Bullet (the only two choices I've been given). I've found that I have to create/destroy the static collision for trees on the fly for those trees that are close to the player only in order to keep physics CPU usage down to a minimum. In this case (multi-platform console title), Havok is unfortunately a very expensive proposition.
  9. Sly

    The Way We've Always Done It

    An interesting story, but it's just a story. http://www.snopes.com/history/american/gauge.asp Additionally, in Australia, different states still have different rail gauges.
  10. Sly

    Weekly Sitrep

    No plans for GCAP? Come on down to see the Aussie game development scene.
  11. Sly

    ObjectTable Hacks in SlimDX

    Quote:Original post by Promit It's also apparently become fashionable to start posting things a day early, which is bull. Go to hell, TechARP. Go. To. Hell. The rest of the world thinks its annoying that Americans post April Fools things a day late. Keep in mind that America comes at the end of world's daily cycle. Here in Australia we are already at work the next day before you guys finish work the previous day.
  12. Sly

    So damn slow!

    You're doing a great job. Being at GDC myself (great to meet you there!) I know just how much stuff they cram into those few days.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!