Own game in 72 hours: rakes, crutches and alpacas

Gather a dream team, in one breath gash down a masterpiece game that will blow up the tops. Or, as befits a lone genius, overnight, to design and release into the world a game-phenomenon, a game - a magnet for money and fame. As it turned out in the smoking room and on a variety of IT mitapah, similar dark fantasies torment not only younger students, but also respectable uncles. It’s just harder for them to admit it.

How to be a developer whose career path is as far from game development as a Hobbiton from the Black Gate? To brush aside the obsession and finally finish the library that would have looked so good in the resume. But if to bury your own dreams is not your way, welcome under cat. An honest story awaits you about how Kick-ass from the IT world practiced in front of a mirror and stuffed bruises. The history of the game, from sketches to release.


From vague mental images to the finished concept

In the first approximation, the plan sounded like this: in the minimum time to go through the game development cycle, the final stage of which is the release of a full release.

Reasonable time limits and the need to publish the game contribute to the avoidance of a typical trap waiting for noobs in game dede: chase the “dream game” image! Most often, the “ideal” concept turns into a project unaffordable for an indie team. The very idea becomes a disadvantage, which sooner or later will be shamefully hidden "on the table."

In order to avoid an inglorious failure with the development of a submarine simulator or an online 3D shooter, it is better to postpone and release a simple game. By the way, simplicity does not mean a primitive hello-vord arcade, a stripped-down snake clone and other variations of non-playable and non-original handicrafts.

"Four in a row", a farm with butlers, Plants vs. Hamsters ... What exotic idea to choose as a trial balloon? Maybe something about the balls. And since this is the first pancake, then let the game be flat, in 2D. The motto of any questionable activities - less reasoning, immediately to the point. Therefore, the first relatively imputed idea was fixed. So, a sketch of a wild mixture of billiards and eyreokhokey in the setting of an ancient civilization:

The concept of the game

This arrangement of balls (zengs) at the height of the game. The player aims at the zenga-crocodile with a zeng-cat to beat him into one of six pockets and see a powerful special effect of the explosion. The one who knocks out all the enemy's zengs from the field is Etsvatsephala (a great lad). Oh yes. The setting of an ancient civilization is still behind the scenes.

Flour of choice: target platform and toolkit

After the concept of the game was drawn in general terms, it was not difficult to determine the platform and the toolkit.

Sight on the PC market is facing zamorochki with online distribution services. Take at least the Steam Direct system for publication in the most popular Steam store. A tax of about 6,000 rubles is charged for the addition of each product , and from the moment of payment to sending for publication, a month must pass, during which Valve employees "see who they are dealing with." On moderation of the game before the release takes about five more days.

Indie igrodel's collaboration with GOG.com, another giant in digital distribution, begins with filling out a questionnaire.about the game. It takes some time for the store to review the game, and the risk of failure to publish is quite high: the game may not seem to be unique enough, low-grade, or not to suit another criterion ...

Common sense dictates that it makes sense to contact monsters like Steam or GOG.com if you have a ready (or almost finished) product of appropriate quality. But the release of the game for a mobile audience - a faster and more affordable option. Of course, I am hinting at Android: a one-time payment of $ 25 for activating a developer account and access to the Google Play Developer Console is more expensive than the annual $ 99Apple for the possibility of publishing in the Apple Store. I have a Google Play developer account since time immemorial, and this has tipped the balance in favor of Android.

As for Android, the daredevils who fold onto the slippery track of development for this platform often find themselves at a crossroads: whether to fence a game into Canvas, learn the OpenGL API, or deal with a full-fledged game engine. For me, the choice did not even stand: it is easy to carry a mouse in a beautiful GUI engine - where it is more tempting than to spend the night in a debugger and investigate why the scene does not scale, it hangs.

Obviously, it was necessary to choose an engine that meets the requirements:

  • The ability to port the game for release for Android
  • Free
  • Low threshold of entry
  • Prototyping speed
  • Fresh, clear documentation or active community

After some searches, three engines were of interest: Cocos2D, Unreal Engine and Unity. Cocos2D impresses with lightness and C ++ as a development language, but writing a game on it does not promise to be speedy. The difficult choice between the Unreal Engine and Unity ended in a victory for Unity: when we first met, we had the impression that it was easier for a beginner to understand this engine. What is it worth at least a smart online tutorial on creating 2D-games!

For the indie developer, Unity is available under the Personal tariff plan, that is, for free. For companies whose annual turnover or the amount of funds raised exceeds $ 100,000, it is proposed to use a paid subscription. Well, as soon as, so immediately, but for now we start Personal.

On the development of the game alone: ​​where time disappears

