Aug
2018

DevBlog

Patch 1.2 is out! Mac and Linux versions are finally available.

by picaresque

Ahoy there!

After a long beta test phase, patch 1.2 is officially out.
The biggest change introduced by this update is the support for Mac OS and Linux. In addition to that, major updates included in this patch are a complete rework of the scenes loading system, improving loading time by 75%, and the introduction of a new background image for each city, giving them a unique feeling.

Here is the list of changes contained in this update:

Features:

Implemented compatibility with Mac and Linux
Added possibility to toggle controller support
Implemented customization of controller key mappings
Added difficulty panel in Character Creation

Changes:

Improved loading times
Added a new background image to each city in order to have them unique.

Fixes:

Fixed “Quest Completed” window appearing during combat and blocking the game, during Kahekili and Bass final quest
Fixed Game Over not appearing when losing in Main Quest 9
Fixed block on loading a game from the same scene
Fixed seadog save files not appearing in the load screen
Fixed graphical glitches on the first few frames after loading
Minor fixes in event tooltips
Fixed quest text of a non-whaling area discovered
Fixed wrong “Crew healed” notification when entering the port, when the crew had only maimed men
Fixed music overlapping after the tutorial

5

Apr
2018

DevBlog

Mac and Linux versions are now in beta, more to come.

by Mex

Ahoy there!

We keep working hard to satisfy the requests of all the people who bought Nantucket (thank you very much for the support) and the ones of people that would like to do it. Mac and Linux versions of the game are now in beta and we are looking for testers.

In case you are interested, please write us a mail at beta@picaresquestudio.com specifying:

– Hardware specifications
– Operating System name and version
– Steam username and account page link

If you already own the game, and you have a machine with Mac/Linux OS, you can try the beta for those versions by clicking with the right mouse button on Nantucket in your Steam library, select “Properties”, pick the “Betas” tab and select “Beta”.

Meanwhile, we are working on additional features. Some of them will be available to you all, while others will be part of a new DLC coming in the next months, adding a new game mode.

Here a glimpse to the new cities images we are working on to increase their variety:

Keep following us on our social pages for more updates about the development of Nantucket.

See you soon!

13

Mar
2017

Code

Choosing the fastest route in Nantucket – 2D polygonal pathfinding in Unity

by DanieleBubb

In the last few weeks we reworked the pathfinding system in the world map scene. In this article we are going to explain how we implemented the new pathfinding system, and what are the improvements we got from it.

The old, tile-based pathfinding

As many other devs do, we used A-Star algorithm to traverse the navigation graph and pick the fastest route between two points in the map.

The navigation graph was generated using an offline process which defined nodes and edges following these rules:

The world map was split in squared tiles
We added a node in the graph for each traversable tile
We added an edge between two adjacent nodes

The graph looked like this, with the nodes represented by blue circles and edges by red lines:

The issues

We analyzed the problems we had with this system and came up with the following:

Too many nodes and edges, which led to poor performances
Rough choice of routes along the coast

The solution

To solve those issues we wanted to find a way to generate the graph differently, in order to:

Reduce the number of nodes and edges, especially in open areas, to improve performance
Move the nodes closer to obstacles, to achieve smoother routes around corners

The graph generation

We ended up changing the rules of generation of nodes and edges in the navigation graph. We defined obstacles as polygons and defined the new graph with the following rules:

Add a node per convex vertex of the obstacle polygon
Add an edge per couple of nodes visible in line of sight

Inspired by this article we generated the obstacle polygons by following these steps:

1. Draw the obstacles using the Graphics editor of your choice

2. Insert the obstacle image in a GameObject and add a PolygonCollider2D component to automatically define the outline.

3. Generate nodes and edges of the pathfinding graph

Since our obstacles are static the process is done offline, and data stored in a ScriptableObject.

The path calculation

When a route between given source and destination points has to be calculated the only computations left to be performed at runtime are:

Add a node on the position of the source point
Add edges from source node to every visible node in line of sight
Repeat steps 1 and 2 for the destination point
Calculate the best path using A-Start algorithm from source to destination node

Here is the pathfinding in action, you can notice how the graph changes when moving source and destination points:

The optimization

In order to improve the performance and let the pathfinding not impact the framerate, we implemented few optimization techniques.

We added a visibility cache, we used the tiles we had in the previous implementation, and stored all the visible nodes in line of sight for each tile. This let us save computation time when adding the edges between source and destination nodes, instead of performing a lot of expensive line of sight checks, we just use the nodes cached in the tile the node is in.

We reduced the number of edges by removing all edges between nodes of different polygons, except for special nodes marked by hand. We won’t go in detail about this, since is strictly tied to the nature of the map, and we didn’t find a way to automatically choose special nodes.

We then moved all the runtime part of the algorithm in a different thread to further save computation time.

The final result

Despite having hundreds of nodes and edges, the overhead is minimal and improved ~100 times over the previous implementation. It runs smoothly on all the machines we tested it in, and we are now able to run it every frame to show the potential route the player can currently set.

Here is the final result in Nantucket:

Hope you enjoyed this technical article, I thought it would be useful to share it since I didn’t see anything like that implemented in Unity.

Nantucket is in the late stages of development, we are putting the final content and internal testing is giving us useful feedback on game usability and balance. We’ll soon show more gameplay in a video on our Youtube Channel. Meanwhile don’t forget to follow us on Twitter and Facebook.

16

Apr
2016

DevBlog

UI Combat: Let’s fight!

by Capt_Eatbones

“

Drink, ye harpooneers! drink and swear, ye men that man the deathful whaleboat’s bow…

”

This will be the last article about the combat and before we start, I’d like to point out a couple of aspects of Nantucket. As you probably know, one main aspect of the game style is that is made of paper. It’s an experience played onto the Captain’s table, in his cabin and sometime is played in a harbor. Even so, the harbor is an illustration drawn on paper too.
When we thought of a combat style for this game, it came natural to us moving towards something mostly related with a table and a bunch of pieces of paper: a card game.
This combat is not a Trading Card Game. We’ve chosen a card style due to the context of this game: ship, crew, sailing. And, of course, we like playing card games too. Nantucket, per se, is not a card game, but includes a little card game played during the combat. Now, let’s move on with the article main subject.

Today, we are going to have a look at the actual combat phase UI. I want to share with you a first mock-up (this is a frame of an animated one):

Combat 3.0 – Animated Mock-up (Still)

In the picture above you can see a still of the animated mock-up we prepared before starting the implementation. We needed this to define the timings of the overall combat experience. If you have red the previous articles (if you don’t, you can catch up here and here) you already know how the combat has evolved and how the previous Deployment phase works. Once you start the real fight, you have to roll the combat dices of the crew members you have in your whaleboats and decide which command is the best to win against your opponent.

Combat 3.0 – Dice roll and Command choice

As you can see, these images are from an early mock-up and the dices faces are not final. The main concept, though, is there: according to the crew members you’ve placed onto the whaleboats you’ll have several dices combinations. Each dice face, when rolled, will unveil a specific command. Once the the dices have been rolled the player can chose which command he/she prefers. When the command needs a target, ad arrow will appear to point the target the player wants.

Let’s have a look at the design of the crew card:

Combat 3.0 – Crew cards

Above you can have a look at the final version of the cards. I’ll show you each element from the top to the bottom:

Combat states icons: Bleeding, Stunned, Poisoned, Blind and Surrender. These icons will appear according to the combat development. Except for the Surrender state, all the others are inflicted be the opponent. This label will appear and disappear according to the presence of states.
Crew member information: Health, Name, Class and Level. In this case, I chose to use the heart icon to be sure everyone understands the meaning of it. Previously, we used a red/rope health bar but still it was not clear enough.
Crew member picture: this is the same used in the whole game, whenever we access to the information of this man.
Combat dice.
Combat dice switcher.

The hearth of this card is the combat dice. In the above image, you’re looking at the Captain’s card which is special. Since the Captain has all 4 working skills (Hunting, Sailing, Science and Crafting) he will have 4 different combat dices: one per working skill. According to the evolution of the working skill the related combat dice will evolve too. The working skill faces are 3, no more. The remaining 3 faces are used in this way: 2 for specific skills in use and 1 for specific objects in use. This special dice faces will enable special combat commands.

During combat you can use the Dice Switcher to decide which working skill of your avatar you prefer to use. Simple crew members will only have 2 Dice Switchers: the one related to the working skill they are specialized on and a generic one (related to the Cabin Boy half-class).
Before the roll of the dices the player can chose which combat dice to use for the roll. This way, you can chose the best strategy combination to use each turn. Of course, its crucial that you placed the right men during the Deployment phase.

Combat 3.0 – Creature Cards

The Creatures card is a little simpler than the Crew one. First of all, there are 2 different cards: Standard and Special. Above, on the left, you can see the Standard card style while, on the right, you have the Special card style. As you can see, Moby Dick will be a Special card because its class is Legendary (and because it’s Moby Dick, I’d say!). From the left to the right, these are the elements of the Creature card:

Creature type label: here you have the name of the species and the color of the card. The color is important because it lets you know which color will be its attack cards.
Action/Instant card slot: here the creature can play two different type of cards. The effect of these cards is used for the creature itself.
Creature picture: below the Action/Instant slot.
Creature information: Health, special creature’s Name (or the species name instead), Category, Special ability (or the species shape instead) .
Combat states icons: here will appear the same icons used for the Crew card, except for the Surrender.

Combat 3.0 – Mock-up

Remember that not always defeat the enemy all the enemies will be asked. The Victory conditions card, in the top left, tells the player the requirements to the success. Moreover, in the top right, there is the Random Combat Condition card that will be drawn each turn and will define the combat conditions each time (bonus, malus, etc.).

And what about the Crew VS Crew combat? Here you have it!

Combat 3.0 – Crew VS Crew mock-up

Here the combat will work the same, the only difference is the there will be less crew member on your side. Moreover, you will be able to see the combat dices of your opponents. The only real difference is in the opponent card: the colored label is placed at the bottom of the card. This way you have a reference to who is attacking who.

Well, I don’t want to spoil too much of this since we will have specific videos about the combat in our “Devs Play” series (watch it here).

Hope you’ve enjoyed like I did in sharing this with you.

Keep tuned and Godspeed, as always, from your Capt_Eatbones!

9

Apr
2016

DevBlog

UI Combat: Deployment

by Capt_Eatbones

Arrr! Your Captain summons you!

Today I want to talk a little more about the combat’s UI: the Deployment. During this phase, the player is asked to spend a little time, before the actual combat, to decide who will participate in the fight. This is a crucial moment since part of the strategy and the outcome will depend on the choices made here.

This part of the combat has always been in the design so it’s something that’s always been there, even in previous combat iterations:

Combat 1.0 – Deployment

The main idea is let the player choose from the list of all the crew members on your ship. Every crew member has his own skills, traits and states. Several skills are related to the combat so, for example, according to whom will be assigned to the fight the player will have different options during the next phase: the actual combat.
This list has the goal to show all the crew member information related to his possible use in battle. As you can see, in the picture above, a description of the skills useful in combat is show on the right of the crew label in the list. This layout has not changed too much during the next iterations. Actually, let’s move on the next iteration and see what changes have been made (if you haven’t red the previous article about, you can do it here):

Combat 2.0 – Deployment

Now, as you can see we have a card deck. More specifically, the Attack cards deck. In the previous iteration we placed the crew list in the middle of the combat board. This time we thought to place it right on top of the selected whaleboat to make crystal clear to which boat the crew member would be assigned. The layout is not that different, except the crew member details on the left of the list. This time the player is able to have a better look to the selected crew information: Traits, Skills, Objects and, of course, the combat dice. The interesting thing of this solution is that while you’re assigning crew members to the whaleboat, you see changing the available cards on the deck. This underlines even more the importance of this moment of decision making.
We are ready to move to the last iteration to see where our final stop will be (sure it will be the last? :D)

Combat 3.0 – Deployment

While in the previous iterations the crew assignment was handled only through drag&drop, this time we introduced buttons. In our opinion not everyone finds the drag&drop the easiest solution nor the most precise one. Moreover it’s not always clear where to drag.
Here the crew list has been flipped horizontally. On the left is the list while on the right there is the preview of the crew card. This card contains several elements:

