iPad

Evolution of a design – iPad

Exactly one year ago I began to work on the design of the game, and now I found some interesting pictures about the initial state of the application. I’ll sketch the main evolution steps of the iPad design, and the challenges I (we) faced at that time during implementation.

Designing a project is a challenging and complex process. In fact you are defining a completely new product with all of its aspect: look and feel and interaction. You need to know the type of users, and how they want to use your game. We also want to create a simple, logic, and beautiful design.

From a small project perspective design has two important areas:

  • Functional Design: this incorporates the whole interaction in the application, where the key aspect is to have a logic structure, the buttons should be placed in a logic place, and users should “feel at home” in your application, without the need of teaching them the key components location and how to use your app. Lots of sketches, brainstorming time is needed before writing down an interaction diagram.
  • Graphic Design: A creative artist with experience is needed here. You dream something, and he draws it enhanced. The result will be awesome ( http://www.denes.ro )

When doing the functional design, you need to start from some constraints: device size, how the users are handling the device, where the key elements should be placed. Also, for simplicity, we wanted to have a single game area (all other elements will be presented on small papers, actionsinitiated from the main game area). Let’s detail the process.

Define tappable elements size

First step is to define elements size. We will play on checked paper. But on which size? Because bombs will be dropped by dragging them, they cannot be too small, otherwise will be hard to tap them. Also they cannot be too big, because overall space is limited. After many tries, the final dimension for iPad was defined. A checked paper with these constraints covered very well the available screen area.

Define content of the main area

When adapting a classic paper and pencil game we know, that we need in the main game area (these elements will be always visible):

  • We need two boards (The content of the boards were taken exactly from the version I played on paper)
  • On second board we need an area for dropping bombs (another piece of paper?)
  • Always visible (but not too visible) menu buttons

First mockup was created:

battleship_gui_04

Initial prototype contained two papers for each board on a bamboo wood desk. It was not perfect, we tried with different backgrounds.

battleship_gui_07

Considering this is a childhood game, we wanted to emulate the feeling of playing in a school class. This feeling can be achieved by using papers and notebooks.

battleship_gui_05

Yes! Notebooks. We are around the perfect solution. Something like that:

battleship_gui_06

But wait. Kids usually are playing in their notebook, instead putting piece of papers in a book. By merging these concepts, and putting the menu items on post-it, we finally achieved what we want. To increase the doodle feeling we put a few sketches on the notebook’s corners.

Good. How many dynamic elements we will need? In the original game, only numbers are written in the cell, but looks nicer if there are some elements around numbers. We played with filled and empty bombs. Because were people which liked more the filled bombs meanwhile others vote for empty bombs, both of them are used (can be changed in settings).

Another big challenge was to emphasize the cells when the bombs are dragged. Considering the size of a bomb, when the user thumb is on it, simply is hard to visualize the location where will be dragged. To overcome this problem, hatches are highlighted on the target column/row.
For coloring we need the following colors:

  • current turn (black)
  • previous turns (gray)
  • highlighted state (green)
  • wrong state (red)

And here are the final design result:

battleship_gui_10e

Some polishing, choosing from various wood materials for the background and putting everything together in a real application:

iPadScreenshot1

Advertisements
Categories: Design, General, iPad | Tags: , , | Leave a comment

Scoring Details

Scoring is available for iPhone and iPad, and here are some details, how it is working. Considering the characteristics of the two game modes, the maximum achievable score will be different:

  • Commander Mode: Max 10 points
  • Admiral Mode: Max 20 points + bonus points

In every match, 4 categories (category score contributes to the main score in different ways in the two game modes):

  • Cleverness: max 3 points in Commander mode and max 4 points in Admiral Mode
  • Agility: max 3 points in Commander mode and max 6 points in Admiral Mode
  • Precision: max 2 points in Commander mode and max 5 points in Admiral Mode
  • Ammunition: max 2 points in Commander mode and max 5 points in Admiral Mode

CommanderChart

vs.

admiralchart

For every category a value interval is set, and based on the achieved value, a score is calculated. Let’s consider an example, the easiest. Cleverness. This means, how many units were correctly highlighted. Our units will cover 24 cells on the board, so the maximum number of cells that can be correctly highlighted is 24 (Please note, that the incorrectly highlighted cell will reduce Cleverness value). So user can get Cleverness value between 0 and 24.
Now let’s see the corresponding score calculation. In Commander mode if the user achieves 20 as Cleverness value, he will get the maximum score (3 points for this mode), meanwhile in Admiral mode is enough to highlight correctly 15 cells he will get the maximum score (4 points for this mode). In Admiral Mode if all 24 cells are correctly highlighted, the user will get 2 extra bonus points.

The scoring intervals for the other three categories are:

  • Agility (turns used before victory): If 6/7* or less will result maximum score, 12/11 value for minimum score. In Admiral Mode if the win occurs in turn 6 or before, a bonus point will be given
  • Precision (number of cells covered by bombs – better if lower ): If 50/60* ore less will result maximum score, 70/80 ore more will result in minimum score. In Admiral Mode, if the user used less then 60 bombs, a bonus point will be given.
  • Ammunition (number of bombs available in the last turn): If 6/8* or more will result maximum score, 2/1 or below will result the minimum score. In Admiral Mode, if the user has more than 8 bombs in the last turn, a bonus point will be given.

* First value = Commander mode / Second value = Admiral Mode

Screenshot 2013.12.11 23.02.44 Screenshot 2013.12.11 23.02.52

Categories: General, iPad, iPhone, Scoring | Tags: , , , , , , , , , , , , , | Leave a comment

Scoring

To make addictive a game, a clever scoring mechanism is needed. In battleship like games, usually the successfully won matches count is used. In some cases, the proportion between won/lost matches count is used.

My goal is to  implement something sophisticated. Instead simply counting won/lost matches, we could add a score which depends on how the game went. We can win like a sir, with almost all ships healthy, and all bombs available, or winning can result after pure luck. There are differences … How to catch that?

Which factors should be used and how? In the game, there are already some aspects which could be scored. For example: the users can highlight bombs on positions where they consider, there could be a ship (Yep, of course users which have a little experience, and they have formed the “filter view”, which I mentioned in my earlier post). So let’s take factors which we can use:

  • Highlighted positions: the ships can be located on 24 cells (from 100). If the user highlight correctly all of them – maximum score
  • Used turns: if the user wins the game using fewer turns we could give higher score
  • Remaining bombs: It’s matter, how many bombs could use the user, when the game ends. Maximum value here is 10
  • Thinking time: If the user consume less time in thinking we could add higher score
  • How efficient is the user: how many bombs are on board. Considering we have 100 cells it matters if the user could identify ships using less shots, or the board is almost filled with bombs to locate ships.

Because a few factors are relative, an optimal balancing is needed to get the winner combination. What is your opinion? Which factor is the most important, and how they should combined? What is your opinion?

Categories: iPad, iPhone, Scoring | Leave a comment

be·gin·ning /biˈginiNG/

Everything begun 20 years ago, when my Grandfather revealed a “new” version of the classic Battleship game. A clever one. Instead shooting blindly, we need to think in patterns. As you play more, you will see the board through a “special filter” and you will see where the ships can be. Liked a lot. I contaminated everybody with this game: other family members, friends and classmates. If you get comfortable with the game play it begins to be addictive. 🙂 It is fun…

A year ago I was thinking why to not implement this game for iOS. Sounds challenging. Because the paper on which we played could fit easily on an iPad I decided to write for this device type. After about a year of spare-time development, the game got little by little a nice shape, and it begins to look like an iPad game. It was fantastic. But it deserves a professional design. Quickly talked to a visual artist friend, and in few weeks the design was ready. As a result this year, the version for iPad was published in AppStore. It was time for iPhone. A lot of new challenges comes at this point. How to compress a UI which fits perfectly on an iPad to a small phone. Its not possible. After long thinking I had a cool idea. And few months later, the version for iPhone was released.

The project doesn’t ends here. No. Now is jumping to a new level. I have a lot of ideas in my mind, and if you like this project you can follow how this is evolving. Enjoy. 😉

Categories: General, iPad, iPhone | Tags: , , | Leave a comment

Blog at WordPress.com.

%d bloggers like this: