Dream game development. Part 2
A year ago I wrote an article about developing your own “dream game”. I advise you to read it first to better understand the context of what is happening. A lot has changed since then, and it’s time to tell about it.
What happened this year? Yes, to be honest, a lot. And in this “much” the development of the game somehow got lost. It just so happened that in the first half of the year there were more pressing problems and the development of the game proceeded, but rather slowly. And in the summer I went to work in Gorny Altai, and development stopped. But death did not overtake the project, as might have been expected!
In September, I began developing the game with renewed vigor! The project underwent a “soft” restart and the most striking innovation was the move from GDevelop 5, in which the game became, frankly speaking, cramped on Godot 4.3.
An attentive reader may ask: “You wrote in the first part that Godot was not suitable for development. What has changed?” My answer is that since that moment, many tutorials and articles have appeared that help in development, and the engine developers have fixed the most critical problems. As a result, developing on Godot 4.3 is a completely comfortable experience. If I have problems for which tutorials have not yet appeared, then Claude 3.5 comes to the rescue, which can surprisingly explain incomprehensible topics in a very clear and detailed manner. But let's get back to development.
In a couple of months, I redrew all the assets from scratch. Since the project acquired 3D graphics after the move, it follows that 3D models also appeared. I chose BlockBench as the modeling program. Why not Blender? The thing is that for my project its functionality is redundant and will only slow down development. It's like hammering a nail with a screwdriver.
The first thing I did was develop a level generator – the game is in the roguelike genre. Initially, I implemented the creation of a landscape by generating noise and creating a mesh based on it. But this solution had 3 problems:
High system load
Inability to generate navigation mesh. At least it didn't work out for me
The overall dullness of the resulting environment
The solution turned out to be simple – make a generation from pre-made tiles. Due to this, it was possible to kill all the birds with one stone, and the code turned out to be simple and easily extendable.
Over time, I rewrote the pathfinding code of my opponents. I started using vectors instead of NavMesh. It may be less precise, but it provides higher performance, and less on-rails behavior.
At some point I realized that due to the fact that the player’s bullets, when shooting left and right, did not fly exactly in the direction of the cursor. This was due to the fact that only the horizontal coordinates of the cursor are taken into account, and the camera is located above the character at an angle. I solved this by adding an aiming point directly on the plane at the real coordinates of the cursor, while hiding it and replacing it with a fake one, which is aimed at a point on the plane. Overcomplicated? Yes. But I was never able to force the camera angle to be taken into account when calculating cursor coordinates.
After that, I added various small gameplay features, such as the ability to hide in the bushes from the enemy. Just like in a series of games from a well-known genius 🙂
When can we expect the release? Well, I came up with a great motivation for myself – I tied my thesis work to developing a game. This factor will motivate me to complete development within the next six months. Well, or he’ll drop out. One of two.
I don’t have many distractions – just trips to couples and capitalizing on the engine of my Japanese swallow. So there are no obstacles to completing development within the given time frame!
I hope this article was interesting and informative!
