Ranger Sheck's Blog

Browser-Based Game designers, take note from some of the web-based app designers: the term “Look and Feel” means more than you think! Win back some of those players you frightened away by seeing your game through their eyes and giving them some familiarity to start with.

Which came first?

In the web-based application development communities, once in a while you see this kind of chicken and egg argument pop up. The question is, which design comes first, code or interface? A lot of solo developers like myself go right for the code. After all, without a solid code design plan, with data models and business functionality, the application is useless. Google didn’t become the most popular search engine because it looked pretty; it works well, that’s how it became popular.

Your graphical people, of course, will go the other way. Google is the exception to the norm, they’ll tell you. Especially in today’s Web Too Oh world, first impression is key, because people can leave a website just as quickly as they arrive.

Of course, it’s more than just visual aesthetics. As websites move deeper into that uncanny valley and look more and more like real-deal applications, designers and developers must take into consideration their site’s interact-ability. The key questions are: What does it look like from the client’s perspective? What does it feel like to the client?

So, I switched sides. Yes, I know – code base is very important. Data structure is very important. However, let’s be frank – that’s the easy stuff. That’s the logical stuff. The hard part – the thing that sets you apart from everyone else (or makes you look the same) – is the interface. Not to mention, when you start your design from the interface side, you’ll find some things you would have missed. You think a lot harder about what it’s like to be in your client’s shoes.

It talks like a duck, but walks like a Sasquatch

Familiarity is a design concept that becomes important here. The more your web-based application acts like real application, the more your clients are going to treat it like one. When they begin to recognize certain interface elements, they will start attempting to use other elements, like shortcuts, or they will start looking for familiar context menus, like the kind you get from right-clicking in a normal application. The moment they hit CTRL-S expecting to save a record or a document and it doesn’t work, their trust in your site is broken. Their browser’s implementation for that key combo fires off and they are reminded once again that it’s not really a full blown application, it’s just a web site.

With browser-based games, the same problem exists. After all, computer games are nothing but entertainment applications. As javascript, Flash, and other technologies allow web developers to create browser games that act more and more like full blown computer games (or even console or arcade games), we’re running into that familiarity snag, but it’s two-fold. Not only will your players be looking for familiar interface elements, they will be looking for familiar gameplay elements. Games are a lot more varied than business applications in both these respects, so it’s going to divide your client-base into two factions: (A) people that play tons of games and realize that every time they pick up a new game, they may have to learn some new gameplay concepts and they may have to master a new interface and (B) people that play only a few games and only really like something new when it closely resembles something they’ve seen before; if it doesn’t, then it better be something that’s not hard to learn or get the hang of.

The Lost Players

The big problem is, those people in that second group – that’s the majority, and those people will walk away the fastest. I’ve seen people on dev boards say time and time again, “well, if it doesn’t look great but it’s fun to play, I’ll enjoy it”. That’s probably true for a lot of people, even people in group B – the problem is, most of them are leaving before they get a chance to find out that a game is “fun to play”. They’re not going to take the time to leave you feedback either and let you know what turned them off.

Let’s look at some possible reasons for new players to give up on your game within five minutes:

• They got lost. Right from the beginning, they didn’t know what to do.
• They thought they were getting into a game they would already know how to play (they were wrong).
• They thought they were playing a game that would be easy because it’s a game on the web (they were wrong).
• They saw half-assed graphics and figured the game was unfinished and not worth their time.
• They found little on-screen help and a separate manual consisting of tons of pages that were hard to read and probably uninteresting.

Some of these people, they’re on their coffee breaks, they’re killing time, they’ve got a meeting in 20 minutes; they’re looking to web-based games as a spend amounts of time in varied increments. Maybe they want to kill 10 minutes, maybe they want to kill an hour or two. If you hit them over the head with some interface that looks and acts like nothing they’ve ever seen before, and a game that plays like nothing they’ve seen before, they’re going to get frustrated and look for something easier.

The Balancing Act

Obviously, we don’t want to make cookie cutter games that all look and feel the same way. I’m suggesting that when you can create familiarity, you create comfort, and you alleviate frustration. When you can’t make an element familiar, whether it’s an interface element or a gameplay element, then make sure it’s easy. Easy to use, easy to understand – look at it from the perspective of someone else (someone who’s not a developer). The key is to find that balance between the unique and the familiar.

Many games pride themselves on their depth. Too much complexity translates to a bunch of white noise, static, to the first time player. When you want to add complexity, do it in bite-sized increments – open up features one at a time to players after they get comfortable with the basics. During development, only add new features when you’re sure the simpler parts are solid. Honestly, it’s better to have a few concepts that work really well and look really good than a whole box of unfinished pieces (with lots of “potential”).

And definitely don’t hit your players with all the information available up front, let them discover some things on their own – it’s part of the reward of playing a Persistent BBG.