Postmortem: Ocean Empire

Overview

The goal of this project was to make a game that showcases the capability of Roblox Studio, in addition to providing Roblox with the framework to expand the game on into the future. With this goal in mind, team Atlas created Ocean Empire. Ocean Empire is a multiplayer, ship building/battling game for iPad and PC. Players can customize their ship by adding various components with different attributes, allowing them to build a ship that fit their own particular play style. The players then use these ships to sail the high seas, gathering resources and battling up to 5 other players through the Roblox servers. The game has already been published to Roblox, and is in the process of being ported to an iPad application. Ads will also be posted on the Roblox website to generate further interest in the final release.

What went right

Choose the right theme

We chose the “Naval Ship Battle” theme as appeals to most audiences. Being a universally recognized theme, the player has some preconceived notions of how to play the game, while at the same time the game provided a new and exciting experience. Through research of AAA titles such as “Assassins Creed 4”, as well as casual games like “Seafight”, we realized that despite a considerable amount of naval combat games, there was a lack of games emphasizing the customization of your ship.

Building interface: Tool or Toy?

We struggled with different building interfaces at the beginning, requiring a great deal of iteration. At first we chose a building mechanic similar to Water +, an ETC’s project from last semester, requiring the player to click the item first then click again at the target location. Through play-testing we realized that this interaction was not at all intuitive on the iPad, requiring a great deal of verbal instruction so people could understand how the interface worked. This was resolved by instituting a drag and drop system, which further play-testing revealed to be more intuitive, allowing people to build their ships with no verbal instruction. Later, a removing/relocating mechanic was instituted, allowing them to freely move any items on the ship, changing the whole feel of the game. Since the building process has become so easy, the building interface is more like a “toy” than a “tool”, as a toy is something fun to play with, even without having a goal. In our latest playtest, we’ve seen some players spending a lot of time in the building mode, changing different components and layout even though they know it’s only half the game.

Follow the fun

Through our research, it was obvious that battle is the most intriguing part in most naval games, which prompted us to propose a combat-heavy game from the beginning. This worried the client, as they feared the Roblox engine might have difficulty handling large battles. We explored many other possible mechanics like exploration and treasure hunting, but none of them seemed to fit. We decided to put cannons on the ship regardless, and found that the gameplay suddenly became exciting. After discussing it with the client and working around the technical limitations, we implemented solutions that would allow for small, player vs. player naval combat. We now know that it is better to follow the fun, than to pursue some idea without the same potential.

Release the game on Roblox’s website early

We had published our game on the Roblox website one week before Soft. Occasionally there were random people visiting the game, some of whom left constructive comments, which we in turn answered. This became important because it was our first time developing a game for this demographic, and the website help us get close to our audience and understand their needs.

What went wrong?

Missed the Focus Groups Testing

Focus groups are sessions where potential players are interviewed about their likes or dislikes. We wasted a lot of time “guessing” what kind of game is better, but what we should really have done, is reach out to our target demographic and ask them what they’re most interested in directly. This is something we could have done on the Roblox forum, but we were too focusing on the traditional brainstorming process. One of the major pieces of feedback we got from many of our play-testers was that they felt they needed more weapons. This is a function that sounds very obvious in this kind of game, but one that we didn’t anticipate at the beginning. We were afraid the screen may become too crowded, making the buttons used to control the guns hard to control on iPad. However, our target audience seemed very excited about the combat, and after adding more weapons, it was apparent how much more interesting it made the gameplay. A system if shooting all of the guns at once allowed for a simple, multi-weapon setup.

Underestimate the Technical Difficulties

All of us were new to Roblox Studio. To get familiar with the tool, our programmers made a top-down shooter prototype in one week. Despite growing more comfortable with the program as we progressed, that progression was not without its difficulties. These problems were usually quickly solved by creative problem solving, and in the hardest of cases, through help from the Roblox team. Roblox provided us a technical question forum, which allowed their engineering team to answer our questions very quickly. When we made the name tag and health bar on your opponents’ ship, there was no built-in function that make a 2D GUI using screen coordinates to follow a 3D object in world space. We had been stuck on this problem for a whole day, at which time we reported our difficulty on the forum. The Roblox staff read our question and sent us some code to fix it, saving us a considerable amount of time. Despite a great deal of debugging, we still encounter some bugs that we don’t yet know how to fix. For example: the welding (a special function in Roblox that connects two objects) breaks occasionally when too many players are in a server; visible glitches appear when we shrink the hull; Some objects don’t appear on iPad, and we don’t yet know if that is caused while loading, or if it is an issue in our code.

Underestimated the Time Needed for Quality Assurance in a Multiplayer Game

The multiplayer is a built-in feature of Roblox Studio. Therefore, we didn’t need extra code for game matching or online performance. Knowing this caused us to underestimate the amount of time needed to test in multiplayer. Some systems in the game worked perfectly in single player, but caused problems when more players joined the server. It was hard to track these problems because we can’t access the built-in functionalities, leaving us to try and find the bugs early and fix them. To solve this problem, we had an “Ocean Empire Hour”, when all members in the team would play the game and report the bugs on a spreadsheet.

Aimed on physics heavy game early but it became even buggier

When we started researching games in Roblox, we found that some games used Roblox’s physics engine to create some excellent effects, for example, the destroyable objects and water physic. At first we wanted every component to affect the physic of the ship. For example, a ship may sink after setting sail because it had been overloaded, or may be toppled if the load is unbalanced. However, through testing and discussion with the Roblox team, we determined that the capability of the physic engine is actually very limited. It can’t specify the weight of an object, making it hard to give ship components different weights. The physics engine is also unrealistic in that a large object made of wood will still sink into the water, as the engine pays no attention to material. After halves, we decided to give up most elements related to physics, and use code to simulate the real-world effects.

A Game Concept that nobody have seen before.

One piece of feedbacks we got from those who played our game at soft, was that they were unsure of the goal. This may have been, in part, due to our use of an unorthodox game mechanic, requiring rules that most people had not seen before. The original pitch of this game was “Simcity meets Shipbuilding meets Naval Combat”. We wanted to make a persistent world set in an intriguing nautical theme, allowing players to explore the islands and make use of a complex trade mechanic. However, due to technical constrains and scope, the maps size is limited. This prompted us to create an arena-like level with randomly generated items. For the combat genre, the level and interface usually explain the goal of the game. The arena-like level leads people to believe it is a short-term experience, but as they progress, we want them to keep getting resources and upgrading their ship. It’s okay to have a tycoon game without an end state, allowing the player to keep expanding, and in the case of Ocean Empire, giving them the unerlying premise of arena combat as a purpose to build their ship. Our solution to reinforce a sense of purpose was to provide a back-story for this game. This backstory was then reinforced in the promo video, as well as tutorial. At the end of the tutorial, your captain’s dying words are “avenge my honor”, establishing a simple premise to further reinforce the gameplay.

Not enough background knowledge

We decided to make a shipbuilding game a little late, which force us to start designing the mechanics in a hurry. If we have time to research about how ships are actually being made and design based on reality, the game would be more intuitive and meaningful.

Auther: Chih-Wei (Jerry) Chen
Proof-Read, Edit: Joel Ogden

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s