I had to deploy my Go code very quickly at the beginning of this week. Unfortunately, even though I always prepared the deployment process at the beginning of the initial process of any project, I was not ready this time.

I did just this:

1. Created an AWS EC2 instance.
2. Created a GNU/Linux-specific 64-bit binary with a single command with the help of my Makefile.
3. Use scp to upload the binary code.
4. SSH into the EC2 VM and run the code with a single command.

That is all. (Not scalable, but most people do not need scalability.)

After creating the VM, the actual deployment is three-steps process. First, if you are a customer, you buy a hosting service from your provider. And if you do not build your code. You upload and run the code. It is that simple.

This resembles the days I used PHP scripts (remember PHP Nuke or Postnuke?) Even this page is being served by WordPress, which has the same deployment process. This kind of web project only requires a database connectivity configuration. It is done via web interfaces, so I can consider the product is running when you start the configuration wizard.

Language features are important for software developers, but the decision to purchase is mainly made by customers, and language rarely affects the quality of the software. (Developers can build good software products even with the .NET framework.) This makes the deployment process more important for the customer and the middlemen who sell the platform.

I have used the enjoyable Django framework for over 15 years. Django helped me to adopt the deploy first strategy. It was always harder to make things work when I was a newbie. Of course, platforms like Google App Engine and Heroku broke this unfortunate situation, but it is still hard for a customer if they download an artifact of a Python project and use it right away.

Go, or another language, whichever has an easier path to reach the customer will win the race for the next decades.

I have been thinking about this for some time. Godot 4.0 is just released and looks very promising. It is free software (as in freedom) and looks superior on GNU/Linux systems. So I could rely on only FLOSS software if I prefer Godot. But my final decision had to be something different.

One of the main reasons I decided to stick with Unity is that I am already familiar with it. I have used it for my other simple games and am comfortable working with it. In addition, starting from scratch with a new engine like Godot would require me to learn the ins and outs of the software – time that I don’t have.

Another reason why I opted for Unity is because of the limited amount of time I have to work on my game. Like many other developers, I have a full-time job during the week, so my weekends are often the only time I can work on my game. With Unity, I can quickly pick up where I left off and continue progressing on my project.

Godot is an excellent game engine in its own right. In addition, it has recently gained popularity among indie developers due to its open-source nature and user-friendly interface. Godot may be worth considering if you have more time or are looking for an alternative option.

Ultimately, deciding which game engine to use depends on personal preference and project requirements. Unity was my best choice, given my familiarity with it and limited free time. But I will for sure try Godot soon.

While searching for a solution, I found an article related to this issue. According to that article, Waifu2x is a tool to magnify low-resolution non-vector images. I used it a couple of times, and the result was impressive.

As they say on their website, they use convolutional neural networks (CNN) for this magnification. The tool does its job very quickly. I am even jealous of this product. I can develop one with a CNN and an autoencoder. Most probably, it will be easy to create a dataset for it. (Greedy side project alert!)

The current mobile game market is full of trash. I do not want to mimic those games. I will copy some of them for learning purposes, but my releases should not be alike.

I am a software developer. With the help of my daily practice, the coding part will be more accessible and less problematic.

Deciding the genre:

I need to pick something not very challenging. I need to be able to dream about it. I am not an expert on any game engine, so it should be relatively easy for a novice developer. Also, play testing will be one of the most time-consuming parts; if I do not like the game, I cannot dedicate my spare time. Based on these constraints, I am picking the dungeon crawl genre.

The assets:

I am not an artist in any way. Visuals, sounds, etc. I have no idea how to create it. I am not even good at picking the good one among many. (Good luck developing games with this taste.)

I will need to use a pre-made asset set. I browsed many asset stores, and it looks like Kenney has some fantastic 2D assets for my taste. So I will pick one or more and create my dungeons with their help.

The time plan:

There is no real plan for this journey. Also, the main aim of this journey is not to release a product. It is just for learning and the fun of the development process itself.

But all software projects need a plan and time budget. I foresee at least two years to release a product on a single platform. And with those two years, I will probably develop only the minimum playable game with 2-3 levels.

Expected delivery may look very far from now, but I must note that I have only weekends for coding and some evenings on weekdays. 

Also, I may need to develop some side projects to learn unrelated methods for this project. This one will be my main goal, but that does not mean it will be only a side project in these two years.

A name and a story:

I am looking for one. And I will share all stages of game design. But, if you are a novice game developer or designer, please do not take my journey as your guide. It will include more faults than correct actions.