The principles of minimalism in developing games for mobile platforms

Preamble

At the end of last summer we decided to make the continuation of our game Papa Penguin as a full-fledged new game. Initially, we wanted to change the existing idea only slightly and launch a more serious project based on it, which uses our ideas, but we did not sufficiently thoroughly approach preproduction issues and did not define the focus and basic gameplay of the project quite clearly from the very beginning. As a result, the game was not as concise and solid as it could have been, and the development of the game was delayed. Moreover, not all of the planned features were implemented, and during the development process we had to stop several times, revise the results and simplify both the idea itself and the level design, interface, etc. The last simplifications were made after tests and reviews. The result was exactly Captain Antarctic, and not Papa Penguin 2. Frankly speaking, I am not completely satisfied with the result. Although the game was very interesting, much of it can be simplified and improved (which we will try to do in the next update).

There was a question about creating a new small game. And in order not to repeat the experience of the previous one, I sat down and wrote a list of requirements that need to be kept in mind when starting production of a small project for iOS. Of course, he considers that developers should already have some experience and their own achievements. Without them, some items do not make sense. In addition, the list is not focused on all genres, and is largely determined by our games. But I think everyone can learn something from him.

So, in order:

1. Minimalism ideas

• The idea of ​​the game should be simple and clear to the player.
• The idea should be so simple and short that the player could instantly share it with others (which contributes to the spread of the game).
• The idea should directly support the simplicity of the gameplay.
• A simple idea should sink into the soul of the player and be remembered for a long time.

An example of this is Tiny Wings.

')
and Angry Birds.

2. Minimalism design

• The gameplay should be as simple and clear as possible without prompts and training.
• Management should be simple and suitable for most players. It is undesirable to make several management options. It is desirable that management was carried out just as easily on other platforms, so that when porting you do not have to invent new things.
• The gameplay and game session should be short, but the gameplay and the rest of the infrastructure (for example, a store) should give the opportunity to replay again and again (endless mode or the possibility of continuous improvement of results).
• The level should be designed so that it is always easy to make changes and test them.
• There are no parametric missions within the game at the same time as achievements. Why two things if they actually do the same thing (JetPack JoyRide)?
• The process Game-> Improvements / Store-> Game-> ... must be fast, as simple as possible and intuitive.
• The store and the goods in it should be simple, so that you do not need to explain what kind of product it is and what it provides to the player, but nevertheless leave the player a choice.
• The menu should be as simple as possible transitions. It is desirable that in general there were 3 screens: the main menu, the store and the game itself.
• The game should be as small as possible text (ideally, only the name of the game and the authors). Everything else - visually (icons, arrows, etc.) and intuitive. This minimizes localization work.
• The design should have as few numbers as possible - this simplifies setup. And, of course, as few numbers as possible (except for statistics) should be provided to the player for processing.

Under these points (but not all) I would sign a JetPack JoyRide


and Run In Crowd.

3. Minimalism in graphics

• A small number of objects on the stage / screen.
• Objects do not have to be huge. In the extreme case, they should be built from smaller ones (we reduce the size of the textures).
• Simple and memorable appearance of the protagonist.
• The main character should have such a form and shape that its animation was simple, but fun (as little as possible of animation work).
• Fuzzy, no detail background (you can put the compression).
• GUI elements should use generally accepted standards (type of icons, for example). No need to reinvent the wheel.

Cut the Rope


and Contre Jour.

4. Minimalism of programming

• maximum use of current practices.
• simple design should lead to simple algorithms and data structures.
• the smaller the code, the smaller the size of the application.

I would add here all the sequels of Angry Birds, Cut the Rope Experiments and Mega Run.

5. Minimalist sound design

• Light, non-bothering background music that everyone will enjoy.
• A small amount of sounds (they load the processor and increase the size of the build).
• Sounds should be simple, not distracting and not loading, but immersed in the gameplay.

Contre Jour, Cut the Rope.

6. Other (additional) requirements:

• It is desirable that the application was universal, since individual versions have to build longer and harder to maintain. Whether it is reasonable from the point of view of marketing is a moot point.
• The application should be designed for the widest possible audience.
• Retina display support.
• Well, if the application supports all existing Apple devices on iOS (we will please everyone) and works on them without brakes.
• The total size of the application should not exceed 50 MB (for iOS> 5), and even better if it is less than 20 (for old devices that do not support iOS 5).
• The application should not have platform-specific elements, which will allow further distribution to other platforms.

The main result: all unnecessary elements must be removed immediately. If you remove an element, and it turns out that you can do without it, then, most likely, it is not needed here. I remember the story of Steve Jobs, when the developers for a long time thought about the interface of the program for writing files to disk. In total, Jobs removed everything from the interface, leaving only the large “Record” button, and the files just had to be dragged. At that time it was revolutionary.

Perhaps, much of what is described here, at first glance will seem trivial, but if during development you do not constantly keep such a list in your head and do not control yourself on it, it may turn out not at all what was expected. I propose to discuss these requirements together, add something, and refute something. I will be glad to know the opinions of other developers with experience in the industry.