As a result, throwing between different platforms and engines on a computer registered Unity 2017, Visual Studio Community and Android Studio. By the way, the official Unity builds are available for installation on Linux, and in my openSUSE Leap installed without any problems. However, most of the development of the game was conducted under Windows, because there is Photoshop. And the only developer of a part-time project is also the only designer, which introduces a special peck into the process of gamedev.

For example, one often had to switch between two tasks: writing code and drawing graphics. As soon as the development process was blocked by the need to add new graphics to the stage, it was necessary to put everything off and be engaged in design. For the parallelization of these processes, images “stubs” were actively used; they were thrown about somehow and to the last replaced the full-fledged graphics.

Phased development of graphics

Happened and falling into a creative dead end, when the graphics, which were considered final, caused rejection by the author or the players, and it was not clear how to correct the situation. Practice has shown that a couple of new concept art contributes to breaking the deadlock. They either tell you in which direction to redo the image, or completely replace it.

In any case, a huge amount of art will not enter the final assembly of the game, and this is normal. For from a ton of unsuccessful sketches, one is born that everyone looks at and says: “Yes, this is she. That same alpaca.

That same alpaca

But the playing field after numerous iterations of redoing:

Screenshot of the playing field

It turned out that out of 72 hours around 40 were spent only on drawing and design. The remaining time was spent on the development-testing cycle, the acceleration of which was facilitated by three factors:

Checkpoint of readiness of the game for release.It is not a shame to consider the game with which functionality to be complete, ready to be passed by the user who sees it for the first time? Does it cease to be so, if you give up one or two features? If it were not for the pre-compiled and mentally translated read-only TK, the game could have been improved and developed for ages. As they discussed with the players their impressions and the emergence of their own ideas, the new Wishlist appeared almost every hour, this was where the list of features for the control point was saved.

Rejection of beautiful code.One can argue with this, this practice can be considered harmful both for the project and for the developer, and I agree with most of the arguments ... But the fact is obvious: if the project is small and time is tight, then cleanliness of the code fades into the background. The main thing is that the source code can still be sorted out. And spaghetti code and fatty copy-paste are not so harmful if you do not order a double portion.

Polygon for running parts.An explosion of time spent on the explosion, but he still does not pull on the award for the best visual effects? Weirdness in the animation of the sprite became visible only now, because other objects were drawing attention to themselves? Debugging difficult sections, tuning special effects, running animation ... For such events, a good approach is to isolate the block of interest as much as possible and bring it to a clean project (or at least in a separate scene). Firstly, it excludes the side effects of other game entities on it. Secondly, it helps to concentrate on the current task, to experiment without the risk of nosyachit and break something in the neighborhood. For example, in a separate scene it was convenient to adjust the parameters of the effects of explosions when a zenga hit a pocket, and in a test project to select options for texturing the background.

Errors that never became fatal

Uncompromising falls on open beta, null reference ¬ Easter eggs near the lines with the phrase “// TODO”, escaping, like water through fingers, bugs ... The sad fact is that most of the errors are due to carelessness and lack of ownership of the tool. Unity has detailed documentation, and this is no accident. Many Unity technical solutions are not obvious. Clogging up documentation creates extra hours of debugging and wandering around Google ... which returns to online documentation.

Ladies and gentlemen, before you "Top-3" the most delicious and time-consuming mistakes that graced the development process of El Zengo. They are curious because they are special cases of typical problems arising from the rapid development of a lack of time for a detailed study of the subject area.

3. It does not work as I want

Ooh, how much time was killed to debug simulation of zengs collisions ... Of course, in Unity, the entire calculation of the movement of bodies works out of the box. And in the raw prototype of the game it was eagerly exploited: zengs rolled around the stage with zero gravity, bounced off each other and from the sides, and the question of their trajectories after the collisions was not. But the crucial moment of drawing the vectors of zengs came, and suddenly it was revealed that the actual bouncing of zengs from each other (gray arc in the screenshot) differs from the expected (white line):

Expected and actual bounce trajectories of zeng

Zeng deviated from the intended path due to too much friction and the resulting torsion moment, the reason for which remained a mystery for the time being. The fact is that each zeng is a gameObject generated when loading a scene, to which Rigidbody 2D and Circle Collider 2D components are added.

Rigidbody, “solid body”, determines the physics of an object's behavior in the game world: mass, resistance, gravity, and other useful characteristics. Collider is the component responsible for calculating object boundaries and collisions with other bodies. Both components have a “material” property to specify the coefficient of friction and elasticity.

So, the correction of an incorrect bouncing off of zengs came down to the question: if two components are attached to the gameObject, Collider and Rigidbody, and each of them has the “material” property, which material will be applied?

The “Material” properties of Collider and Rigidbody in Unity.

