#failuregame

We're demoing Failure: NeuroSlicers at Intel Buzz Workshop in London this Saturday 8th April, during the #indiedev showcase - http://intelbuzz.bemyapp.com/2017/london/ come along and meet the team if you're about.

One of our first design goals for Failure: NeuroSlicers was to create a User Interface (UI) that was streamlined, clean and gave the player just the information that they’d need at a given moment without cluttering or overwhelming them.

Looking To The Past

Other RTS games often, at least in the past, had UI’s that would take up 1/3rd of the screen with unnecessary elements or over the top art that, in our opinion, added little to the immersion and took away the player’s ability to see the bigger picture. This is also why we allow full camera movement rather than fixed angle and zoom.

Very little has changed in terms of UI design for RTS games over the past 20 years; we still see the mini-map, info panel, areas for Resources, Tooltip box and a number of other elements as seen in below screens from 3 of the most popular RTS games from the past few years:

As you can see from the above examples the designs are almost identical and all have 1 very annoying problem; their size and the amount of information being displayed means that only 2/3rds of the screen are viewable to the player and this restricted view means the player will have to move the camera around more in order to keep focused on the action. This is compounded by the limited camera zoom, rotation and tilt that players have access to.

With Failure, we have made it our mission to remove or at least reduce this screen clutter while still giving as much information to the player.

First Iterations At Minimal UI Design

UI design is endlessly complex; there’s an incredible number of things to think about when it comes to the thing that you’re going to be interacting with throughout your time with a game; element positions, fonts and sizes, what happens when you press a button, how shortcut keys are linked to elements, sequences of actions, animations of elements, input methods (i.e. touch, mouse/keyboard, controller, motion, eyes, voice, etc.). The list is almost endless and it’s been the biggest discussion point over the past couple of months. Before I go into details about our plans for Failure’s UI, I’d like to show you how it’s changed over the past couple of years:

The above version of the UI was one of the earliest iterations and boy was it ugly! 

Here we used the top left section to show the available Scripts and their costs. When you had enough Data to play one it would light up. Below this was the data resource pool… no idea what we were thinking with that design. And finally, in the center of the screen was a radial menu design. This appeared when you selected a cell and you would slide you mouse over to the script you wanted to use. 

Several issues were evident quite early with this design. Firstly, you needed to memorize the icons for each Script and what they did (and some we didn’t even have icons for!), the Data Pool section looked really out of place and the overuse of colour really didn’t help things. Also, as we continued to develop the game the layout didn’t fit with the new mechanics that we designed.

This circular menu never actually made it into the game, it was just a mock-up to see how we could integrate the elements from the top left section from the previous iteration into the placement UI. What was quite nice about this UI was that we could see when a Script might be ready; as you gained more data the segments of each script would fill up, though one issue was that you'd only see this menu when clicking on a cell, and once you'd clicked on a cell the UI would occlude your view of the level, so not ideal.

Experiments In UI Overlays

Here's another mock-up UI that never made the cut. Though this time it's an overlay. We felt we wanted to integrate a chat system and mini-map and make the Data Resource a bit more prominent, though through play-testing we very quickly realized that there was little need for a minimap due to Failure having small arena based maps and no fog of war. It was space that could be better used. The other issue we found was that due to the Data Resource Positioning some players never looked in the top left corner.

This was a second mockup that we actually integrated and tested in game, though once again we realised it wasn't the best use of space. It also still relied on the cell selection based menu for Script placement, meaning you had no idea whether you had enough Data to play your Scripts until you selected a cell. Not ideal.

Going Clean with UI

This in-game UI was the first version designed by Ryan Klaverweide (UI Artist from Bungie) when we brought him on board.

Here we have the Data in the center, Function scripts to the right and building Scripts on the right. All scripts displayed their cost in the top right and over on the Building side you can see the units that were associated with each building.

Several things changed here from the previous iterations. We realised how important it was to be able to see each of your scripts at all times along with their associated costs; one thing you can't see in the above is that scripts were given a dark overlay when you didn't have enough data to play them and then became lit when you did. With this layout, we also allowed shortcut keys to be used to trigger each of the Scripts, bound to the numerical keys 1 - 6 (though they could be bound to any keys you want).

With this design, we still had a few issues. Firstly, players still needed to learn the icons in order to decipher each script. We also couldn't find a good way to display the upgrade menus for each script.

At this point, several key design changes happened. First, we decided to separate units from buildings, in effect making them their own Scripts. Previous to this you would build a building and then units would spawn automatically from them at certain intervals; we wanted players to have more control over units, at least in terms of placement, so the change was necessary.

The second major change came from the load-out/deck building - we moved away from the 6 Script Deck onto a 9 Script Deck. The idea being; you would build a deck of 9 scripts in the deck builder before a match and then, using a new resource called Tech, unlock up to 6 during a match. 

This allowed for more strategies during a match, allowing you to build a Deck that could work for a number of scenarios and also helped with match pacing. 

You'll see the Tech resource here to the left of the Data UI Element. You can earn up to 3 Tech and Script / Upgrades cost between 1 - 3 Tech each.

NOTE: Tech is earned through secondary objectives and over time, its used for both unlocking and upgrading your scripts during a match. Data is then used to then play your Scripts.

We were really liking this layout but we soon realized that we had failed to resolve one major issue - understandability and learning for new players. You see, although an icon-centric interface might look super nice and clean it still has a very steep learning curve requiring players to learn each and every icon before being able to easily understand what each refer to. In addition, we found that more hardcore players wanted more information from each of their Scripts before playing them. Things such as health, attack power, territory gain, movement speed and the core abilities needed to be displayed in order for players to truly understand how a script played, what they were good and not so good for. Some scripts even have multiple behaviors or complex abilities that just weren't easily placed on an icon based UI system.

We had to find a better solution.

Re-Purposing Card Based UI Design

So the idea was to take a CCG approach, using cards with additional elements to display each of our Scripts. It seemed like a natural progression from the icon-based approach and allowed for considerably more information to be displayed while still keeping the UI minimal... well in theory.

Above was our first mock-up of how the new Card based system could work. This screen showed your Scripts in a Mini Card format at the bottom. A larger card format with additional stats would be displayed on mouse-over or right-click which would also show the Script Upgrade menu. For Slots that didn't have a Script installed yet you would click (or use the corresponding shortcut key) to open the purchase menu where you could install one of your 9 available scripts. In addition we saw a redesign of the Resource UI elements on the left.

With this first version of the Large (Above) and Small (Below) versions of the cards we were suddenly able to add a tonne of additional information. On the large card we had Attack Power, Attack Range, Health and Armour on the left.  At the top left was an icon to say what kind of card it was (Unit, Building or Function power), the name, Data Cost, a box for additional details and context sensitive info when hovering your mouse over one of the three ability slots at the bottom. Then we had a large area at the bottom to explain the Script’s specialty and finally a button on the far right to open the upgrade menu for that card. The mini card version was just a compact version of the larger card with slightly less information.

The issue we then had was trying to determine exactly what information players would want at any given moment while also attempting to simplify the way we give the player information in order to reduce the learning curve and time players need to be looking at their cards - Failure is pretty fast paced with matches lasting around 5 - 10 minutes each; you don’t want to be spending half that time looking at the UI, you want to be actually spending that time trying to defeat your opponent so it’s crucial that the information on the cards is presented in such a way that you can understand at a glance and make informed choices without having to spend too much time reading through a bunch of stats.

Here’s how we started to prioritize information based on Script Type:

As you can see, not all Script types need the same information on them and with this in mind we had to try to determine how to present each in a clever way.

Here are some other iterations we went through - pretty much everyone on the team had a try at different layouts and feels for the cards as well as information/stat layouts:

This last one is how our Scripts look in-game right now but over the coming weeks we’re going to be taking much of our findings and research and creating something much cleaner that will hopefully meet our design goal of minimal UI that conveys just the information a player needs at a given moment without overwhelming them while also offering the details that hardcore players want from an RTS.

We are still finding ideas to compress information in a smarter way, and the Card-based UI system isn’t the only UI element we’re trying to be innovative with. 

We imagine that throughout the development process we will be tackling a number of design challenges in regards to information and readability, we’ve really thrown ourselves into the deep end with the development of an RTS game, but this process is really showing what the team are capable of and we cant wait to conduct some proper player research with the new UI systems to see how things have improved. 

Justin - Creative Director

Not an incredible amount of things to talk about on my side this month. I've spent much of the month working on streamlining our processes and making sure that we're hitting our key milestones over the next few months. Unfortunately, a lack of funding continues to hindering our full team working full time; this of course means that scheduling tasks and getting features implemented by certain dates incredibly hard, but rest assured things are still moving forward at reasonable pace considering these funding hiccups. We're hoping that by the end of March these will be a thing of the past as we're still in talks with several people about getting the cash flow needed to bring our vision for the game together.

I've also been doing some system design to try and streamline some of our development processes to prepare for complex integration systems such as our dialogue and in game events which are used to trigger everything from sound effects to animations.

I'm hoping to be able to get back to some sound design over the coming weeks as we have several new Scripts to integrated which are going to need some sounds to bring them to life.