Name of the Crew member
Health points
Class and Level
Current Combat dice
Combat dices switcher

I won’t explain all the functionalities of the combat since there will be specific videos about this in our Devs Play series (watch the episodes here). However, I want to point out that in this version the combat dice is in full sight. Previously there was a dice icon that would open a tool-tip with the dice faces information. Now the player can review the combat dice at any moment.
Well, it’s all good but, are we going to fight only at sea? Of course not! As we told you in other occasions, there is also the combat between crews, on the ship deck. Here is a glimpse of what the deployment in Crew vs Crew would look like:

Combat 3.0 – Deployment: Crew VS Crew

The crew list stays the same. It will just take less time to deploy our men since there will be less of them.

That’s it for today, we’ll be back with the last article about the UI of the actual combat phase.

I hope that you’ve enjoyed and godspeed!

26

Mar
2016

DevBlog

UI Iteration #X: Combat

by Capt_Eatbones

Ahoy! Capt_Eatbones is here!

Today I’m going to tell you the story about the combat UI design for our upcoming title Nantucket.

Why a story? Well, it deserves this introduction because it’s one of the core mechanics we’ve been struggling more on, iterating a lot… Of course, we knew since the beginning of the production that we wanted a well-thought combat. For this reason we kept pushing on it. In this article, I’ll guide you through the iterations we went through for the combat UI.

MOCK-UPS…MOCK-UPS EVERYWHERE!

Combat 1.0 – Vector Mock-up

We started again with a functional model and then worked on it. The above picture shows the starting mock-up for version 1.0. As you probably guessed, we love strategy games and we are big fans of tabletop and card games too. The main idea for the combat scenario was to represent it as a more detailed map on top of the navigation map. We imagined the combat as a card game and this idea is still our goal.
On top of the sea combat area, are placed the two sets of cards: Whaleboats (left) and Creatures/Canoes (right). This layout applies also to Crew VS Crew, when the combat takes place on the ship’s deck. In the middle area, you find the Attacking and Defending slots where the action cards are played. As you can see, there is a big arrow path in the middle area: it’s meant to declare who is attacking who. In this combat version, all cards are placed and then played all together in sequence. This meant that there could be 3 overlapping big arrow paths, generating confusion. To avoid this, we decided to use a color code to identify who was doing what. Here you have the final result for the main cards (Whaleboat and Creature):

CombatCardsIllustrations

Follows the final mock-up:

Combat 1.0 – Final Mock-up

Here you can have a look at the final composition and layout. The action cards are placed in the middle area and the colored border tells you to whom they belong. After this step, we implemented this version in the game. We asked for feedback, as usual, and we were told that too much information was unclear during the clash of the action cards:

What really means the dice value?
How is calculated the damage value?
Who won?

To answer these questions, we re-worked a little the moment of the execution of the action cards placement and we got to this solution:

Multiple action cards could be used to attack a single Whaleboat/Creature card. In this combat version, there are attack and defense dice faces. One defense face can only contrast one attack face, so in case of a multiple attacks the other attacks pass right through the defense. By using these dark arrow we hoped to better clarify these relations. Moreover, the middle numbers are thought to tell the final result of each card confrontation.
Well, after Greenlight and, especially, after the feedback received during the Gamelab 2015 (read about it HERE), we decided to re-think the whole design, both the mechanics and the UI. One thing was clear: too much information in too little space. We had to learn from other games and (re)start simple.
The first step towards version 2.0 was a simple test. We tried to expand the action cards of each main card at the bottom, a sort of action deck:

Combat 1.1 – Vector Mock-up (Action deck)

This solution is something that several people asked because all the info related to the possible actions where visible only through the use of tool-tips. If you don’t know that a tool-tip exists then you’re missing valuable information. Nonetheless, we didn’t like the result: the action deck is hiding part of the combat area. The answer to this was “let’s re-think it all” (more or less).

Combat 2.0 – Vector Mock-up

