previous: Operation Survival - humanities last standprevious: Book review: ActionScript for Multiplayer Games an...previous: Washing spoonsprevious: "The Killer Elite" in Rolling Stone Magazineprevious: Qualitätsjournalismusprevious: Autofahrer sind asoziale Psychopathenprevious: impressive photographsprevious: It wasn't me...previous: id software is at it againprevious: Infopr0n

Operation Survival - design guidelines

One of my goals for Operation Survival is to make the barriers to entry as low as possible. This means a couple of things:

With such an ambitious set of goals it is obviously impossible to fulfill them all equally well. There will always be trade-offs and compromises and lots of the issues are a matter of personal opinion to begin with. Nevertheless, I think it's a good idea to state some guiding principles when fleshing out the design further, so that's what I'm trying to do here.

Considering all of the above and the fact that the underlying game design is fundamentally multiplayer I believe a browser based solution is the only way to go. Browsers are ubiquitous, the back button and links the universal user interface primitives everyone on the planet understands by now. Browsers run everywhere. Everyone that uses one is already connected to the Internet and thus able to play multiplayer. Browsers shoulder the burden of guaranteeing security. Everything that runs in a browser window is assumed to be safe while downloads are seen with skepticism by even the most naive of users.

So a browser game it is.

I'll post my thoughts on the other points soon. In the meantime: What do you think about those axioms? Anything missing? How would you weight the priorities?

posted by Sören Meyer-Eppler at Monday, January 25, 2010    


4 Comments:

Blogger Jutta said...

I see a bit of a problem in the "fully localized" approach. Even though I appreciate that not everyone is comfortable to communicate in English, with a multiplayer-online game chances are that players from different countries and cultural backgrounds will run into each other and have to communicate. Unless they both share a native language, they will probably end up using English anyway. But if the user interface is localized, it will make their communication more difficult.

"Just pick up the Bewegungsmelder and tell me what you see!"
"The what?"
"You know, the ... eh ... monitor thing? Animation alarm?"
"Oh, you mean the motion tracker?"
"Yeah, I guess"

Do you understand what I'm getting at? As long as players only communicate with the game, localization works. If they have to communicate with each other, localization makes things more complicated for them, because they will have to translate game-specific terms too understand each other.

Not saying you shouldn't localize, but a point that should be considered.

Blogger BuschnicK said...

Absolutely. And I'm the first to rile against localizations and require the whole world to speak "my" language. I frickin hate localizing stuff from a developers point of view and often enough from a user's point of view as well. However, I do think it is unavoidable.

Chat won't work, but I think no one expects a game to magically bridge the language barrier completely. I can see two mitigations:
1) use regional servers and multiple game instances. Requires a critical mass of users and fragments your community.
2) use "chat trees". Dunno what the proper expression here is but instead of using free style chat you could (additionally?) offer chatting via emotes and canned phrases which can be chosen from dialog trees. That would "automagically" translate to each user's native tongue.

Blogger Jutta said...

I doubt that you can bond and create a sense of community by using a chat tree. Maybe that's the roleplayer in me talking.

The mean thing about localization is, that it is something you don't want to think about much in the beginning, since it is something that just gets in the way and makes GUI design and user interface development a pain in the ass and you don't really need it until much later. But if you don't have a clear concept for it from day one, you will never be able to get it right. Maybe we should just use Esperanto ;)

If the players fly to missions all over the earth (as in the original XCom series), it would also be very neat to use the language of the country they are currently in for all "in game" stuff ... any scripted NPC dialogue, labels on found items etc. Would make it much more realistic and if things are not too complex and iconic enough, players should still be able to pick up what's going on, even if it is in Russian, Chinese or French.

Or would it maybe be possible to keep the thing completely language free and only use symbols? Then it is completely up to the players what language they use in a chat or VoIP system, but the complete GUI could probably just use icons. Does not work for the research/backstory part, though, I'm afraid.

Blogger BuschnicK said...

My intention is to prepare for eventual localization by using unicode strings, GUI elements that properly resize to their content and externalized resources. Having to support lots of languages is a good problem to have because it means you have a sufficiently sized player base to create such demand. I'll worry about the details once I get to that point ;-)

In the meantime I can only provide English and/or German, because that's what I know. There will probably also be natural separation because players will flock to the closest server (if there'll ever be more than one ;-) ).

I like the idea of having in-game characters speak their local language. Since that'll probably be background flair civilians anyways it's not important the player understands every word...

Post a Comment

previous: Operation Survival - humanities last standprevious: Book review: ActionScript for Multiplayer Games an...previous: Washing spoonsprevious: "The Killer Elite" in Rolling Stone Magazineprevious: Qualitätsjournalismusprevious: Autofahrer sind asoziale Psychopathenprevious: impressive photographsprevious: It wasn't me...previous: id software is at it againprevious: Infopr0n