Blokci: The Story of My First Game

During my high school days, I used to play a game on my Symbian 9.4 phone where you stacked blocks to build structures. The challenge was to align the blocks closely to make the building stronger and harder to collapse. This simple concept brought a lot of satisfaction, and I fondly remember playing it with my dorm roommates.

Years later, I looked for a similar game on the App Store and Play Store. Although I found some, they either had too many features or lacked the original game’s charm. Even finding what seemed to be the original game didn’t recapture the same feeling, likely due to resolution and optimization issues. That’s when an idea struck me: why not create my own block-stacking game? With my coding skills, access to almost free game engines, and countless free assets available online, it seemed feasible. How hard could it be?

As it turns out, it was quite challenging. After some research, I chose Unity, which at the time seemed like the best option for a beginner, as it has strong documentation and an easy-to-use suite. This was before the controversial licensing decisions, so Unity had a good reputation in the developer community. Along with some other wrappers for C/C++ or JavaScript, Unity works with C# which I had not coded before but seemed to easy to learn and create something as a side hustle. Unity uses C#, a language I hadn’t coded in before, but it seemed easy to pick up for a side project. The platform also has an extensive asset store, providing a wide range of paid and free assets from audio to textures or sprites.

The prototype of the game came out surprisingly fast. It was a rough, playable something but not a game. And that was the time that I started to realize the difficulties. The first major challenge was to manage the physics. For instance, determining whether a block was still falling or had landed, ensuring it was properly stacked on another block, and managing space for new blocks were all tricky problems to solve.

Once I fixed those technical problems, I faced another challenge: the game’s appearance. It was, frankly, ugly. I had used various free assets from different sources, created by talented people supporting the indie game community. However, I struggled to combine these pieces in a way that matched my vision. Then another idea struck me: what if I created the art myself? It shouldn’t be too difficult, and I do know some Photoshop, right? But as it turned out, art is hard.

To be honest, technical knowledge of tools like Photoshop, Illustrator, or even Paint can help, but they are just tools—like brushes and paints for an artist. No matter how proficient you are with these tools, deciding on object sizes or selecting colours is still challenging. Fortunately, a helpful part of these skills can be learned. I started by understanding the basics of colour theory, watched numerous YouTube videos on creating flat art in Photoshop, and sought inspiration (which is invaluable when you’re an engineer trying to make art). In the end, I managed to create an acceptable version.

Then I thought, “What about monetizing it?” I looked into it and found that Google AdMob SDK for Unity was quite simple to integrate. It seemed to work fine on both Android and iOS. However, it came with its own challenges. For instance, I wanted to prevent users from bypassing ads by sending the app to the background. Despite the documentation suggesting that this was possible, the Google team maintaining the SDK decided to remove support for this feature without any explanation. I eventually came to terms with this and added ads to my game, then began considering its release.

Android Play Store was my first target since a Google Developer Account is cheaper than Apple’s. I created my account and started setting everything up according to the guidelines. Then I encountered a strange warning: all new personal developer accounts must conduct closed testing, which requires at least 20 testers to test the app for a minimum of 14 days. Even though I understand the motivation behind this decision which is clearly to make the Play Store a cleaner market, I don’t think 20 test users is a feasible number for any individual developers when you consider they would need to provide proper feedback in a structured way which is also required by the reviewers. I tried to hire a cheap testing service from Fiverr –a freelancer marketplace– but it did not work out as they could not give proper feedback that I could report during the production application. Honestly, it was a bit discouraging then.

However, I didn’t give up and instead released the app on Amazon’s app store. Although it’s not widely used except on Amazon’s own devices, it was at least available on Android devices, and the game went online in a couple of hours. Knowing that the user base would be limited, I had another idea: why not create a WebGL build and host it as a static site? After a few small JavaScript adjustments, it ran smoothly in browsers. I created a subdomain and hosted it on AWS using S3 and CloudFront, which is necessary if you want to serve using SSL; otherwise, S3 and domain routing would be enough. As I said, creating a game wasn’t easy for me, but it was more fun than hard. The game itself is a simple endless high-score game, not a big deal, but the process was a significant experience for me. I learned a lot. If anyone wants to create a game without any prior knowledge, I would suggest going for it without hesitation. It won’t be easy, but I assure you, you’ll have at least as much fun as you would playing a game.

Thank you for reading. If you like to try my game, here is the link: https://blokci.alatas.dev. If you like to try the Android version with ads you can download it from here on Amazon’s store. Feel free to give any feedback via email to enes@alatas.dev.

  1. https://www.youtube.com/@thomasbrush
  2. https://docs.unity3d.com/Manual/index.html
  3. https://opengameart.org
  4. https://www.youtube.com/@NemanjaSekulic
  5. https://www.amazon.com/Blood-Sweat-Pixels-Triumphant-Turbulent/dp/1538453932