Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
August 23, 2017
arrowPress Releases






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Small Indie Reaches for the Skies - The Making of Heroki
by Michael Balm on 08/31/15 01:01:00 pm   Featured Blogs

4 comments Share on Twitter Share on Facebook    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

By Michael Balm, Bobby Bouman, Jimmy de Meza, and Jeffrey Kamermans

Like so many other indie games, it all started with the question "what if?"...

When the iPhone 3g came out, Michael Balm (Music, SFX and PFX Artist) was the first of us to own one and saw it as a serious game device early on. He pitched the idea of creating a game for it to Bobby Bouman (3D Artist). At the time, Bobby was working at Triumph Studios on a big AAA title for console  and didn't take the idea very seriously, as he felt that mobile phone games were quite basic and didn't really appeal to him.

As years passed and the iPhone proved itself to be a worthy platform with multiple great looking games, the idea of creating something for this platform really started to grow. One evening when we were attending a skating event, Bobby shared the idea with Jeffrey Kamermans (Programmer). As we rollerbladed through the city of Rotterdam, we discussed the possibility of creating a game together with our other friend, Jimmy de Meza, as Concept Artist. What if we were to bundle our strengths and specialties- what would the resulting game look like? As all of the work would need to be done in our spare time, we agreed to create something small (yeah…), yet fun.

At the very beginning we had tons of fun game ideas, so we started experimenting with different game-mechanics. One game concept that stood out at first was a game wherein players would pick-up passengers on a bus and face a road full of obstacles which caused you to lose passengers if you hit them. The goal was to finish the stage carrying as many passengers possible. It was simple, yet effective.

We all liked the funny / wacky style of the game and decided to work on expanding the game mechanics. Meanwhile, Jeffrey was also working on a small, completely separate prototype and pitched his idea to us. For the first time, we saw a convincing control scheme that was a perfect fit for touchscreens - Pushing a character 360 degrees forward, as if blowing wind with your fingertip which is always placed behind the visual action. It was this very first prototype that we fell in love with. Perfect!

We saw massive potential in this new control scheme, so we scrapped the bus game and went straight for the push mechanic idea. The gameplay was set up to push a character forward through maze-like levels and reach the goal by avoiding all types of hazards. We undertook what we thought was a small project that we would complete within a year or so (the irony…).

What started as a small side-project grew into a massive 5 year project which would eventually be published by SEGA.

What Went Right

1. Controlling a new kind of Platformer

Right from the start, we knew we had something special to build on with the push controls. With this core mechanic in place, lots of additional ideas followed and our course was set to create an adventure game influenced by many famous platformers from the past.

Technically, Heroki isn’t a platformer since Heroki’s main ability is flying - which was an obvious design choice because of the push controls. Having complete 360 degree freedom to move while keeping traditional platformer elements intact proved to be a huge challenge. Offering so much freedom meant that Heroki could travel anywhere you wanted him to go, and although exploration is something we sought to focus on, it was possible to easily fly over enemies, which took away a lot of the challenge and fun. We had to keep these aspects in mind while design all of the levels - Invite the player to explore, while directing them to engage in combat with enemies. But what would this combat look like?

The traditional way to attack in platformers is by jumping / stomping on enemies. This wouldn’t work for our character because he’s flying and therefore doesn’t have the ability to jump and we wanted to do something different that would fit the style of the game perfectly. Being able to attack at any given time proved to make the game too easy, so we wanted to balance this out by making the attack depend on other factors like pick-ups. The pick-up mechanic works just like point-and-click. When you tap on an object, Heroki flies automatically towards the selected object. While holding an object, a new mechanic becomes active - The ability to throw, which is also Heroki’s basic attack. This mechanic is activated with the conventional catapult gesture by pressing on the character, pulling back, and releasing to throw.