Version 2.0 introduces a new action card concept: Attack, Support and Inspiration cards. This time each card has a single clear effect but it’s applied only if the dice rolls meet the card requirements. Looking at the above picture, you see that the main cards layout is similar to the version 1.0. Even so, now there is a dedicated space, below the combat map, where the action cards deck is shown.
The main concept is quite interesting since it’s based on a bet on what the dice roll result will be. First you choose the action cards you want to use and then you roll the dices and hope for the desired result to come.

Combat 2.1 – Vector Mock-up

We tried also a horizontal layout, a little asymmetrical. We liked it more due to the better space reserved to Victory and Sea conditions. Moreover, it reduces the space used by the action cards decks. So, thumbs up!

CombatCardsStates

CombatViewDeployment_States
Combat 2.1 – Action cards and Deck Mock-ups

In the picture above you can see the style of the action cards, according to the different states, and the new deck. Then we put together the final mock-up for this second version of the combat:

Combat 2.1 – Final Mock-up

Now, we loved the idea of betting on the dice rolls (surely from a drunken sailor point of view!). However, playing it revealed several drawbacks of this concept. Two of them are the most annoying:

Too many missed turns.
The more advanced the action cards you can use are, the less chance of success you have using them.

You know, even if you have experience as a player or even as a developer, you always make mistakes. The “secret” is to find a solution to those mistakes. That’s really it…but it really isn’t that simple ^^ Nevertheless, we were in a better position than before. This version was a better one compared with the other but still we had a way to go.

After the Christmas holidays we started fresh and re-worked (again) the combat concept. Version 3.0 is the one we introduced to you a couple of weeks ago. Here you have it in all its splendor:

CombatView_v3

Combat 3.0 – Final Mock-up

For today we stop here. We’ll talk about version 3.0 and all its UI more in depth in the next UI articles. I hope you enjoyed!

Keep tuned and don’t miss our Devs Play video series!

Capt_Eatbones

19

Mar
2016

DevBlog

Follow your winds

by Mex

“

Voiceless it cries,
Wingless flutters,
Toothless bites,
Mouthless mutters.

J.R.R. Tolkien

”

Ahoy there!

I hope to find you all well. Here I am with a new feature presentation for our upcoming title Nantucket. Today I’m going to write about something we are currently working: winds.

Nantucket is set in the XIX century, so during the Golden Age of the Age of Sail, where the efficiency of sailing vessels was at its peak and immediately before steamboats started to take their place at sea, forever changing the way of sailing. In fact, steam powered ships were the first ones to make the obvious possible: if I have to go from point A to B, I just have to take a straight course to my destination. This was not the case during the Age of Sail, where you had to take into account winds and their patterns, since most of them blow predominantly from a single general direction.

So, the first things we did was to implement a map of the global winds that you can access by using the winds filter of the Captain’s log. By taking a look at it, you will be able to notice 3 types of areas:

Areas with wind patterns: in which you will find some wind for sure, probably blowing in the direction shown or really close to it.
Areas with strong wind patterns: similar to the area above, but with strong winds. It’s characteristics of the oceans area under a latitudes of 40 degree.
Areas with no patterns: areas of sea in which the wind could blow in any direction and strength.

How can you understand what’s the wind situation in your current position? Just take a look at your compass rose, it will tell you three things:

Wind direction: the direction in which the wind is currently blowing
Wind strength: we are currently using 3 different strengths (none, normal, strong).
Your sailing direction: so, if you are sailing windward or leeward (against the wind).

The most important element is for sure the wind direction in comparison with the one of your ship. Sailing leeward it’s a really difficult and inefficient way of sailing since it requires a lot of maneuvers to keep moving. It translates in the game in going slower (according to wind strength also really REALLY slow). Going slow means burning resources and money and, if that it’s not enough, I’m sure you will reconsider it the first time a pirate ship will be biting your ship’s stern.

If inside the areas with wind patterns is pretty easy to schedule your course, outside of them you have to keep an eye to your compass rose to avoid unpleasant surprises. The wind there is much more unstable and you could end up struggling for days.

In the next episode of our DevsPlay series coming next week (if you have missed the first four episodes, you can watch them here), we are going to show some gameplay related to the navigation so, if you want to take a look to everything we discussed here on “paper”, keep an eye to our Youtube channel.

That’s it for today. See you soon guys!

Mex

5

