• Register

The well-known guessing game – now in a challenging flavor. If you want more strategy instead luck, you will like this.

Post news Report RSS Evolution of a design - Part 1

In a few posts I'll present the main challenges during the design phase of my project. You will find also the initial prototypes and how this evolved, and finally all the pieces of the puzzle were put together in the final design.

Posted by on

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 ( 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

You can find more about the project:
Battleshiptacticalgame.wordpress.com

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: