WaveBreakers
Wave Breakers is a third-person and top-down tower defense game focused on strategic tower placement, upgrades, and surviving relentless monster waves. The gameplay is centered around strategically building and maintaining a network of towers, that automatically gather resources and defend your position.
Players can construct specialized resource buildings that generate materials over time that allow for adding and upgrading buildings. There are no walls to place, but towers can be repaired, upgraded, and optimized to withstand increasingly dangerous waves.
​
Storm Crystals are the rare upgrade currency used to enhance towers, improving damage, range, and survivability. They are not tied to level progression or story advancement — your success depends on smart upgrades and tactical decisions.
To stay up to date with the whole team's progress, visit out Itch page, where you can even play an early build of the game! ​
​
https://syntaxsurfers.itch.io/wave-breakers-firstperson-strategy-hybrid-tower-defense​
Gameplay prototype
Latest Video
WaveBreakers Development Update
November 30, 2025
As this was a post made by the official Dev account please take a look at it natively on its itch.io page:
​
A Change in Scenery
November 13, 2025
The team and I have been doing a lot of work to clean up the transitions, integrate some better UI feedback across separate systems and just iron out a few issues here and there.
​
Most of all though, you can see that the endless void of space is not as visible any more! We are still adding other pieces of scenery to make the area feel less sterile, but this is a good step closer towards what the final result will be.
​
Here is some footage from one of our latest tests, that highlights my work on integrating the UI responses into the build system:
Here is another clip of a fun moment involving the tower possession mechanic which I have been helping on in my preparations in integrating controller support:
Problem: We can't see what we are doing!
​
I spent so much time making sure that it was easy for me as the developer to see while, testing, and iterating, that I completely forgot about the fact that it would all be stripped away in the build version. I came to this realization after our last build, and have been trying to implement some additional cues to make it more clear what exactly is going on for the player.
​
Old Build in editor: While developing and testing, this worked perfectly. Not only was it clear when I was playtesting what would go where, but also while developing, it gave me visual cues for improvements/changes, as well as just a guide when debugging aspects of the build system.
Old Build in .exe: Once we got the full build running I felt really stupid for not seeing that so much visual feedback was missing.
Solution: Think INSIDE the box
​
While trying to give more cues about what was happening I decided to look through some of the assets that we had pulled into the project. The tower assets that we decided on using came with a bunch of different textures and materials that we could use. I found one material that was a sort of holographic blue that was perfect for our sort of build representation.
​
I began to implement this material for the towers and buildings, and gave them a period of time required to be fully built. While still "under construction" , the structures showed the blue outline, and once fully built, they returned to their true materials. I had it all implemented too, but once I was getting ready to commit I realized that Unreal had kicked me out of revision control and that I was working on files that had already been checked out by others developers. I ended up reverting the work not only because I didn't have the files checked out, but also because I realized that this change in appearance to the buildings, while very helpful and more visually appealing, it was not as important as making it clear where the buildings could even be placed.
​
I decided to take this realization to heart and to begin focusing on showing the parts of the grid that can be placed on and those that cannot. I created a small class to represent the tiles on the grid. I gave this a simple cube mesh along with the holographic material. Now whenever the player enters build mode, top down or first person, they can see the surrounding tiles of where they would be placing the object. It currently is all in a single color, but I plan to have it change colors based on if something can be placed or not.
BLUE = Basic preview color for tiles
GREEN = Good Placement Spot
RED = Bad Placement Spot
Newest Build .exe: Our newest build includes, a first person and top down build preview of the surrounding tiles! Currently all blue but, the tile with the building to place will in the future, change colors based on if it can and cannot be placed.
First Person Building:
Top Down Building:
Building in Both Modes:
Resolution: Constantly think like the player
​
This build is definitely an improvement when it comes to feedback but there is definitely more room for clearer more responsive feedback. It is a really good start to including visual feedback in the build and I am pretty happy with the outcome so far. It will need some tweaking and refinement as we progress in mechanics and cleaning up, but as mentioned, these additional materials will be used to show a different build "status" and I am sure that I will find more ways to improve upon it as we go. I have learned that I need to be much more cognizant of how the player will see things rather than just leaning on my own understanding of the concepts and mechanics as a developer.
I can't see without my debug lines! *Velma voice*
September 26, 2025
Lines and Boxes: Everything has its place​
September 20, 2025
Problem: Everything has its place
Grids are cool because they are like little mini worlds. You can fill them with whatever you want and they can be used for all kinds of purposes. Since our tower game requires placement of towers, a grid was a perfect fit. While there is a great deal of freedom in what you can place and where, I had to impose some restrictions in order to make the game as realistic, intuitive and reactive as possible.
The first rule I set out to enforce was that you can only place one building/structure per tile. This prevented multiple buildings being placed in the exact same spot, as well as allows me to mark certain spots as off limits. We need to ensure that the lanes where the enemies travel cant be blocked off, and that things like the core of the base can't be built on top of.
The second rule I imposed was a distance check. This is just a small calculation to see if a building is within a given distance to any of the grids. This allows me to snap a building from its current position to the next closest grid. It also allowed me to check whether or not a building was too close to another building.
Solution:
​
My solution, besides the distance checks and placement rules, was to further mark the center of each grid tile, so that it was possible to visibly see where the building will stay once being placed.
It may seem like a really small thing to do, but it allowed for not only a better knowledge of how placement of towers worked for the player, but it also gives the ability to possibly divide these tiles further in the future.
Another key aspect of the build system is allowing the player to choose what buildings to place down. While incorporating this into the system it caused me to wonder if there truly was a need to be able to further divide tiles at run time. If a building is significantly smaller than a space, the player may not want to place it any as it reduces their active space. This is of course the kind of decision that must be made in a strategy game like this, but it is a possibility that I think we should consider for the future
Resolution:
​
While the build system is indeed functioning and very intuitive in the editor, we still have some room for improvement on the feature as the true game build lacks visual cues for the areas where the player can actually build. Things like textures on the ground will certainly help, but some sort of tint or coloring would go along way in making it feel more responsive.
PROBLEM: Time? Never heard of her.
​
There are pros and cons to the sprint workflow we have adopted and due to the time frame that our dev team is working with we these pros and cons have an even greater impact on our timing. Despite this approach to development being extremely well structured, I think that we are spread a little thin in terms of us utilizing too many resources. There are many great tools at our disposal individually but when there are so many of these intertwined it makes it quite hard to use any of them to any great effect, not to mention having to deal with any continuity issues.
​
I have been doing a ton of planning and just thinking to the point that my head hurts. Most of the design of the game is solidified in terms of the bones of the project we are starting with as well as the concept we are targeting, yet the details are many and the need to take the appropriate amount of time on each of them is great. While fleshing out the Design document for our game we began approaching many of these topics, and while we have become more focused on them, we still have a great deal of technical limits to see. This though goes hand in hand with our development approach
Gotta go fast, But not too fast!
September 15, 2025
Part 2: The Benefits of Proper Planning
​
There are so many little details that we as a team still need to make decisions on but this elongated planning will definitely be worth it in the long run. In what short time that we have had we have really come up with some great things, and have begun to think through all of the benefits, changes and ways that they can impact each other. In a game centered around strategy I think that this is really key and will be of great benefit to us in the long run.
​
I have already come across about 3 aspects of our game within the first build that have indicated the need for increased planning and testing. It would have been devastatingly difficult to rebound and pivot later down the road if we had not taken this long stretch of time to prepare. Even now in my own programming tasks of preparing the Grid System I have come across things that have forced me to reconsider some of my design choices and approach to overcoming some of these challenges.
Even just taking the time to create a detailed flow of thing like the gameplay loop have helped me to better see how all the moving pieces are connected.
Part C: Outcomes
​
Despite the fact that a lot of this planning is scattered and fits on all different levels of the intended gameplay experience, it has brought a since of identity to the project that I truly don't believe that it might have had any other way. Just by taking the time to plan efficiently I was able to get the basis of the entire building system coded in 35 mins!
​ I will forever remember the tools that we have used here for future projects sprints and plannings, even if I don't take advantage of every single one directly, there are aspects of each that I can take with me when i plan for projects in the future.
Want To Follow The Project?​​​
To stay up to date with the whole team's progress, visit out Itch page, where you can even play an early build of the game! ​
https://syntaxsurfers.itch.io/wave-breakers-firstperson-strategy-hybrid-tower-defense
​​​
If you are interested in viewing my own progress on the project, view my dev logs for the project!​​