At this point, we had all the basic gameplay in place, but while playing through the levels, we felt there was still something missing. The gameplay felt slow at some points and we wanted to improve that by adding a new mechanic - the free fall. This mechanic allows Heroki to go into a free dive which makes gameplay a lot faster. The free fall is activated with a single tap on the screen (depending on which os the 3 given control schemes you’ve selected).  This was the quintessential missing puzzle piece, adding depth and making the game a lot more fun to play. The free fall is to Heroki what jumping is to Mario or Sonic, only in opposite direction.

Over time, we added additional abilities to increase variety such as the Dash and Bash attack and the power of wind. For the power of wind, we had to design a new trigger that would not conflict with the other control gestures in Heroki, so we came up with the idea of drawing a wind line from the edges of the screen. We hadn’t seen the implementation of this gesture in an iOS or android game before, but it worked wonderfully and activated only when intended.

Having so many abilities / features on a touchscreen without using buttons made it challenging to keep all gestures separate from each other and prevent accidental triggering - Especially since we aimed for  one finger input. We also had to keep all gestures simple to execute because there are only a limited number of commands that can be used on a touchscreen. Despite these challenges, all the gestures we’ve used feel intuitive and made for touch and we’re quite happy with the end result.

2. The Art Direction

We wanted the art style of Heroki to appeal to a broad audience so that people would want to invest their time exploring every corner of each level. We wanted to make players feel like they are actually in this beautiful and believable fantasy world. Blue skies ftw!

Before we arrived at the current art style, we experimented with quite a few different styles. We were leaning towards a family friendly look with playful shapes and vibrant colors. Our goal was to create something accessible, yet memorable.

Here is the first Concept drawing which set Heroki on the right track in terms of art style:

We drew a lot of inspiration from the games we grew up playing, such as Mario, Donkey Kong, Sonic, and Kirby, each of which have their own unique take on platforming gameplay and art style.

For Heroki himself, we wanted to create a character that was easily recognizable. His functional design - large arms for pick-ups, big head for reading his expressions on a smaller screen, small body and legs to show that he’s built for flying, and his propeller- gives him his distinctive look.

We chose 3D in order to save on texture space, because when we started developing Heroki, the iPhone 3gs was the target platform and didn’t have much RAM Memory compared to what we wanted to achieve. If we went for a 2D game, we were afraid that working with so many unique textures would flood the memory - so 3D it was! We decided to work with universal textures which we could use to create many different shapes for platforms and other scenery.

Translating 2D images into 3D can change the feeling of a concept, so we wanted to make sure we kept the 2D feeling by staying flat-shaded in a 3D world - and this worked.

As we got further into the development, we gradually added visual and technical polish such as: real-time shadows, rim-shader, bloom, distortion shader, dissolve shader, lens flares, and more.

After a while, the 2D-ish environment started to contrast with all of the added visual polish. It needed that extra ‘something’ to even it out, so we turned our attention to ‘ambient occlusion’. This subtle shadow effect allowed us to add depth to environments while maintaining a cartoonish 2D look. The only problem was that ambient occlusion wasn’t supported by our engine, so we decided to manually add all of the AO by hand, using vertex colors. The upside of adding ambient occlusion by hand was that we could use whichever colors worked best for the underlying texture color in order to make it blend best. This lead to a somewhat baked global illumination effect. Using only the color black can result in a “dirty” look around the edges, so having full control over all the colors that we used was a huge plus. The downside of adding all of the AO by hand is that it was a very tedious process and took a tremendous amount of time and effort. That said, after seeing the first tests with and without AO, we were convinced!

3. Inspiring Music and SFX

The music in Heroki was elemental when it came to setting the tone and direction of the game. It has a funky groovy vibe that fits perfectly with Heroki's swinging arms and flying, free falling movements.

Although the music went through changes over time, it retained the same funky vibe that it had from the start. We added a lot of dynamic audio loops in Heroki,  for example, in his village there are lots of positional audio loops placed on certain islands that reinforce the main tune when Heroki is flying nearby, and all of this synchronized with the theme song of the village. We used this technique for many instances including the world map theme song, which changes instruments depending on which world you're looking into. Another example is that when you dive underwater, all of  the instruments change. These seemingly minute details add a lot to the audio-visual experience - Heroki boasts over 40 unique tracks including custom cutscene music.