Mar
2016

DevBlog

A new way to handle your harpoons

by Mex

“

Is Ahab, Ahab? Is it I, God, or who, that lifts this arm?

Herman Melville

”

Ahoy there!

It’s been awhile since I wrote my last post, but there have been a few posts from Captain Eatbones about interfaces and we have inaugurated our new video series “Devs Play“, in which we started showing some gameplay from our upcoming title Nantucket. If you have missed our first three episodes, you can watch them on our Youtube channel.

In today’s post, I’m going to write about the changes we made to the combat system in the past months to improve the overall gameplay experience. During our tests and by showing the game around to people, we realized the combat system needed some rework. The main issue was related to its length, since every combat had too many empty rounds.

So, the biggest change has been completely changing the way commands were triggered. In the previous iteration, commands had to be chosen before knowing the dices rolls and, since their costs were subject to a lot of variables, really often selecting the cheapest command was the safest solution, granting an higher chance to do something during a round. Yes, it’s bad, especially considering the fact you level up your characters to get cool commands, and you want to play them.

Combat Mock-up

In this new version the commands are “engraved” in the dices, so you actually roll the dices before selecting a command among the ones available in each whaleboat. Every class has a base command occupying 2 sides of their combat dice and then special sides (and commands) that are unlocked by leveling up your crew or assigning an object to a specific character. In details:

Hunters are good in dealing damage. According to their skills branch, the can be specialized in hunting whales or fighting men (such as pirates).
Sailors are specialized in evasive maneuvers, so in removing enemies action cards.
Craftsmen are a support class and they allow you to re-roll some dices.
Scientist can heal you characters and save them from death.

So, every round, the enemies play their commands (cards) face down. Then you roll your dices and pick a command per whaleboat. Pretty easy, also if the strategies involved are quite a lot.

First of all, whales have different behavior according to their type and age, so you want to “tune” your strategy according to the enemy you are facing. Then there are random condition cards appearing each round, related to the surroundings of the sea area in which the combat is taking place (icebergs, rough waters etc.). These condition cards are pretty strong and they will affect a lot your choices in each round.

Finally, with this new system, you will be able to set your strategy well before the beginning of a combat. You can shape your dice and the ones of your crew during your travels, leveling up, or simply selecting crew members fitting your style of play. For example, you can choose to have a lot of hunters, maximizing your chance to hit every turn or decide to have a more versatile approach, picking more classes.

Remember that hunting is just a part of the dangers you can face at sea, and probably not even the deadliest.

That’s it for today. The new combat will be covered by a “Devs play” episode, so you will be able to have a more detailed grasp about it pretty soon. Keep following us for updates and see you next time!

Mex

20

Feb
2016

DevBlog

UI Iteration #2: Shipwright

by Capt_Eatbones

Ahoy! Capt’s here!

Here I am again to continue our journey around the UI iterations we’ve been working on in the pasts months. If you haven’t read the previous articles, here you have the link:

UI Iteration #1: the Tavern

Moreover, you surely have been following our video series “Devs play”, about us showing our game Nantucket development status. If you haven’t, well…just do it:

Nantucket – Devs play

Now, back to where we were. Nantucket’s harbor has almost no more secrets for you…or so you believe >:] After the Tavern, we did iterate another crucial UI: the Shipwright’s. Here you have the old version, previous to the “steroids treatment”:

Before the re-working, the Shipwright UI was split in two. Above you can see the main panel where the player would have repaired his/her ship or bought a new one. Again, the main idea was to represent this UI as an unfolded piece of paper where the shipwright owner would take note of all the ships available to be bought in the harbor. The little panel on the right was the player’s current ship panel.

Guess what? People trying the game was not able, most of the time, to understand which was your ship and which were the available to be bought. Too many elements were blending in confusing the player. Moreover, at the top left, the tab to switch between the Ships list and the Upgrades are almost invisible. It recalls you anything already happened with the old Tavern UI? Indeed it does!

What about the Upgrades panel then? Here it is the old version, before the “lifting”:

In this section, more issues arose. The Ship technology upgrades are a very important aspect in Nantucket’s ship management. They let you, the captain, research and acquire technology to be able to “tune up” your current ship and the future ones. Also in this panel there are elements not clear: which are the Upgrades installed, which are to be installed, which can be upgraded and which not. I won’t dive into the functionality of this UI since it will be explained in the next video of our Devs play series.

Furthermore, being the two sections separated (Ships and Upgrades) and having the two tabs almost invisible made players almost unaware of the Upgrades view. This is a crucial UI so we couldn’t keep it as it was. A drastic change was needed. At that moment, I was sincerely a little scared of the complexity needed for this UI and of what should be necessary to change it for the better. I didn’t want to change everything, risking to cause more problems than solving them. But, you know what? There are moments where you feel it has to change, radically. So, I started working on it and came to this mock-up:

I wasn’t quite convinced about it. The basic idea of having the current ship and the selected one from the list one in front of the other was there. It just wasn’t proportioned enough: too much weight on your Ship – which is fine per Se – but if you have to choose a new ship, wouldn’t you like to have it shown full size for better comparison? Another important aspect is that the Ship technology upgrades panel is now in full sight: you don’t have to switch to another view. As I told, the main concepts were there…they simply weren’t fully developed.

So, I changed it again and come to a new proposal:

When I shown this two Mex and Bubb their reaction was: oh-my-god…you changed it completely! Now, that’s the kind of reaction I looked for! Simply, I wasn’t sure if it was a good one or not XD

This is the current Shipwright UI. As you can see, I switched the player’s current ship to the right placing the selected ship from the available ones on the left. Perhaps, knowing that a person usually reads from the left to the right it is not the best idea. What I tried to achieve with this decision is to maintain a certain amount of consistency throughout the game. In the Tavern UI, the Captain’s panel is placed where it would be in the navigation phase: on the left. Here the player’s ship panel is placed where it would be in the navigation phase: on the right. Visually, the ship view is the same as the one you have during navigation. We want the player to get used to these placements, so we don’t change them. Indeed, this is not always possible or is the best idea. In this case, we think it’s worth it.
Also, the available ship selected is presented and the same size as the one the player currently has. This places the other ship on the same level since it could be your next ship!
Right in the middle, between the two main panels, there are the details of both ships. I wanted here a direct comparison between information, so I decided to place them one in front of the other. The last thing I did was to re-work the Ship technology upgrades panel in order to have it visible at the same time.
Keep in mind that this structure is thought to be modular. The Shipwright, as all the Harbor buildings, can be of different levels. To each of these levels correspond a specific UI panel:

Level 1: only the “Your Ship” panel is visible.
Level 2: only the “Your Ship” and “Available Ships” panels are visible.
Level 3: all UI panels are visible.

As for other iterations, we asked for feedback. This new version has been generally welcome. We know there is a lot of information to process but we took the screen space needed to show them and we organized the elements in a more functional fashion. I adapted the new UI elements style to this layout so everything should be a lot clearer. Is it perfect? No. Is it a better solution? We believe so. It probably is a bigger step forward in comparison with what has been the last Tavern iteration.

If you feel that something is not right or that could be improved, please, let us know 😉 We’d really appreciate.
Well, I think I’ll leave you here for today. Remember, though: more articles are coming about our improvements in Nantucket!

Stay tuned!

5

Feb
2016

DevBlog

UI Iteration #1: Tavern

by Capt_Eatbones

Ahoy, fellow mates!

It’s been a while since our last meeting, the articles about the interface design process of our upcoming game Nantucket. If you missed them, here you have the links:

Well, I’m here again because of what I said in those articles: iterations. Oh yes. Right after the Milan Games Week 2015 (here’s the full coverage) we analyzed the received feedback and a relevant part was related to the UI not being clear enough.
We decided to rework the UI with the goal of make it more readable. The mistake I run into is trying to have an appealing UI, well integrated with the “Paper” theme. Too much integration leads to less readability of the UI elements, being too “camouflaged”.
An example of this are the generic buttons: too many different styles so the user cannot really say when an UI element is a button or not. Following this principle, I started re-designing basic elements such as button, check boxes, etc. up to whole UI panels.