So, if Collider has no material specified, then the material Rigidbody is used. If set, then the Collider property is more important. For explicit material Rigidbody, the material with the default values ​​of elasticity and friction is used. Thus, the error was in the erroneous assumption that the Rigidbody property with near-zero friction would be applied with the specified Collider material. And it cost the spent Saturday night.

2. It behaves differently on different devices.

Different behavior on devices with different versions of the API appeared by chance, when drawing the shadows of the text. A text with the name of the game was added to the scene. Attached to the text component "Shadow":

Component "Shadow", added to the text in Unity

Dark color, transparency. Perfectly emphasizes the text on all devices ... except for the old Android with API 15, on which the shadow stubbornly looked pale blue instead of blue:

Incorrectly drawn shadow in the game interface

It was not possible to quickly determine the cause of the error and the ways of elimination .

Conclusion: stay alert. On different devices, even the trivial elements of the game may look and work differently. This is often manifested in hard-to-find details.

1. It does not start on a specific device.

On the night before the release (or how is it customary to start such stories?), It was discovered that on one of the smartphones the game basically does not want to start. I had to urgently cling to the debugger and watch what went wrong.

By design, the game is forcibly launched in landscape orientation. In Unity 2017, the Default orientation setting is responsible for this (Edit -> Project settings -> Player -> Orientation):

Setting the screen orientation in Unity

When exporting to a project for Android Studio, the default orientation setting turns into the screenOrientation property specified in the manifest:


It would seem that could go wrong? Indeed, on all devices, the flight is normal ... Except Android 8.0.0 (API 26), on which the application crashes with the exception when it starts up:

java.lang.IllegalStateException: Only fullscreen opaque activities can request orientation

Repaired by turning off transparency in the style specified in styles.xml:


Absolutely accidentally detected drop, pushing on morality: the correctness of the work should be checked on all API supported by the application.

About promotion and monetization, or “Today I understood a lot”

After preparing a thick pack of promotional materials to be placed in the Android store, a release was made under the joyful cries of the programmer and designer. However, it soon became clear that except for the name of the game in the Play Store is impossible to find. El Zengo, like a sunken galleon with gold doubloons, rested somewhere at the bottom of the ocean of games and waited for its diver ... Apparently, the divers do not dive so deeply.

Zero number of downloads per week went against the expectations. Remark: expectations were not baseless fantasies, but were based on real, though outdated, experience. Back in 2014, when Google Play was actively expanding and luring new developers, the author published a logical game for nothing. And although the main purpose of the publication was personal use for parties with friends and colleagues, and the design left much to be desired, the game went surprisingly smoothly. She loomed in the new section, from where she crawled to the tops of games by category in Russia and neighboring countries. And all this without the slightest effort.

Since then, Google Play applications overflowed, developers began to lay out huge amounts for evacuation from the bottompromotion to the top, and attempts to make the game known, so that, to begin with, a potential user could at least somehow find it, they came up against the business.

Elephant Business. The prince is waiting for an unplanned adventure.

Companies offering promotion services, video reviews from YouTube, reviews on gaming portals, advertising on various sites ... If you absolutely do not dismiss paid promotion, you will be pleasantly surprised by the number of ways to get rid of a couple of salaries with chic. But how effective are they, in what combinations and proportions they give the best effect for a particular game? The question remains open.

Tried free ways, including topics on gaming forums, moderately impudent public relations in social networks and rampant propaganda in the circle of communication, brought modest results. The conclusion suggests itself: if we think about the progress of the game, then do it in advance and allocate the appropriate resources. In this case, you can reduce all efforts to zero, if you do not be aware of market trends and characteristics of the target audience.


Is it possible for a couple of months to release the game yourself or a small team, not to the detriment of work and personal life? And so that without self-overcoming and “triumph of the will” over lack of sleep. Yes, it is quite! And using modern engines, IDE and stackoverflow are easier than ever.

But if the development of indie games is not an end in itself, and there are questions about its promotion and monetization, then ... there are nuances. Promotion - a monster about three heads: a separate science, in which a small miscalculation is already a loss; a continuous process that needs relentless monitoring; black hole for time, effort and money.

And finally. Indie development is not only code, graphics and geometry course, which would be nice to re-read. It is also communication with enthusiastic people who are ready to leave feedback and even participate in the project with pure enthusiasm. For example, the developer gave a ton of advice and criticism on the gameplay and the UI, in general, cool with casual casuals. And the music for the second version of El Zengo was created by the composer, who liked the game. If you try and look, you are sure to find those who want to test the game and leave a review. And with a good choice of tools and the observance of some simple fan rules from development, the release coverage and not weak pumping of experience are simply provided.

Also popular now: