I have so many things to say in such a topic and the more I think about it, the more ideas I have .
I’m hesitating with:
- procedural map generation that I can’t make it to work because I was too stubborn on ideas
- dynamic generation of texture in Unity with multiple solution possibles but none worked
- the smallest bug fix I ever had to provide that took me too much time to find out
- creating a Super Nintendo game because I’m me after all and I like to lose my time apparently
But, I’ll go with the procedural map generation. If you want to know for the others, let me know, and I will speak my dev life.
It was a very interesting challenge/experience in my developer life that had a significant impact on how I see development. I was working on a personal project. Being overly influenced by the game Super Metroid, I wanted to build a procedurally generated map that sticks on a grid.
Basically, it should have to look like the following:
But I wanted to include my things in it. So, the first step was to do some analysis about what I required in this generation. I thought about it a lot, wrote the ideas on a textbook, gave them a try to see if it works.
Did that cycle about thinking, writing, coding, trying, failing again and again. Sometimes, I lost hope and gave up with that for months before retrying.
About 5 or 6 years spent like that (no joke). There was always a small issue somewhere that brakes the thing in a manner I couldn’t understand. The solution wasn’t ok obviously but why? I inspected the code in every single character it could have, spent a lot of time debugging step by step, recoding from scratch, changing its architecture, etc.
Nothing worked excepted removing the grid constraint but it felt unsatisfying to me and even more like a failure actually.
During these years I met a person in particular at a Game Jam. He was already working on a project for a video game that where sold on itch.io as a beta version at that time (now it’s even on Steam and Nintendo Switch btw). We were not part of the same team at that Jam. At a moment I took a look from far on his screen… He was already on a fine-tuning stage while with my team we were just struggling and had almost nothing.
Hard to believe, this combination couldn’t be possible: technologies not tailored for video games + dirty code. He actually had his constraints like everybody and this solution suits him. In the end, he had “dirty” working code and I had “clean” non-working code…
What’s the best?
Thinking about that, I considered another approach. This time, I won’t focus on code architecture and it doesn’t matter if I found the code dirty. Let’s just try to make it work and see.
I achieved my goals in two evenings (4 to 5 hours at most)…
I gathered a lot with that experience. Using a “dirty” approach first worked better because I couldn’t know what architecture to implement before identifying the solution I need. Only after, I could think about making it cleaner. Indeed, I was solving too much problem at the same time and not in the proper order making it impossible for me.
(I will put, for fun, a GIF later on when I’m back home to show you the result of that procedural generation and explain what to see.)
P.S: This code is still dirty today