Postmortem: Shadow Blade

Shadow Blade is an action platformer for the mobile devices that was released on the AppStore and Google Play Store in January. Developing this game has been the first attempt of our studio at a mobile game and this postmortem is a compilation of a few of the most important challenges we faced during the development of Shadow Blade that lasted for a total of 18 months. This project started out as a small side project to be completed during one summer and slowly converted to a very serious project for the whole studio. You can view the game trailer here and gameplay video.

What Went Right

1 – Remaining Focused on the Core

The main design goal for Shadow Blade was to create a platformer for mobile devices that would embrace touch controls as much as possible. We really wanted to do something unique with the touch screen and provide an experience that would be different from the standard platformer experience on PC, consoles or what you get with virtual gamepads on mobile. Secondary goals were having a dynamic combat system and a little bit of stealth gameplay. We faced our biggest challenge from day one, controlling a Ninja that wants to do precise platforming and combat without having the standard gamepad controls.

One of our main goals was to stay away from the usual “Runner” genre and enable the player to control the character as he wishes and provide options for exploring the levels. 

Our first step was to make various control prototypes and try any gesture possible on the screen in order to control a quick Ninja doing moves, jumps, attacks, climbs, slides, wall jumps, dashes in the air, dives, executes enemies, etc.

The controls and the basic mechanics were something that needed to be continually polished till the last day before the launch and even after the launch. Many requirements tended to diverge our attention to other parts of the game but we would somehow remind ourselves about the core of the game and returned to perfecting this core. We are quite happy about the final result and the unique controls have been received very well, although because there are always some who are resistant to new ideas, we ended up implementing virtual game pad as a backup option for those players.

The goal was to control the Ninja with only taps and swipes

2 – Maximizing Team Potential

One of the goals for Shadow Blade was to try and utilize the best abilities of its team members. We wanted to make something that our specific team could do best, for example we could have tried to make the whole game in 2D but since we had a good 3D artist and animator, we decided to make a 3D side scrolling game. This is probably not what the larger studios do and they would select their team based on the game requirements but for a smaller independent studio like Dead Mage with a team with an already great chemistry, we tried to align the project with team potential and we believe this turned out very well and helped Shadow Blade differentiate itself from the usual side scrolling platformers on mobile devices.

Main Character Idea Concept Sheet

3 – Prototyping

We knew that we had numerous risks ahead of us and one of the decisions that really helped us was to make as many prototypes as possible. The first group of prototypes focused on the controls of the main character. Various gestures were tested to see how they feel when used to control a quick ninja on touch devices.

We wanted to find the sweet spot for this game between platforming mechanics, combat and stealth which we did not have any specific examples to follow and was quite risky so we came up with various game mechanic prototypes for platforming, combat and stealth. This was our first experience making mobile games and we did not have much of an idea regarding the final performance on actual devices, so prototypes specifically to target the performance risks were another main category. And finally in order to understand earlier how the final game could look like and what kind of shaders and lighting system could be supported on the devices, we created a few graphics only proof-of-concept prototypes.

Making these prototypes required a considerable amount of time and resulted in throwing away a lot of assets and code but at the end of the day we believe it was well worth it. The reason for the creation of every prototype was communicated to he whole team in order to reduce the negative effects that throwing away work can have on developer morale.

4 – Testing

We knew that making a lot of prototypes would not have had any value if we were not able to follow proper testing processes once they were ready. Initial tests were done on the PC by our internal team, every test had the goal of answering the specific question that the prototype was made for. Once the PC test passed, we deployed the prototype on the device and proceeded with the tests. We asked a lot of friends outside of our studio to help us with the testing and getting initial feedback from players was highly beneficial. We soon realized that having the latest build available on your mobile device and letting anyone you find outside the studio give you a quick feedback is one of the better aspects of mobile game development.

Regular weekly team tests where all developers sat together and tried the latest build was very beneficial. Having all team members around would help because first of all every little glitch was noticeable by the specific developer, like a problem with one audio was noticeable by our sound designer and a little discrepancy in level platforms would only be noticed by our level designer and secondly proper communication would take place on the spot regarding any problems during the test.

Luckily there were quite a few iOS devices to test on at the studio!

5 – Data Analytics

We knew that we are making a game for an audience, which are quite varied and rather different from the gamer/developers we had on the project. Balancing the game and knowing what the final player is expecting at each stage is a main challenge and our guesses will definitely have a lot of errors. One of the best solutions for this problem was to be able to get proper feedback from player game sessions and then tweak and optimize based on actual data. We found out about GameAnalytics.com and integrated it into Shadow Blade. Now usually the analytics tools are used for marketing and monetization purposes but in our case our main goal was to use it to optimize the gameplay experience and it worked very well. A dedicated post about the details of how we used it to balance the game flow can be found here: 

Closing the Loop: Validating Design Decisions Using Player Data for a Platformer

What Went Wrong

1 – Project Development Time

