As a child, I already found it fascinating how a few lines of code could make objects move on the screen, as if these objects came to life. It was so exciting to create my own world and see that it worked. It was like a playground where I could unleash my creativity and imagination to experience new adventures with the help of technology.

Have you ever programmed a Snake clone or Tetris clone? I suppose these are some of the games one would typically program when embarking on the journey to create their own game. At that point, you realize that programming a menu may not be as thrilling as you initially thought.

Programming is not just about entering code into the compiler. Code input is not the first step in development. If you start too naively, you may find yourself rewriting many parts of your code in the middle of development. That's when you realize the importance of cleanly separating classes because changes made in one part of the code can have consequences in another part. Suddenly, you're faced with a mountain of tasks that need to be solved.

During the development of the game "First Strike - Firestorm," there is a part where an enemy can hit and damage another enemy with its projectile. When everything was finished, and I reached that enemy while playtesting, it turned out that it was destroyed by its own projectile. That wasn't intended. I simply forgot to include a check in the code to verify if the projectile was fired by another enemy, and only then register a collision. The solution required some clever tricks.

Then there was a problem with the power-ups. The player has the option to choose one out of three power-ups. If the player is skilled enough and manages to position themselves in the middle of the power-ups and stay there for a few seconds, they receive all the power-ups. That was the idea. However, it could happen that if you failed to stay in the middle but some time had passed, and you collided with one of the power-ups, you still received all of them. The problem simply stemmed from poorly thought-out logic. I had to reprogram the entire power-up system. You can imagine how frustrating that can be.

Sometimes, even when you think of everything, problems can still arise. One such case was the collision detection for the player's projectiles. I did everything as instructed in the documentation or as seen in one of the many tutorials on the internet. However, occasionally, when the number of projectiles increased, some of them managed to pass through the enemies without triggering a collision.

There are moments in indie game development when motivation alone is not enough to continue working on your project. The collision issue was a point where I didn't feel much desire to complete the project.

In such cases, it helps to persevere, tackle the problem anew, take notes, and search for solutions within certain limits.

I found the solution in reprogramming the collision detection using rays. Each projectile creates a ray from its current position to its previous position. If the ray collides with an enemy, the system registers a collision. In the subsequent test, no projectile was able to pass through the enemies anymore.

With this text, I just wanted to briefly summarize the problems that can arise during game development and highlight that good planning is crucial but doesn't always allow you to foresee everything.