First, what do I mean by reboot? A game reboot is a rework of the core, fundamental aspects of the game in terms of gameplay and technical structure. The story, or more precisely, the main narrative, has not been and will not be affected.

This means that most game mechanics will be changed/reimagined/recreated from scratch from a technical standpoint.

The decision to reboot the game was made for several reasons that seem quite important to me.

1. The game's code architecture is incredibly bad. It so happened that Dreadshot was my first truly large project, and when I started working on it, my programming skills (even visual programming, which is primarily used in game development) left much to be desired. Over time, I learned to make the code better, more structured, more understandable, more optimized, and more scalable. But I also made mistakes, many mistakes, and this whole pile of errors has lingered until now. My task in relaunching the game is to rewrite the entire game code (or most of it) from scratch, improving its systemic structure and architecture, so that it can be expanded further.

2. Gameplay-wise, the game was too... generic. The game currently has a ton of mechanics thrown together haphazardly, but it lacks anything outstanding. Something that would truly set it apart from others. After thinking about this for the last month, I believe I've come up with a solution to this problem, in the form of a single key mechanic that will drive a huge portion of the gameplay. But I'll talk more about it once I implement it (hopefully in the next blog post).

3. This is a combination of the two previous points: the new fundamental mechanic I've come up with affects a huge number of existing mechanics from a code perspective, but the code itself isn't currently designed for this mechanic and needs to be massively reworked to accommodate it.

I can't say with certainty how long it will take me. I'm currently deciding on an approach to developing the new structure. This choice will determine how long it will take.

• I can either create my own architecture from scratch, which will be entirely my own. It will take a fair amount of time to create such an architecture, and I'm not guaranteed to be able to make it as high-quality and scalable as possible given my skills. On the plus side, I'll be able to leverage existing code more extensively, and the system itself will be more intuitive for me.

• I can choose the "industry standard" and use the GameplayAbilitySystem—it's an extremely large-scale system within the game engine itself that automates a huge number of processes. However, since it's so large, I need to study it thoroughly and learn how to use it. The hardest part is the learning curve, as some developers take 3-6 months, which is simply unacceptable in my situation.

I will most likely choose to create my own architecture, but at the moment no decision has been made.

The first half of fall was extremely productive (which can't be said about the second half, due to the school year and some personal issues). Here's what I did (the highlights are what's truly important for the game's future and will likely remain for the next year):

• Improved game optimization

• Fixed some bugs

• Created an enemy spawn system

• Updated the shotgun model and animations

• Improved the game's lighting and visuals

• Moved the rocket launcher to a new animation system

• Worked on the game documentation

• Worked on the concept for an improved interface

As you can see, quite a good job. Let's go over the most important and interesting points in more detail.

The enemy spawn system was a lot of fun to work on. The gameplay concept is that as the player progresses through a level, they'll enter rooms where enemies will spawn at predetermined points. Spawns will occur in waves. The key here is to create a clear and optimized system, as spawning and removing enemies is a very resource-intensive operation, so it was important to me to eliminate any possibility of spawn lag. To achieve this, I use a special technique called Object Pool, which allows enemies to appear in the level as it's loading, and at the right moment, they simply teleport to the correct point and become visible. This eliminates lag during gameplay while still allowing for the ability to determine in advance where a specific enemy will spawn.

The shotgun was one of the oldest weapons in the game and was in need of an update. Furthermore, its model was too bulky for a mid-range weapon, so it was scaled down.

Old shotgun version

New shotgun version

Until mid-fall, the game's documentation left much to be desired, as I was mostly keeping all my ideas in my head. Because of this, development was disorganized, and I often just did the first thing that came to mind.

For those who don't know, documentation is a series of text files that outline the entire content of a game: mechanics, descriptions, plot, technical implementation, and so on.

Currently, I'm working on documenting the gameplay specifically. I want to clearly define what I'm doing, to avoid moments where I'm doing something I don't even know what I'm doing. I think having everything written down on paper will give me a clearer plan and the tasks I need to complete.

I write the documentation using Obsidian, and it's perfect for my needs in terms of organizing the documentation file system. I can even visually show the current scope of the documentation without showing the actual documentation. Here it is:

A white dot is an existing file with information.

A gray dot is a non-existent file, but is referenced.

A yellow dot is an application (image).

A green dot is a tag that groups multiple files.

This documentation will only grow in the future, and I think I'll show you its growth in the next blog post, so you can appreciate the scale of the game on paper.

The interface is a crucial component for communicating mechanics to the player. Since I was planning to introduce a completely new and global mechanic, I needed a way to communicate this mechanic to the player.

Additionally, I immediately took into account that the game is story-driven, meaning it will have dialogue, bosses, a speedrun mode, and so on. Therefore, I needed to consider the possibility of all elements being on screen at once.

And here's what I came up with:

It's worth noting that it's quite rare for everything to be on the screen, and it may only appear cluttered at first glance. In reality, in most cases, the screen will be missing a boss bar, subtitles, timer, and money counter, so keep that in mind.

By the way, I've moved all the most important data (HP, Stamina, ammo, current weapon) to one corner so the player doesn't have to flick their eyes around the monitor and can get all the essential information from one place.

And yes, this isn't a design, it's more of a layout of the elements. The design itself will look more futuristic, resembling the interface of some futuristic helmet. Accordingly, there will be more decorative elements on the screen, but in a way that doesn't overwhelm the player with information.

We're facing a very, very difficult period right now. Rebuilding the game from scratch is a very painstaking and lengthy process, which I'll have to go through myself. Honestly, I'm feeling low mentally right now; I'm exhausted because I see no progress in development, and that makes me sad. But I hope I can overcome this, and the project's future will be bright.

• Rebuild the game.

• Implement the mechanics that will be decisive in the game.

As usual, I'll share with you the current wishlist statistics.

The game is currently on 7,232 people's wishlists, an increase of +622 people.

Thank you for your interest in the game; I'll try not to let you down! See you at the end of winter!

Vladislav ZenDev, 2025.

Hello everyone! Thank you for following the development of Dreadshot. I'm a bit late with this post, nevertheless, summer is over, which means it's time to sum it up and lay out plans for the autumn season!

As usual, let's discuss what tasks were completed during the summer season and which ones remain:

• Music System

• Full implementation of the railgun AK-72

• Full implementation of the new revolver

• Full implementation of WMPv2

• Full implementation of WM_BOmB

• Redesign/Rework of the shotgun, BBHML, and katana for the new animation system

3 out of 6 items completed!

Besides that, I did some work on the game's visuals!

Namely, I changed the look of the dashes. Here's how it looked before:

And here's how it looks now:

I also updated the robot death effects. Here's how it looked before:

And here's how it looks now:

There are also some other visual changes, like effects from bullets hitting surfaces, which you can see in the video above.

But all that is just visuals, not that interesting, right? Then let's move on to something hotter... Like WMBOmB.

I wrote about it in the previous report. There I described its general functionality and what you would be able to do with it. Now, I've added all of it into the game.

WMBOmB is an enemy that will constantly chase the player, and when it gets close, it will jump towards them and explode, dealing significant damage. It's fast and small, making it hard to hit. However, it only takes one hit to make it explode.
Also, if the player is agile enough - they can catch the moment when WMBOmB jumps towards them and kick it in mid-air (if the kick is equipped). Then WMBOmB will fly towards the point where the crosshair is aimed and explode upon impact with a surface.

But you know, the explosions from WMBOmB weren't enough for me, so a full revolver rework was implemented: from the model and animations to the mechanics. If before the revolver was quite dull: on RMB (alternate fire) it just quickly fired the entire round with a small spread, which was quite useless and boring, now on RMB (alternate fire) it tosses a pack of dynamite in the direction of the character's movement vector. And the dynamite has huge potential for mechanics. For example, if you shoot it with the revolver - it will break into several smaller dynamite charges that cover a fairly wide area and can help against a crowd of enemies. And if you shoot the dynamite with the BBHML - a more powerful, red explosion will occur, dealing more damage and having a larger area of effect than the regular dynamite explosion, so it can be useful against bosses with a lot of HP. By the way, a regular explosion will occur if you just throw the dynamite and leave it alone. It will explode a couple of seconds after contacting a surface. Well, you can also kick the dynamite like WMBOmB, and it will behave the same way: fly towards the crosshair and explode on contact with a surface. Overall, the revolver turned out to be extremely interesting and functional, however, it still needs attention. At the very least, I need to figure out a system for reloading the dynamite. For now, I'm leaning towards the dynamite being usable once every 5 seconds, and it will passively recharge, but I might change that.

I didn't limit myself to just the revolver when updating the arsenal. So, I finally fully implemented the AK-72 assault rifle, which I also talked about in the last seasonal report. The only thing is, I changed the mechanic: hitting enemies charges the cores for the railgun. There are 3 cores total, and the more cores charged - the more powerful the railgun shot will be, both in damage and explosion radius. Yes, all railgun shots create an explosion, the size of which depends on the charge level of the core. The system is quite smart because if you have, say, 2.5 cores charged, only 2 cores will be spent, and 0.5 will be saved, so you'll only need to charge another half to fire the railgun. By the way, the AK-72 is currently the only weapon that has spread. I didn't add spread to other weapons to make the game less dependent on RNG, and also because the weapons up to this point were only semi-automatic. If the AK-72 had no spread - it would be a dumb laser gun that would be too easy to shoot. So, there is spread, but it's not constant. It gradually expands depending on how long the weapon has been firing non-stop. And if you stop firing even for half a second - the spread will gradually return to its original state, and you can continue accurate fire. For exactly the same reason, because it's an automatic rifle - I added a slight distortion to the firing sound when the magazine is low on ammo. This is done so the player can determine the remaining ammo by sound without looking at the interface. I liked this feature so much that I also added it to pistols that fire fast enough, making it sometimes hard to keep track of the ammo count. I think the AK-72, thanks to its railgun, has very good potential for interaction with other weapons, for example with BBHML rockets and the revolver's dynamite. Besides that, there might be potential for movement, as explosions created by the player don't damage them, and you could use the railgun explosion to gain speed.

For the most part, that's all the new stuff that was added, but there's one more thing... Game optimization. I started noticing that the average FPS in the game began to drop, and stutters became more frequent, which are quite annoying. I already have some assumptions about why this is happening and a rough idea of how to fix it, even though it will take quite a lot of time. I won't go into technical details here, I'll just say that game optimization is an extremely important task, and I will try to make it as good as possible within my capabilities.

There's also another piece of good news: the project has received quite stable funding! It's all thanks to my media profiles on social networks; I got advertisers there, and the revenue from them provides me with the necessary minimum to fund my game. This means I can now devote all my free time to working on the game and its content, which is very encouraging.

The plans for the autumn season are Napoleonic (ambitious). We need to consider that I only have 2 out of 3 months free, as I have university exams in November, which will take a significant amount of energy and time. So, during September and October, I need to try to complete as many of the following tasks as possible:

• Music System

• Full implementation of WMPv2

• Redesign/Rework of the shotgun, BBHML, and katana for the new animation system

• Enemy spawn/respawn system, spawners

• Reduce the number of dependencies between objects in the game for the sake of optimization

• Add more weapons

• Add more enemies besides WMPv2

• Start designing levels for the story campaign

• Main character model (for promo + cutscenes)

• Fully write the game's story

• Weapon and skills merchant model

• Create a skill upgrade system

• Rework the shop from a terminal to a weapon merchant's stall

• Hub location that will be between levels

• Cutscene system

• Dialogue and subtitle system

Obviously, I won't do all of this in 2 months; these are plans for the next 2-3 seasons. However, these are the plans that need to be accomplished to bring the game to the early access stage and start sales of that early access. The highlighted items are the priority items; after their implementation, it will be possible, in principle, to start open free playtests of the game on Steam. That's why I will start with the highlighted items and then move on to the others.

By tradition, wishlists! And they are as follows: the game is on the wishlist of 6,610 (-34) people! I didn't do any wishlist marketing this season, so a small decline happened, but it's not critical.

Thank you for continuing to follow the project's development and for reading this article! See you at the beginning of winter!

Coctail model used for render[skfb.ly]