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.
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: chasing the “dream game” image! More often than not, the “ideal” concept turns into a project that is 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 primitive hello-vord arcade, trimmed 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:
Game concept
This is the arrangement of balls (zengs) at the height of the game. The player aims at a zenga-crocodile with a zeng-cat to hammer it 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.
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.
The indie igrodel collaboration with GOG.com, another giant in digital distribution, begins by filling out a game questionnaire . Some time is spent on reviewing the game by the store, and the risk of refusal to publish is quite high: the game may not seem unique enough, low-grade, or not to suit another criterion ...
Common sense suggests that monsters like Steam or GOG.com should be contacted if there is a ready (or almost ready) product of the 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 budgetary than the annual $ 99 in the Apple bank 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, daredevils who fold onto the slippery track of development for this platform often find themselves at a crossroads: whether to fence a game in 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:
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 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.
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 do the design. For the parallelization of these processes, images “stubs” were actively used, thrown out somehow and to the last replacing the full-fledged graphics.
Phased development of graphics
There were also cases of falling into a creative dead end, when the graphics, which were considered final, caused rejection by the author or the players themselves, 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, it is she. That same alpaca.
The same alpaca
But the playing field after numerous iterations of redoing:
Screenshot of the playing field
It turned out that out of 72 hours, about 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 readiness of the game for release. It is not a shame to consider the game with which functionality to be completed, ready to be passed by the user who sees it for the first time? Does it stop being such, if you give up one or two features? If it were not for the pre-compiled and mentally transferred to the read-only state of TK, the game could be improved and developed for ages. As we 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 the purity of the code fades into the background. The main thing is that the source code can still be sorted out. A 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 into 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.
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: 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 tasty 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.
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 zero gravity scene, bounced off each other and from the sides, and the question of their trajectories after collisions wasn’t. But the crucial moment of drawing the vectors of zengs came, and suddenly it was revealed that the actual rebound of zengs from each other (gray arc in the screenshot) differs from the expected one (white line):
Expected and actual zeng bounce paths
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 the behavior of an object 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 define 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 of the materials will be applied?
Material Properties for Collider and Rigidbody in Unity
So, if a material is not specified in Collider, then Rigidbody material 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.
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. The “Shadow” component is attached to the text:
The “Shadow” component 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 how to eliminate it, so for the sake of speed of development, the shadow had to be abandoned.
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.
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 hook the debugger and see what went wrong.
By design, the game is forced to run in landscape orientation. In Unity 2017, the default orientation setting is responsible for this (Edit -> Project settings -> Player -> Orientation):
Setting screen orientation in Unity
When exporting to a project for Android Studio, the Default orientation setting becomes the screenOrientation property specified in the manifest:
It would seem that could go wrong? And indeed, on all devices, the flight is normal ... In addition to Android 8.0.0 (API 26), on which the application crashes when launched with the exception:
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.
After the preparation of a thick pack of promotional materials for placement 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 has been overwhelmed with applications, developers have begun to lay out huge amounts of money forevacuation from the bottom of the promotion to the top, and attempts to make the game known so that, to begin with, a potential user could at least somehow find it, run into the business.
Elephant Business. Prince is waiting for an unplanned adventure
Firms offering promotion services, video reviews from YouTube, reviews on gaming portals, advertising on various sites ... If you absolutely do not dismiss paid promotion, then you will be pleasantly surprised by the number of ways to get rid of a couple of salaries. 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 of three heads: a separate science, in which a small miscalculation is already a loss; an ongoing 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 on 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, an uplifting release and not weak pumping of experience are simply provided.
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: chasing the “dream game” image! More often than not, the “ideal” concept turns into a project that is 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 primitive hello-vord arcade, trimmed 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:
Game concept
This is the arrangement of balls (zengs) at the height of the game. The player aims at a zenga-crocodile with a zeng-cat to hammer it 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.
The indie igrodel collaboration with GOG.com, another giant in digital distribution, begins by filling out a game questionnaire . Some time is spent on reviewing the game by the store, and the risk of refusal to publish is quite high: the game may not seem unique enough, low-grade, or not to suit another criterion ...
Common sense suggests that monsters like Steam or GOG.com should be contacted if there is a ready (or almost ready) product of the 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 budgetary than the annual $ 99 in the Apple bank 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, daredevils who fold onto the slippery track of development for this platform often find themselves at a crossroads: whether to fence a game in 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:
- Ability to port games for release for Android
- Free
- Low threshold of entry
- Prototyping speed
- Fresh, clear documentation, or an 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 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 do the design. For the parallelization of these processes, images “stubs” were actively used, thrown out somehow and to the last replacing the full-fledged graphics.
Phased development of graphics
There were also cases of falling into a creative dead end, when the graphics, which were considered final, caused rejection by the author or the players themselves, 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, it is she. That same alpaca.
The same alpaca
But the playing field after numerous iterations of redoing:
Screenshot of the playing field
It turned out that out of 72 hours, about 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 readiness of the game for release. It is not a shame to consider the game with which functionality to be completed, ready to be passed by the user who sees it for the first time? Does it stop being such, if you give up one or two features? If it were not for the pre-compiled and mentally transferred to the read-only state of TK, the game could be improved and developed for ages. As we 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 the purity of the code fades into the background. The main thing is that the source code can still be sorted out. A 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 into 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: 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 tasty 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 zero gravity scene, bounced off each other and from the sides, and the question of their trajectories after collisions wasn’t. But the crucial moment of drawing the vectors of zengs came, and suddenly it was revealed that the actual rebound of zengs from each other (gray arc in the screenshot) differs from the expected one (white line):
Expected and actual zeng bounce paths
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 the behavior of an object 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 define 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 of the materials will be applied?
Material Properties for Collider and Rigidbody in Unity
So, if a material is not specified in Collider, then Rigidbody material 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. The “Shadow” component is attached to the text:
The “Shadow” component 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 how to eliminate it, so for the sake of speed of development, the shadow had to be abandoned.
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 hook the debugger and see what went wrong.
By design, the game is forced to run in landscape orientation. In Unity 2017, the default orientation setting is responsible for this (Edit -> Project settings -> Player -> Orientation):
Setting screen orientation in Unity
When exporting to a project for Android Studio, the Default orientation setting becomes the screenOrientation property specified in the manifest:
android:screenOrientation="landscape" It would seem that could go wrong? And indeed, on all devices, the flight is normal ... In addition to Android 8.0.0 (API 26), on which the application crashes when launched with the exception:
java.lang.IllegalStateException: Only fullscreen opaque activities can request orientationRepaired by turning off transparency in the style specified in styles.xml:
<item name="android:windowIsTranslucent">false</item> 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 the preparation of a thick pack of promotional materials for placement 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 has been overwhelmed with applications, developers have begun to lay out huge amounts of money for
Elephant Business. Prince is waiting for an unplanned adventure
Firms offering promotion services, video reviews from YouTube, reviews on gaming portals, advertising on various sites ... If you absolutely do not dismiss paid promotion, then you will be pleasantly surprised by the number of ways to get rid of a couple of salaries. 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.
Epilogue
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 of three heads: a separate science, in which a small miscalculation is already a loss; an ongoing 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 on 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, an uplifting release and not weak pumping of experience are simply provided.
Source: https://habr.com/ru/post/420775/
All Articles