One last thing; on Tuesday 31st January I attended the WeGeek event in London Old Street at the WeWork campus and got another chance to show of Failure and get some much needed feedback from gamers and other tech professionals; it was a great evening and we’re going to try and do this monthly. If your based in or around London and want a chance to come and check out Failure and have a go at playing it yourself head over to http://www.wegeekninja.com/ and grab yourself a ticket. I’m looking forward to meeting as many of you as possible.

Anyway, until next month.

Justin

Loic - Art Director / Designer

Following the art advancements of last month, I kept on designing new units and constructs, polish shape language, animation style and the final look of the 3d models. I’m blending robotics code with nature inspired shapes. 

Some of this inspiration comes from the latest advancements in robotics from Boston dynamics for example, and researches on neural network-based AI and combining this inspiration to mimicking nature, and giving us a new artistic paradigm of what will be our modern take on cyberpunk.

The next step will be to test this design in-game and research new directions to improve it further, before we start producing the rest of the scripts at higher pace.

Railgun by Dream_Harvest on Sketchfab

Pylon by Dream_Harvest on Sketchfab

Brute ANIMATED by Dream_Harvest on Sketchfab

FireWall by Dream_Harvest on Sketchfab

At the beginning of the month Justin also tasked me with prototyping a new design for the Failure logo that encapsulated our mantra for the game - that it’s about the players, each of which are going to be entering the game as trainee Slicers and who will become super powerful throughout their journey. This is still very much a wip but gives a good idea of the direction we’re taking it. Loic

Milcho - Lead Designer / Programmer

Good Evening…

Yes, I don’t respect time zones, thanks for asking J

Anyway, it’s time for my monthly report which enlightens so many. A lot has happened in the last month, and there’s a lot to come, so stick around or regret it forever. For example, the world is burning, but that doesn’t stop us at Dream Harvest to pump out the good stuff – like this beauty:

For anyone interested in this marvel, it shows the struggles of trying to communicate with a remote team. Since we don’t have an office, and a physical white board, we use a virtual one (www.realtimeboard.com). What I am trying to explain there is a new mechanic called “Invade” which takes effect each time you get new territory. It’s still in the works, but in theory it would open up quite a few new options in terms of empowering your buildings beyond their base stats as well as create more effective ways of gaining territory, making each time you place a building something that needs to be carefully considered. We’ll be sharing more details in regards to this system over the coming weeks and months.

On another note, we’ve been dealing with our main in-game progression mechanic this month. It’s to do with how quickly you unlock your abilities, which then gives you certain advantages at certain stages of the game. For example, do I want to invest my time and energy into getting more powerful/interesting stuff? Or do I want lots and lots of resource which will help me spread all over the map, giving me positional advantage?

There are all sorts of choices to be made in Failure and the thing that we’re most proud of is that we’re going to be teaching players about them in detail with gameplay tools. For me, personally, this is extremely exciting, since very few competitive games take the time to teach their players about the depth of their game and leave them to roam the forums. Not with us, we will have a lot of learning tools already in game. At least that’s the plan.

I won’t hold you any longer, you’re probably hungry. Oh, what’s that? Not everyone feels the same as I do right now? Well, that’s quite fortunate, because I am starving. Time for some Yogurt + Biscuits (don’t judge me).

Until the end of time.

Milcho

Richard - QA and Design

Hello again! Let’s get straight into it shall we? The past month has seen a succinct rise in ponderous beard stroking, mostly due to our work on Tech generation and how to make it fit smoothly with the current state of the game.

Our main goals were to allow the player to have more autonomy over his match progression, this was always going to add complexity to the game but our first iteration... It went too far! Introducing the “Tech Bank”, a Script which loaned the player a tech fragment (4 of which made a tech point) but if destroyed takes it back, crashing your “techonomy”, the banking system at its finest! However, it was somewhat difficult to understand, especially so for a new player, with Tech being a key system we had to stick it in a vault and come up with something new.

The Current iteration is the Temple, on construction you’ll gain 40% of your tech point progress, once the player hits 100% they’ll gain their tech point. This is much easier to explain and whilst it does have less interaction and isn’t as punishable by the opposing player it does simplify tech generation. I’m also happy with how it satisfies our goals of giving the player access to different strategic timings and allowing them the choice of when to expand their Script options (the most important part). We’ll see how this pans out in testing, I’m feeling positive about our direction and the amount of choice the player has with this new addition.

Here’s to another month, I hope you’re all well and I look forward to how we progress. Until then… oh the sign off phrase… Mochtest du mit mir tanzen? I’ll think of a better one next time… Just you wait.

Rich