Silicon Jelly started developing games for mobile about four years ago. Our first significant game Mimpi was successful and allowed us to continue our work. Looking back we can see a lot of mistakes we made. Of course we learned from them and tried not to repeat them in our current project, Mimpi Dreams a sequel that is in pre-release now. We believe you can learn a lot by looking at other people’s mistakes, that is the reason we share this with you.
The following article is divided into areas of development for your convenience. We always start with description of the problem and then explain how we addressed them in Mimpi Dreams.
Mimpi: Most puzzles were unique, which is a good thing for the player but it was very costly to develop. Also with some puzzle designs there was unclear communication that was complicating the development. Our coders sometimes did not understand exactly what designers intention was, so there was a lot of unnecessary work that had to be thrown away.
Mimpi Dreams: We designed the puzzles with the idea of re-using it on several places in game as prefabs. This way we were able to combine simple puzzles into more complicated ones. Also if we found out there is a place in the game where nothing happens, we were able to fill it up with content easily.
Example of a one-time puzzle in Mimpi Dreams.
Mimpi: was intended as a premium game. At the last moment our publisher advised us to go freemium asap after launch, so we added hints for puzzles as in-apps. This did not really work very well. With an exception of one short period, the game monetised much better as premium. Well, experienced developer should have these things figured out from the start, but hey, we were learning!
We also added some really hard puzzles mid-game to make players spend hint bulbs and buy more. That was perceived as paywall by the players and they were right. As an excuse, we can say this was our business guy’s idea. Don’t worry, he learned his lesson as well.
Mimpi Dreams: We designed this game as a premium game from the start. We try to make the players go through the game as smoothly as possible. That’s why the hint bulbs are scattered through the game quite liberally. We want our players to actually finish the game - to play all of it. In Mimpi, most people did not see some of the later levels. That was a pity as we spend a lot of time on those and the players just did not see it.
Mimpi: Not mentioning the paywall, we also designed a lot of difficult puzzles mid-game totally disrupting the learning curve. Also, levels two (!) and five were the infamous underwater levels, where Mimpi is in a bubble and If this bubble bursts he dies. The bubble can burst by touching basically anything. The player has to keep it from bursting and manipulate items in the scene in one time, which is really difficult for some and clearly impossible for others.
Mimpi Dreams: We concentrated on a very smooth learning curve in the sequel. We user test the game a lot to see whether there are some steps in the difficulty curve. If we find any, we get rid of them. Also we do not have any underwater levels and we concentrate really hard on making the player use just one control type. That means he either controls the dog or manipulates the environments. Never both at one time.
In water levels in original Mimpi, you had to control both the dog and environment around him, plus any contact of the bubble meant the death of Mimpi. Here you have to escape the fish by closing the clam by tapping it (it can kill you when closing), go behind it, it wait for it to open again and trap the fish by tapping the clam again. The whole time you have to keep Mimpi from touching edges. Pretty hard, no?
Mimpi: The game was all physics. All of the puzzles were physics based and the underwater levels were using different physics to simulate underwater environment. The game was therefore quite slow on older devices (which means most of the devices on Android).
Mimpi Dreams: Almost everything is an animation or clever scripting, even if it seems physical. We save a lot of computational power that we can use for shaders or particles. We have to make everything fall down or create friction by scripts, but it is much easier than to balance physics, especially in a game where a lot of situations or puzzles is one of a kind.
One of the more complicated and colorful puzzles, showcasing our fake physics, in Mimpi Dreams. And yes, it’s also crazy. Just to give you an idea...
CHARACTER CONTROLLER AND ANIMATIONS
Mimpi: Character animations were made directly in Unity and were not excellent. The character controller was also not perfect - Mimpi felt sloppy, slow and unresponsive. Some felt it fitted well with the dream theme of the game, but still, a sloppy controller in a platformer game is a big no no!.
Mimpi Dreams: The character controller was the first thing we developed. Then we created level topology and tested it against character controller. Also we hired very proficient animator who created about 100 animations - from quite a few Mimpi animations to enemy and environment animations. Mimpi now feels and moves very naturally.
This neat gif shows a representative subset of Mimpi character animations.
Mimpi: One of the trademarks of the game was the seamless, richly illustrated graphics. Those were created in SVG and imported via our custom plugin as 3D meshes. The problem was we had to refine the data a lot which meant any change to the graphics took us a lot of time.
Mimpi Dreams: Initially we intended to divide the graphic data into small chunks that would have been processed separately to minimize any effort to implement changes. In the end we ended up also significantly improving our SVG importer (seesvgimporter.com, it's awesome!) It is now able to import the data without any need to refine anything.
An example of a visually rich scene created for Mimpi Dreams using SVG importer.
Mimpi: Rich visuals were really a plus, but since the game was drawn first and then the topology (terrain colliders) was added, it was not always clear to the player what is a platform and what is not. That is a real problem in a platformer game. (See an example below).
Mimpi Dreams: We used Ferr2D plugin for terrain production. It allows you to create rich terrain while preserving visual richness Mimpi franchise needs. We added even more visual richness by placing many, many assets in the levels. We just paid attention for them to be visually clear. They are always clear about whether they work as a platform or not.
Ferr2D plugin is just awesome! It can manipulate terrain directly in live game to see the effect on your character.
In Mimpi, it was not always obvious where exactly can game character walk or where will he land after jump. The art style is fun, however.
We hope these lessons we learned the hard way will save you some trouble developing your game. Well, we tested Mimpi Dreams very hard, so we know a lot of issues we had are now corrected. We are going to release the game very soon, so please, stay tuned to see whether we did well.
EDIT: We released the game last week (March, 17) and the game sells significantly better, so everything we did obviously worked. Or at least we think it did!