All of the sound effects in Heroki were made with the music’s ‘global pitch’ in mind. Often, sound effects can sound a little off because they have a different “tonality” than the music. Applying the global pitch on the sound effects really eliminates this problem. This is important in order to achieve the best sounding results. Overall, Heroki includes more than 900 unique sound effects.

4. Proprietary Tech / Optimizations

In 2010, game engines such as Unity and Unreal were still quite expensive. Because we didn’t have the money to invest in expensive tech, we decided to build our own 3D engine. It gave us full control of all of the modules and optimizations, and the process provided us with tons of experience.

Building our own tech had some very big advantages. For example: We were able to achieve the best outcome in stability, frame rate, and loading speeds for the game logic. Everything is truly optimised without any other unwanted processes running in the background to slow things down. We had full control over every aspect which helped us achieve the target 60fps gameplay with fancy shaders and post effects on almost all supported Apple products. All of this was possible without reducing the visuals on older models and this gave us confidence that we made the right decision in building our own engine.

There were  also disadvantages, such as the amount of time that was required to build the engine. Building everything yourself is a slow process which can wear on your patience, especially if you want to achieve fast results. Workflow is one of the most important aspects in game development, which we’ll come back to later...

Over the course of time, the Picon Engine matured into a powerful tool with many of the same features and shaders that you see in modern game engines. We’re really proud of it.

5. Spare Time Development = Less Financial Risk

5 Years is a long time for game development and for a mobile game, it’s practically unheard of. Yet, because we worked on Heroki in our spare time, we basically had all the time in the world to perfect the game and make it exactly how we imagined it. There was no real pressure as far as a deadline and SEGA was very flexible and gave us plenty of time to perfect the game as much possible.  We were able to create a game that we truly love to play ourselves and almost every single one of our ideas made it into the game, which worked out very positively for Heroki.

As we all worked day jobs throughout most of the project, we were able to sustain ourselves financially which made the project less risky as we hadn’t invested a lot of money directly into the development (apart from working hours, licenses, and a personal loan). Overall, it was a choice that we felt comfortable with, although we certainly faced challenges along the way.

What Went Wrong

1. Workflow

Because we were predominantly “progress focused”, we couldn’t really invest enough time to work with proper toolsets. Tools that would have helped us create the worlds, such as a Level / Resource editor, Tools that are essential in todays game development.

We weren’t able to test our work in a level editor and in the last couple of years, we couldn’t use the Simulator on the mac, as the game had become too heavy to run. In order to test the work we had done, we had to:

1. Commit the files and wait until a new build was made on the build server. 

2. Upload the build to Test Flight or iTunes Connect.

3. Download the build to our phone/tablet to be able to see and play the result.

All together this would take us two to three hours or longer, depending on whether or not the process went smoothly.

We had to choose between focusing on making better tools or making progress within the game, and we chose the latter. In the end, we don’t know if it was the right decision because making proper tools would have sped up the development a lot, just as building them would have been time consuming  – and we needed all of our time to work on improving the game.

Apart from the lack of engine toolsets, we also worked separately from each other (each working from our respective  home) which proved to be far from ideal. Most of our communication was done via Skype, and we learned that we had to be careful to avoid miscommunication. From time to time, team members would be confused about certain gameplay elements because they had interpreted something in another way than it had been intended. As time passed, we adapted to the long distance work relationship.

Toward the end of the project we were able to work from the same location more often, and during these times we found that we worked more efficiently. Working together made creating and testing builds a faster process and development sped up.

Needless to say - initially our workflow was quite bad. Still, in some moderate ways, the limitations that we faced forced us to be more creative. We learned that finding different ways to get to the same destination was at times a fun and rewarding experience in and of itself.

2. Planning

Good planning is essential. Maintaining an accurate overview of the current state of a project is imperative, and we learned this the hard way.

If you followed us on social media throughout development, you might have noticed that we thought we were “almost done” with the project many times before we were really finished.

We found that good planning - keeping track of tasks - took a lot of time that none of us had the bandwidth for. As a result, we made short sprint plans that worked very well, but didn’t give us a full scope of the project overall, and as a result we were unable to accurately estimate how much work there was left to do. Having a realistic plan would have enabled us to better estimate what remained before Heroki would be complete.

What can we say, we’ve learned our lesson and will take this experience to our next projects.

3. Personal Struggles

Working on a project of this scale during our spare time made it necessary for each of us to make sacrifices. Working passionately on a project that was tied to our future dreams sometimes meant that we didn’t have enough time to devote to other important things such as relationships with friends, family, and loved ones. These sacrifices had different impacts on our personal lives, which made the final development phase particularly difficult.

4. Playtesting

Although we did a lot of the playtesting ourselves, hired a playtester for a while, and had a few  QA sessions from SEGA, we found that this was not sufficient for a game the size of Heroki.

As a result, there were a couple of bugs left in the release build that could have been avoided with more extensive testing, such as the iPad mini crash. This was the result of an out of memory issue due to a faulty setting for the texture sizes. It was a very easy fix but, because we hadn’t tested on on iPad mini, we failed to catch this prior to release. As a result of the bugs that we did miss, some of our players asked for refunds or gave the game a low App Store rating.

Luckily it’s pretty common these days to update and fix startup problems on iOS and were able to push out an update just 4 days after the launch. This proved to be a huge success as we received a lot of positive feedback after the fix and our rating greatly improved.

5. Levels Too Lengthy For Mobile Audience

During our many play sessions, we were able to complete levels in 5 or 10 minutes. We calculated a few extra minutes for the end user, but learned that people would sometimes need 20 to 30 minutes to complete just one level. Although this isn’t necessarily a deal breaker, we found that some people would get stuck somewhere in the levels, which we had not anticipated.

There will always be people who don’t like your game and on the flip side there will be people who absolutely love your game. It’s difficult to put a stamp on what works best for the mobile market. We’ve learned that a lot of people that play iOS games prefer shorter gameplay sessions and easier game design. Although this may seem like an obvious conclusion, it’s in contrast with what we set out to achieve because we aimed to make a console quality game, both in terms of visuals and gameplay. We wanted to bring this experience to the mobile market because we felt it was missing. There’s definitely an audience for it, although it may be small compared to the majority of iOS users.

Conclusion

Developing Heroki was an incredible journey that was rewarding on several levels. We’ve learned so much about game development and working with a big publisher in the last 5 years - and we feel like this is just the beginning. Heroki turned out to be the game that we had always wanted to make, and given the fact that this was our first title, it exemplifies what we as a team are capable of making “from scratch”.

Throughout our journey we encountered and overcame several roadblocks while managing to keep each other motivated. With Heroki, we think we’ve proved that we are a team that will always look to create games with fluid, intuitive gameplay with cute, lovable characters.

Data Box

Developer: Picomy

Publisher: SEGA

Title: Heroki

Release Date: July 2, 2015

Platform: iOS

Number of Developers: Michael, Bobby, Jeffrey, Jimmy

Length of Game Development: 58+ months

Development Tools: Picon Engine, Maya, Photoshop, FL Studio and more.


Related Jobs

Avalanche Software
Avalanche Software — Salt Lake City, Utah, United States
[08.22.17]

Art Producer, Outsourcing
Gameloft Barcelona
Gameloft Barcelona — Barcelona, Spain
[08.22.17]

Senior Producer
Giant Enemy Crab
Giant Enemy Crab — Seattle, Washington, United States
[08.22.17]

Technical Producer
Wargaming America, Inc.
Wargaming America, Inc. — Emeryville, California, United States
[08.21.17]

Community Manager





Loading Comments

loader image