Our initial goal was to be able to finish the game in three months. We were thinking that Shadow Blade, being a mobile game, would be developed very quickly. The more we worked on it, the more we saw the potential to do better things with it, we did not constrain ourselves despite having started a different project in parallel at the studio. One of the advantages of being independent is that the team can expand the requirements and continue and do what they feel makes the game better. Of course this can have huge financial risks but in our case we tried not to worry about the project schedule, take the risk and continued with doing what we thought needed to be done. The whole project duration expanded to 18 months.

2 – Art Assets for a Mobile Game by Artists with PC Background

We had released two PC games before working on this game and the limitations of the mobile devices were unknown to us. Our art asset creation started out with the quality that was closer to the PC capabilities. This required our artist to modify the art assets a few times during the project, this included reducing the polygon counts, modifying textures, modifying the shaders, combining meshes and recreating materials. Running out of device memory was a major issue alongside the usual frame drops. The built in profiler tool for Unity was critical for this whole optimization process throughout the whole project. You can read about the details of our optimization journey here:

"0-60 fps in 14 days" What we learned trying to optimize our game using Unity3D

From Concept Art to 3D Model

3 – No Social Elements in the Game

Our sole focus was on making the gameplay experience and we did not allocate the proper time to think about and design the meta game around the core game loop. The social aspect of games is quite important especially for mobile gamers and this is something that does not exist in Shadow Blade. We could have worked on friend leaderboards, mission systems and social challenges. However we are planning to add these features with the future updates.

4 – Late Third Party Tools and Libraries Integration

We were required to integrate the game with many third party tools and libraries after the development phase had ended. We had not thought about these integrations earlier mainly because we did not know about them and most were suggested by our publisher, which we signed with after the end of development phase. Examples for these third party libraries included the Facebook SDK, Gamepad controller support, advertisement systems, payment systems, video playback and share systems and etc.

Integrating code with other third party code late in the development stage without proper upfront design is always risky and we did find out that we needed to do some rework at a very late and risky stage. Knowing about these tools and planning for their integration eariler will enable us to come up with the proper architecture and have more time testing them for our next project.

Shadow Blade Environment Look and Feel Concept Art

5 – Lack of Up Front Design for a Resource and Object Management System

For our previous PC game development projects, we worked on our in-house C++ based technology but for Shadow Blade, we used the Unity3D engine. In our own code base we had our own game systems and one very important system was the resource manager for all assets and main game objects. Having complete control on all object lifecycles was something we had learned the hard way in our previous projects. However, when using a game engine like Unity, if you are not very careful with coming up with your main systems to control the object lifecycles and resource management, it is very easy to corner yourself and experience major headaches in this area in the future. We had a lot of issues related to too much memory consumption (loading a new level would add the new level objects on top of the existing ones and then remove the existing level objects) and disappearing game objects with required services when changing levels. Our hacky solutions to fix these problems did cause a few issues very late in the project.

Is this Wrong or Right? Monetization Model

When we were close to the end of the development phase and we knew how the game was coming along, we started to show our work to potential publishers and see if we can find a partner to help us with the marketing and post production stage as we knew the mobile games market was quite challenging regarding those aspects. Then there was the shock, there was one thing that all publishers asked us first, is this a “Free To Play” game? We were rejected by 99% once they learned that this is not an f2p game! We had not thought about making a free to play game since we were not big fans of f2p ourselves and we just had not felt this sudden rush of f2p games. It was 2013 and the f2p waves were all around. We assessed the situation internally an tried to come up with the necessary changes that we could make on this game to make it f2p but we soon realized that if we want to go down that route, the final game will be quite different with what we have and the bad thing about it was that we felt that we had to sacrifice a few of the design goals we had worked on and believed would provide an engaging experience for the gamer. We knew that f2p needed to be designed with the game from the ground up and forcing it into an existing game would only make the game worse, this was not something we wanted to happen to Shadow Blade so we decided to stay with our design and make the best game we can without worrying about all f2p related requirements which often times we believe can ruin the experience of a skill based platformer game. (I am not all against f2p but I believe strongly that only certain games that are designed with the monetization model from the ground up can benefit from it and it can ruin the game experience for many games if not done properly) 

We made this decision knowing that it will probably be worse for us financially. Game quality was just more important for us at this point. We were quite lucky to find a publisher, Crescent Moon Games, that shared the same vision with us regarding the game and its monetization model and did a great job in publishing Shadow Blade and a metascore of 81% is a good indication of quality, not necessarily a big financial success!

Conclusion

Shadow Blade was received very well after its release and we hope we can learn from all of our past mistakes and focus on making better games in the future.

Making games is a huge roller coaster ride and every project has an ocean of challenges and opportunities. The above were a few of our challenges and issues and decisions made, I hope they are useful to other brave game developers out there as much as we have benefited from the great share of knowledge we get from the community.

Game: Shadow Blade
Developer: Dead Mage 
Publisher: Crescent Moon Games
Release Date: Jan 16th, 2014
Platforms: iOS, Android, Ouya, Mac
Development Duration: 18 months
Core Team Size: 8
Development Tools: Unity3D, C#, 3D Studio Max, Photoshop

Link to Shadow Blade Trailer
Website: shadowblade.deadmage.com
Shadow Blade on iOS AppStore
Shadow Blade on Mac AppStore
Shadow Blade on Google Play Store