Why indie projects don't live to be released

Recently, once again tried to participate in a small indie project.
I made a prototype with primitive graphics, the second partner had to bring improved graphics, but I could not, and I generally decided to write a short article about why I really want to, but I don’t. The article a lot of banalism, but who can come in handy.

1. Timing

Yes, and again, with time, everything flies by, from small projects to large ones, because obtaining high-quality gameplay is very difficult, and a lot of time is spent on remaking features and gameplay. But the root of evil is often stored precisely in the primary estimate of the timing.

Take a simple prototype of a clicker - tap on the screen, the hero peeps a monster with a sword and skills. Everything is super simple, most developers assessing the scale of the prototype will say that such a task can take from several hours to a day / couple.

But! Let's carefully consider the minimum amount of work:

Code
')

1. Interface system (you need to be able to display all the necessary info)
2. Loading levels
3. Loading / pulling graphics (there can be many reusable effects / resources in the game)
4. The main character and his skills
5. Enemy
6. Attack system
7. The system of passing levels (should increase the complexity and collect level graphics)
8. Scoring system
9. Player Upgrade System (skill and level bonuses)
10. Voice system
11. The system of charging / expenditure of resources (the player can have skills for mana or on triggers)
12. Player data storage system (it is necessary to store progress)

Interface

Even a prototype requires a minimal interface, but if we consider a prototype / PoC (proof of concept), it is desirable to have a tasty design and a normal UX. The minimum that is needed:

1. Main menu
2. combat interface (with scales of health, exp, progress level, mana scales, charging skills, etc.)
3. about the victory in the current round
4. loser popup
5. lvap popup
6. player upgrade interface

Graphics and Animation

It's less clear

1. Graphics of at least three enemies
2. Graphics of the protagonist
3. Graphics to generate levels
4. level graphics animation
5. For each skill you need an animation (here you need to multiply by the number of skills).
6. Basic attacks require animation (there should be many variations of basic attacks so that the user does not get bored looking at the same sword swing)
7. Character victory animation
8. Character Loss Animation
9. Enemy attack animation
10. Animation of getting the opponent's damage
11. Animation of the half-dead opponent
12. Death of the enemy

Special effects

1. indication of damage (any tsiferki, shaking, redness of the screen)
2. use of skills (for each skill)
3. indication of receiving damage (blood / spark / smoke)

Sounds

Just look at the previous lists and add sounds to the entire graphics, interface and special effects. It takes a lot of time.

What are all these lists for?

To show the primary volume that needs to be cranked in order to get at least some kind of playable prototype, which can be called a game. I did not take into account the localization and a lot of other work, but the main idea that I want to bring is the primary amount of work.

I brought a small rule - even a small task can easily leave from one to two hours. Very few people are indie developing full time. Many of which I know are combined with full-fledged work. That is, development takes only free evening time on an indie, I have about 2-3 hours, I think most of them also really. 1+ simple task per day. A complex task can take several days. Not every day it turns out to work on a project for various reasons. As a result, the volume in the lists is higher - this is more than a month of work, despite the fact that everything is going well, and all the pros. And this is just a prototype. And then you need a more complex system of upgrades, even more graphics, bring different gear that affects the attack / skills / hp / hired heroes, hiring heroes to help the player, different game modes.

Developing a nice prototype of a super simple clicker can take a month or two, it’s extremely easy, although as I wrote above, at first glance there’s maximum work for a couple of days. And if you take the beta - it can take a year. Delaying the process is frustrating, and people begin to fall off. This is provided that all more or less experienced developers. And here we go to step 2.

2. Competences

Alas, a good programmer does not mean a good indie developer, as well as a good artist / modeler / animator, etc. In indie design there are a lot of beginners, and a great artist who draws very well may not be able to properly prepare the graphics for the engine used. There will be a lot of mistakes, reimports, reconfigurations, reanimations and a lot of any bug related to the graphics import curve.

As for programmers, an excellent C # programmer who does not know Unity3d will write a bunch of his bikes and solutions that will duplicate Unity functionality and not the fact that they will work well. Because the programming paradigm in pure sharpe and inside the unit is quite significant.

Further, if something from the lists above is done for the first time, then it will take time to do a copy, which again multiplies the development time. Therefore, in the end, even on simple tasks it takes not a day, but three. And we again get stretching terms. For burning young people it will be a necessary experience, and for veterans it will be another disappointment.

3. Results and tips

The results are simple - even a small project easily turns into a long-term project, people burn out when they do not see a fervent result, the project merges into a basket.

Therefore:

1. Carefully evaluate the real primary amount of work, often where you think work for one day, there may be work for 1 month as a team, when all this is delayed - the team may not sustain and fall apart
2. Try to accumulate and reuse solutions, it is not only about developments, but also about training materials
3. The primary prototype may be with a minimum of graphics, but the graphics must be lively enough for the prototype to be liked - you need animations and effects. Graphics should be exactly so much - to like and feel that same gameplay.
4. Lead the development publicly, lay out the project progress in the community and on the forums, break tasks so that the result is most obvious. This will create that very feeling of the right movement of a living project. And the team will understand that their work is not in vain.

As for the advice, I will be happy to hear your interesting experience in moving the indie project to release. From the point of view of the organization of the process.