Today’s article is about the first big change: the Tavern UI, used to hire/fire crew members. If you don’t know what’s this UI is about, please, read the previous article Looking for strong hands and a drink.
I’ll start by analyzing the UI that we had, highlighting those aspects responsible of the not-so-good User Experience.

I thought the Tavern panel as a page of a hired crew book, where the captain takes note of the details regarding his/her crew members. At the same time we needed a list of the available crew for hire in the Tavern. The old UI you see above, presents the list of members “For Hire” and “Hired” one on top of the other. The interior layout of each list is the same: on the left, the list of members and, on the right, the details of the current selected character. Being one on top of the other was thought to let the player compare visually the details. The main issues of this layout were the following:

Lot of information is displayed in little space.
Most of the information is in text form.
The right tabs filters are almost invisible to the user.
Drag&Drop assignment not clear.
Prestige points used too “camouflaged”.

As I stated in previous articles, design ideas don’t come from just one person. Actually, Daniele, our programmer, was who suggested a mock-up with a possible solution for the Tavern layout:

TavernConcept

As you can see, we started with a rough concept. Nonetheless it contains all the corrections, at least functionally, we needed:

Separated captain panel, on the left, as in the navigation phase. This way, the captain’s panel is always placed in the same screen area, no matter what phase you’re playing.
Split into two different panels the lists “For Hire” and “Hired”. The layout remains the same, more or less, but they are visually separated.
Added two buttons for Hire/Fire in the middle between the “For Hire” and “Hired” panels.
Bigger filters tabs.
A popup to be used as help tip for the player.

Even if the main changes are present in the above mock-up, there were still aspects not solved, as the Prestige point/cost. So, after this first suggestion, I worked on a bit more defined mock-up:

As you can see, a step forward has been taken in this second mock-up:

Added into the details area the illustration of the selected character. This is something that several people told us would have been better to have in order to visualize the person and not having just a name. It should add a bit of depth.
Each of the two panels “For Hire” and “Hired” has its own action button, “HIRE” and “FIRE”, point toward the direction of the change of places. This way we introduced an alternative to the drag&drop assignment/fire. Regarding the drag&drop, we also introduced a changing cursors while on a dragable element of the interface. This decision has been applied everywhere in the game, not just here.
Added a Prestige icon for each character label representing the Prestige cost of the person. At the same time, below the “Hired” panel, I added a Prestige Used progress bar, to better visualize the concept. Indeed, the Prestige Used icon and the Prestige Cost icon are quite similar.
Moved the Cancel and OK buttons to the bottom right. Most of the people who tried the game where always looking in that area the buttons to close/cancel the action.
The filter tabs are not bigger and colorful!

After this second step, I worked on the final version, the one that we now have implemented into the game currently. Here you have it:

As you can see, some more changes occurred. I moved the tabs on top of the “For Hire” panel because placing them too far on the right made them still a bit “invisible”. Moreover, I placed a darker paper sheet on top of which the two “For Hire” and “Hire” panels are laid. This way I can keep the UI a whole panel. Also, you can see the new style for the buttons: since the paper usually has a lighter color, I decided to go for a darker one for the buttons, to make them stand out more.
The last change is about the captain’s panel: the health bar is now a more “common” red bar with the health value on top. I also added a XP bar, at the bottom of the captain’s picture, with the value showing the current amount against the one needed to level up.

We showed this new version to several people and everyone, even those who saw this UI for the first time, stated that it’s quite good. It’s not perfect but, surely, a big step forward.
We are up and running! We want the best experience for the players and for this reason we chose to keep tuning whenever and wherever possible.

Well, for today I’m done. Don’t worry, though: more UI iterations are coming! So, stay tuned and follow our Devs play video series!

Patch 1.2 is out! Mac and Linux versions are finally available.

Mac and Linux versions are now in beta, more to come.

Choosing the fastest route in Nantucket – 2D polygonal pathfinding in Unity

UI Combat: Let’s fight!

UI Combat: Deployment

UI Iteration #X: Combat

MOCK-UPS…MOCK-UPS EVERYWHERE!

Follow your winds

A new way to handle your harpoons

UI Iteration #2: Shipwright

UI Iteration #1: Tavern

Buy Nantucket

Newsletter

Posts