Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
Portmortem of Cube Up, an endless mobile game based on completing cubes at an increasing speed avoiding obstacles, released on Android devices in 2018.
16 Min Read
Cube Up is an endless mobile game based on completing cubes at an increasing speed avoiding obstacles.
It was released in October 2018 for Android devices and it has been in development for fourteen months (yes, f-o-u-r-t-e-e-n months, a really long time).
You can download the game at this link (feedbacks are really appreciated!):
https://play.google.com/store/apps/details?id=com.macaco.cubeup
The Cube Up development started in a strange way: we were working on a third person shooter financed by a private investor on PC. After few months the collaboration with the investor ended, forcing us to stop the development of the project.
After some weeks of absolute crisis (mental for the disappointment and physical for the long crunch period made in the previous months), we made a reunion with one objective: to choose the new development path to follow.
All the team members shared the same idea: to avoid big projects that would have required funding for the development so we decided to approach little projects in which the funding was necessary only for the marketing.
This is why we decided to develop little games in the mobile market, despite the huge competition in it.
The self imposed objective that the team set at the start of the project was: to create a little game to get experience in a new market, not giving too much importance to the financial aspect because we knew that our first game would have hardly been a killer app for the lack of experience on mobile game development and publishing.
WHAT WENT RIGHT
Ah, one moment...I like motivational quotes and stuff like that, so at the start of each section there is a cool quote (absolutely not mine) inherent to the topic.
We have finished and published it!
"It is easy to prototype a game, selling it is the difficult part"
- Bleeding developers after the first published game -
It is the most basic thing but it is not trivial because numerous projects die especially when the developers have no experience and the obtained results do not satisfy the expectations.
Approaching in a positive way the failures during the development is the key to success.
Planning and structuring the development using the intelligent fast failure is a really good strategy that works very well for teams and developers without a lot of experience.
Learnt:
The road to publish a game is not a sprint, you have to face it with resistance and constancy.
Use the failure as a tool to explore and test new options, ideas, solutions. Prototype stuff to understand and gain experience, not to focus on an idea.
After all the final product complies our initial concept
"A delayed game is eventually good, but a rushed game is forever bad"
- Shigeru Miyamoto -
It is very common to wrongly estimate the amount of required time to achieve the milestones. This was a nightmare for us, in fact we achieved all the milestones with at least one week of delay.
The simplest idea to overcome this problem could seem: to cut partially or entirely one or more features to reduce the required time and stay in the planned time.
Cutting features is really difficult because you have to make a deep analysis to understand which features create the core of your game experience, because if you cut one of them your game probably collapses. Cutting features during the development is the last chance you have.
A smarter approach to solve this problem is to design rules, dynamics, systems, etc. using a priority level that indicates how much this element is important to transmit the experience to the player.
Using this method you start the development with a clear idea of which elements are the core, which ones are the reinforces and which ones are optional, so if you are forced to cut features you obviously will start to delete the less important ones.
In our case we cut all the optional and some of the reinforcing features, but we have always developed the core ones, with the result that our final game experience is almost identical to the initial concept but it took more than a year (too much time).
Learnt:
To design features using the priority method to understand which are the core elements that generates your game experience.
To prototype graphic, UI animations and user experience stuff use Adobe After Effects because you can create very quickly mocap videos with 2D and 3D elements. Only if the created video is approved, start to implement this thing in the game using the video as reference.
After effect Boost mocap In game Boost
WHAT WENT WRONG
Lack of experience on mobile
"Experience teaches slowly and at the cost of mistakes"
- James Anthony Froude -
Design
We did not analyze in depth what kind of interactions work better in mobile casual games. Our game has different problems based on interaction:
The player has to tap in different and precise points based on game situations, if he taps outside of these points the tap is not recognized.
The interaction points are very close to each other (2 centimeters).
The game is really fast so the player has no time to think about how to make a precise interaction.
These problems are annoying, in fact the players fail to tap and die not because of their lack of skill but because of our poor game design.
The previous experience in pc games led us to create a game with too complex rules for the mobile audience. Our game is not understandable without following the tutorial (from 45 to 60 seconds of time required).
Understanding the game rules by a tutorial is a huge effort for casual gamers, the top grossing casual games are so simple that they are understandable by only watching a gameplay video of thirty seconds.
Learnt
To study accessibility techniques to position the game elements in the best reachable screen locations.
The interaction points have to be distant and all accessible with the same effort if you require fast interactions to the player in your game.
To create very simple rules based on previous player knowledge (Angry Birds is based on physics and trajectory, two elements that each player knows; Color Switch is based on colors, everyone knows colors) or create very understandable rules that are clear even watching a gameplay video.
During the development show a gameplay video to the players and ask them how to play the game, if they respond correctly your game has a good level of accessibility.
2D Art
Lack of experience on how to export good sprites and textures occupying as little memory as possible.
Learnt
To create spritesheets and atlas to reduce draw calls.
To use crunch compression to reduce the size of the sprites and textures (they must be multiple of 4).
3D Art
Our game shaders were very badly optimized, all the game performance issues derived from them. After a lot of iterations we deleted the most heavy nodes and we changed a little bit the final graphical outcome but with a lot of enhanced performances.
Learnt
To try to use 2D elements to create 3D effects when it is possible.
For example a really good technique is to use 2D elements in different layers (foreground, midground, background...) in parallax to obtain cool 3D effects with optimized performances.
To consider using things like the new optimized built in mobile simplified shaders offered by Unity 2018.
Coding
The online services implementation (leaderboards, achievements, advertisements and in app purchases) required a very long time and caused a lot of bugs (manifest errors) that did not allow to build the game for a lot of weeks.
The lack of a TDD (technical design document, the coding version of the game design document) in which every developer explains to others their code and the used logic.
Without a TDD each developer could work only on their parts of code because they do not understand how to handle the other’s codes.
So in most of the cases there were developers without tasks and other full of works because the code was understandable only by the creator and the other developers could not help them.
Learnt
Create the TDD at the start of the project and update it after every system/feature creation or change. Code less and write more documentation is the key to efficiently collaborate between developers.
Discuss together on how to develop systems preventing incompatibility problems, because most of the time the coded systems have huge compatibility problems.
Use plugins to integrate systems.
Recommended plugins:Cross Platform Native to easily integrated online services
Easy Save to save game data
Odin to expand the Unity editor with awesome features
Magic Fade to manage all the audio system
Sound
Lack of experience on how to export sounds with good quality occupying as little memory as possible.
Learnt
Listen the tracks and the sound effects directly from the mobile speakers with Audre.io during the audio development, because some audio frequencies are perceived very differently using the mobile speakers.
Ogg is the best format to export audio on mobile, because the quality is very good, the required size is very low, it is gapless so it is perfect for audio looping.
Export audio in mono or activate force to mono in audioclip options in Unity if your game does not require stereo audio, this reduces the size of the track.
A running prototype is not a working game
"You can see a lot by just looking"
- Yogi Berra -
The pre production phase of our game worked pretty well, we analyzed the market, we pitched a lot of games, we prototyped the best ones to understand the advantage and the disadvantage of each production.
At the end of the prototype phase we understood that only Cube Up had a balanced scope for our resources, all the other games were too big or had too complex systems.
We started to create a vertical slice with the basic mechanics of the game and with a little bit of graphical stuff because we wanted to start to transmit the right experience to the testers.
The latter tried the prototype but the gathered feedbacks were not good and all the people said these two things:
Bad interactions (our initial prototypes were based on swipe and not on tap, causing problems on how the players perceived the perspective and so they made swipes in wrong directions)
Too difficult game rules
We listened all the feedbacks and we used this phrase: “these critiques are normal, it is only a prototype”. NO!
The problem of the too difficult game rules it is not a resolvable problem, because the prototype was made up of the core rules of the game, if a player finds these ones difficult, try to think when you add other game systems and the player has to manage more informations in the game.
Learnt:
Do not justify your creation saying “it is not complete”. Listen the feedbacks and if all the people say the same thing think how to fix it.
If the feedbacks are not good, delete instantly the project. It is better to waste one week of prototyping than one year of development.
Be a family first then a team
"Burnout is about resentment. Preventing it is about knowing yourself well enough to know what it is you're giving up that makes you resentful"
- Marissa Mayer -
Our development studio was not a “standard” studio made up of rooms filled with computers… We had an “upgraded” studio with bedrooms, cooking room and all the services necessary to live inside it.
For this reason the most of the developers lived in the studio for a long period of time because we made a lot of crunch and after 14 hours of work people did not want to take a bus or the metro to return home so they lived in the studio.
We started to live like a family creating turns for cooking, washing the dishes, cleaning the rooms… it sounds funny and bizarre I know :D
These situations were very cool for the first months because we created a very unique feeling inside the studio and we shared life and professional moments that are hard to forget. After some months the routine and the differences between the nature of the team members lead to personal conflicts that influenced also the professional aspect.
Learnt:
Do not blend private life with work, even if your teammates are your friends.
Try to divide personal problems from development problems.
Making crunch sometimes is not bad, normalizing crunch in your routine is bad.
From on site to off site development
"A stumble may prevent a fall"
- Thomas Fuller -
After the cohabitation period in the studio, we have been forced to close the studio because the owner decided to use it for other purposes. Our economical conditions were bad and we did not find another cheap place, so we were forced to start a new journey: the mystical remote work. This change was the most difficult part of the development because we did not have experience in this type of work. In few days we removed all our stuff from the studio and we started to work alone, each one at their home.
The huge problem of this change was not the lack of management of the team work because with Asana we kept the project on track even in remote, the big problem was the lack of management of the personal relationship in the team. When we were in the studio all the members forced the others to work with professionalism and each developer felt a sense of belonging in the project, when you are alone in your home you have a lot of distractions (Facebook and Youtube tabs in the browser, phone messages…).
So the team member management has to become more accurate and precise in remote work otherwise the people get a decreased interest in the project especially if they do not receive money for their work (like in our project).
This error caused bad communication, misunderstandings, lack of interest in the project with the flow of the time and six months of delay.
Learnt:
Plan a very specific routine to manage the remote development before you start to work:
Choose what program to use to communicate (Discord, Slack, Skype…).
Choose what tool to use to manage tasks (Asana, Trello, Jira…).
Choose the day and the hour of the weekly meeting in which everyone has to partecipate (it is useful to play together the last build to remain updated about the state of the game).
When you work on remote you have to become the leader of yourself and a good leader for other members. Send messages to others to receive daily updates, transmit the interest in the project to the other team members even if they do not do these things.
DATA BOX
Developer: Hypothetical Games
Publisher: MACACO
Release Date: 5 October 2018
Platforms: Mobile (Android)
Team Size at the Beginning of the Project: 7
Team Size at the spikes: 12
Team Size at the End of the Project: 6
Length of Development: 1 month preproduction, 13 months production
Lines of Code: 1788
Development Tools:
Unity3D
MonoDevelop
Visual Studio
C#
Git (GitLab)
Sourcetree
Maya 3D
Photoshop
Affinity Designer
Google Drive
Fruity Loops
Ableton live
Audition
ABOUT THE AUTHORS
Federico Boccardo is a game designer and game developer with experience in PC, Console, Mobile and VR games. He has credits on games like Cube Up, RedOut, Super Inefficent Golf; The Wardrobe, Waking Violet and on game jam projects and prototypes like Pulse Wave Revenge; Gundropper; OverLife.
Get in touch with him on Facebook, LinkedIn, Instagram or at [email protected].
Nicolas Mihoc is a sound designer, composer and game developer who has gained experience in PC, Mobile and VR games. He has credits on games like Cube Up and on game jam projects and prototypes like Pulse Wave Revenge and Gundropper.
Get in touch with him on Facebook, LinkedIn, Instagram or at the good ol’ electronic mail [email protected].
Read more about:
Featured BlogsAbout the Author(s)
You May Also Like
