Our design philosophy
On a previous post, we presented the game's design pillars. Those are the immutable goals for the experience we want to offer with Hades Star. To sum up, we want to create a game that has players growing an empire over time; exploring interesting parts of space; making meaningful interactions with other players, and becoming involved in exciting strategic decisions.
The design pillars are quite high level and don't by themselves give much information on how we'll approach specific design questions. This post is an attempt to share additional information. By giving some background on our design approach, including our personal preferences and biases, we hope to add context in how we work and share insight on why the game is the way it is.
This design philosophy may evolve over time, and it will affect not only the initial version of the game, but also the new features we add through ongoing updates. Any new proposed feature, including features suggested by our players, will always be evaluated against the design principle discussed here (in addition to the design pillars). We are hoping that by sharing our design philosophy and pre-existing biases early we can help all players understand why we choose some features over others and drive meaningful discussion.
As always, all feedback on any of this is very welcome.
There are two related types of complexity we want to eliminate, and they are somewhat inter-dependent: Complexity in game rules, and complexity in User Interface.
Any time a player sees a new feature introduced in the game, and the game doesn't give enough information on how the feature works, or the player doesn't know how to access that information, we consider that a failure on our part.
An example of how we give critical information on different game objects is the Info screen. This screen can be brought up quickly for any selected game object:
The details and layout of this screen are still being worked out, but there are two core elements we want to incorporate:
Note that by reducing rules complexity (i.e. by saying "All objects must be easily describeable with a small amount of text and properties) also helps eliminate complexity on the User Interface.
These images illustrate some techniques we'll be using on all other screens. In particular, we will be employing similar use of empty space, and careful combinations of font styles, font sizes and font colors to drive player attention to the important pieces of information.
For us, achieving simplicity in the game's rules and user interface isn't just "nice to have", but a core goal of our design. If a feature we are implementing turns out difficult to fit in this framework (for example, if it makes it harder to keep the user interface and the rules of the game simple), then we will simplify or cut the feature, no matter how cool it may otherwise be.
In order to make that possible, we plan to both eliminate complexity (as explained above), and also focus on technical aspects to make sure the game supports such playing patterns. For example, we find otherwise good games are making it very hard to play very frequently in short sessions because of long loading times and general slugishness. Those technical shortcomings may be less visible on other platforms, but on phones they really can drag down the entire experience.
Our technical targets for fast loading times and high framerates may affect how we we are designing the game, what features we prioritize, and in some cases may even cause features to get rejected.
An example of how we're implementing this goal is that our game will have no intermediate scenes to be loaded. Most games have multiple such scenes, starting from a main menu to tutorial scenes, home base scenes, combat scenes, map scenes, etc. In Hades' Star, the game always loads into a star system scene that offers seamless zoom from individual planets to covering the entire star. The entire game takes place in this scene. The only loading screen will happen when we are transitioning to other star systems, and we intend to keep the load times for such transitions to under three seconds.
We want to accomplish the same thing with our game. We are seeking to achieve a good balance between features that require the player's attention over different timespans. If we don't offer any features that can lead to satisfying 1 minute sessions, we have failed. If we don't offer any features that allow some players to have satisfying 20 minute sessions at least once a day, we have failed. If all of the game's features don't layer together to be fun given multiple sessions of varying lengths during a day, we have failed.
Here are some examples of how some of our planned features might fit into different session times:
10-60 second sessions: Players who have less than a minute to play can quickly load the game to see what happened while they were offline. A Progress Report window shows up when the game loads, giving a high level report on all interesting events, such as resources collected and any results of combat that has previously happened. Some players might end the session right after reading this window - if they have a bit more time, they may want to get additional information and perhaps give quick orders to their ships as a result of these events.
1-5 minute sessions: If they have a few more minutes available, players can give orders to their ships. For example, they may give new orders to idle mining ships, or review where the busy mining ships are mining from and perhaps re-adjust.
5-20 minute sessions: Players who have more time available can search for and participate in a Red Star expedition. While it's possible to cut these expeditions short if something unexpected happens and you need to end your session, best results will be obtained by players who can stick with the mission during its entirety.
We will be testing and watching these patterns as our game evolves and more features are added. If playtesting reveals that a feature we are implementing doesn't fit right with typical session times, that means we haven't gotten it right, even if the feature itself is otherwise perfect.
The design pillars are quite high level and don't by themselves give much information on how we'll approach specific design questions. This post is an attempt to share additional information. By giving some background on our design approach, including our personal preferences and biases, we hope to add context in how we work and share insight on why the game is the way it is.
This design philosophy may evolve over time, and it will affect not only the initial version of the game, but also the new features we add through ongoing updates. Any new proposed feature, including features suggested by our players, will always be evaluated against the design principle discussed here (in addition to the design pillars). We are hoping that by sharing our design philosophy and pre-existing biases early we can help all players understand why we choose some features over others and drive meaningful discussion.
As always, all feedback on any of this is very welcome.
Design Goal #1: Eliminate Complexity
We believe a lot of space strategy games are overly complicated. I've written about my personal frustration and inability to play such games. That's not to say there's anything inherently wrong with complex games. Games like Eve Online offer great depth through complexity, and even get some very dedicated players because of their complexity, not despite of it. But at the same time, that kind of complexity is not for everyone, and it's definitely not for us as designers or players. Hades' Star is focused on offering compelling gameplay and depth, while eliminating most of the complexity found on similar games.There are two related types of complexity we want to eliminate, and they are somewhat inter-dependent: Complexity in game rules, and complexity in User Interface.
Rules complexity
A key goal of ours is to create a game that is very easy to pick up and learn the basics, but still offers depth and variety of interesting choices.Any time a player sees a new feature introduced in the game, and the game doesn't give enough information on how the feature works, or the player doesn't know how to access that information, we consider that a failure on our part.
An example of how we give critical information on different game objects is the Info screen. This screen can be brought up quickly for any selected game object:
The details and layout of this screen are still being worked out, but there are two core elements we want to incorporate:
- A very short description of the object and what it does (1-2 sentences). If we can't explain to the players what the object does in that amount of space, maybe its functionality is too complicated to begin with.
- A list of numeric properties for the object. Players can use those to understand the object more deeply as they play, and make informed strategic decisions. Typical examples here include a ship's hitpoints and damage rate. Again, we want to keep the number of these properties per object relatively small.
Note that by reducing rules complexity (i.e. by saying "All objects must be easily describeable with a small amount of text and properties) also helps eliminate complexity on the User Interface.
User interface complexity
Keeping a readable, clean and useable interface is one of our top design priorities. This is a constant struggle because mobile devices (especially phones) have a very small display area. The last thing we want is to end up with complex, unreadable screens that make it hard to find relevant information. We are finding that even with simple game rules, it still takes a lot of effort to keep things tidy. Here are some examples of some screens we're currently happy with their simplicity: |
 |
 |
 |
These images illustrate some techniques we'll be using on all other screens. In particular, we will be employing similar use of empty space, and careful combinations of font styles, font sizes and font colors to drive player attention to the important pieces of information.
For us, achieving simplicity in the game's rules and user interface isn't just "nice to have", but a core goal of our design. If a feature we are implementing turns out difficult to fit in this framework (for example, if it makes it harder to keep the user interface and the rules of the game simple), then we will simplify or cut the feature, no matter how cool it may otherwise be.
Design Goal #2: Eliminate all friction and allow instant gameplay
We believe a big part of the appeal of mobile devices for games is the ability to check in on an online world at any time, from anywhere, and regardless of how small window of time one may have to play.In order to make that possible, we plan to both eliminate complexity (as explained above), and also focus on technical aspects to make sure the game supports such playing patterns. For example, we find otherwise good games are making it very hard to play very frequently in short sessions because of long loading times and general slugishness. Those technical shortcomings may be less visible on other platforms, but on phones they really can drag down the entire experience.
Our technical targets for fast loading times and high framerates may affect how we we are designing the game, what features we prioritize, and in some cases may even cause features to get rejected.
An example of how we're implementing this goal is that our game will have no intermediate scenes to be loaded. Most games have multiple such scenes, starting from a main menu to tutorial scenes, home base scenes, combat scenes, map scenes, etc. In Hades' Star, the game always loads into a star system scene that offers seamless zoom from individual planets to covering the entire star. The entire game takes place in this scene. The only loading screen will happen when we are transitioning to other star systems, and we intend to keep the load times for such transitions to under three seconds.
Design Goal #3: Design for Distinct Session Times
When we play mobile games, we find ourselves in widely different situations in terms of the time available we have to play - even during the same day. This time can range drastically from a minute or less, to 20 minutes or more. We've noticed how good mobile games manage to provide meaningful things to check on and do, regardless of how short the session time is.We want to accomplish the same thing with our game. We are seeking to achieve a good balance between features that require the player's attention over different timespans. If we don't offer any features that can lead to satisfying 1 minute sessions, we have failed. If we don't offer any features that allow some players to have satisfying 20 minute sessions at least once a day, we have failed. If all of the game's features don't layer together to be fun given multiple sessions of varying lengths during a day, we have failed.
Here are some examples of how some of our planned features might fit into different session times:
10-60 second sessions: Players who have less than a minute to play can quickly load the game to see what happened while they were offline. A Progress Report window shows up when the game loads, giving a high level report on all interesting events, such as resources collected and any results of combat that has previously happened. Some players might end the session right after reading this window - if they have a bit more time, they may want to get additional information and perhaps give quick orders to their ships as a result of these events.
5-20 minute sessions: Players who have more time available can search for and participate in a Red Star expedition. While it's possible to cut these expeditions short if something unexpected happens and you need to end your session, best results will be obtained by players who can stick with the mission during its entirety.
We will be testing and watching these patterns as our game evolves and more features are added. If playtesting reveals that a feature we are implementing doesn't fit right with typical session times, that means we haven't gotten it right, even if the feature itself is otherwise perfect.