DroneZone (BluePrint Project)
DroneZone (A 2 week development Project)
Feature log video (1:18s)
Feature log video for anyone who just wants to see the features I have implemented.
Hello! Today I want to talk about a two week game demo that two members of the "Vigilis" University group and I have created. The demo has no official name as of writing this post but the placeholder name from the team chosen was "DroneZone".
The Four sections I am going to go over are how the idea started and why I decided to start this Two week plan whilst also diving into the good, the bad and the future plans for development of the project.
The Inspiration for the project
On 6th of June 2025 the team and I officially finished our second year at university. sadly I was still not confident with my ability's to call myself a game developer, so I decide to dedicated my summer to educating myself and create small project with unreal. On 12th June 2025 I applied for a udemy course called "Code Your First Four Game Projects in Unreal Engine 5 with Blueprint Visual Scripting - From Beginner to Advanced!" by Stephen Ulibarri. I listened and follow Stephen guidance threw each of the lectures until I reached the end of his first official project. "Project BadBot" where Stephen taught me multiple of lessons such as Movement and rotation, Vectors, Firing Projectiles and the basics on how to pass class/object information from different blueprints which I ended up using later on the project to create the healing bot (more on that later) and finally he also taught me the basics of Collison handling between physical and querie collisions.
[Movement using custom Input mapping context]
Once the Movement and Rotation was implanted, Stephen Demonstrated spawning projectiles with a combination of Input mapping pulse modifications, sockets linked with the statics meshes and line tracing to aim the projectile at a specific Point.
The course progresses onto creating the same firing logic and movement for enemy Drones using Timed events and blueprint interfaces allowing for the enemy drone to be damaged when a projectile hits.[Health bar wasn't included on the course, I added the UI for more visual appeal]
[Enemy Fire Logic]
After I implemented the enemy drone I implemented collectables and a boss drone which ended the BadBot Porject section of the course. Whilst the project had a few good mechanics that could be made into a game the end result did not feel like a small completed game. So I decided to take it upon myself to attempt to additional mechanics to the project to make feel like a more completed game.
On the 13th of June I asked a few members of the Vigils group if they wanted to help with a small two week project to which two of the members agree and so started our small two week development journey.
The Good
I will begin with the good points about the project and then proceed to the negative of the project.
At the start of the project the Team started off strong with setting clear goals on what the project must have, should have, could have and won't have. The project was going to have two game modes with the main game mode of a city destroyer where the player must destroy the entire level before moving onto the next whilst the second game mode would be a reverse role play and the player must defend the city from hordes of enemies whilst repairs damaged buildings.
I was assigned Head of Development whilst the other two members worked on a mixture of Art, music and programming. I was primary the main programmer and would lend at hand whilst providing input to the other members when required.
The project started off strong. I used my current knowledge I had learnt from the COTA project and the knowledge from the Udemy course to make the submarine spawn and follow along the spline at a set speed whilst firing missile projectile into the air and eventually lock onto the player.
Following a spline following tutorial from "Gorka Games" Called "How to move a character alone a spline in unreal 5" and following this video worked for the most part but I ran into two problems when following this video. The first issue I had was The objects always spawned at the origin point of the spline.
I fixed this by creating a get start location float variable and then proceed to get all the different point along the spline and pick one at random and getting the distance of that knot on the spline a setting the starting location variable to value of the knots distance. This worked at the submarine was spawning at random knot point on the spline however, two new issues arose.
- When the submarine got to the end of the spline it would teleport back its initial starting point and not smoothly start at the origin of the spline to repeat the cycle
- Depending on where the submarine spawned the time to complete would be different effecting the speed of the submarines. causing one submarine to be running very fast and another submarine to be moving very slow
To Fix the teleporting issue I placed a timed event to reset all initial distances value such as the lerp (a) and time to complete value back to 0 so the submarine understood to restart its cycle back at the spline origin point instead of the random spawn point.
Healing Drone
The Healing drone mechanic was personally my favourite mechanic to work on during the project because it was the first time within the project I did not need to follow a guide to figure out how it would work. it was pure trial and error and when it all worked, it was just an amazing feeling.
The first thing I did when creating the mechanics for the healing drone was simply getting the drone to move from it initial position to the building which at the beginning was just a simple cube. This starting phase wasn't much of an issue because it follows the same logic I used to create the enemy drone but instead of targeting the player it targets the building. This within itself didn't cause many issue the only issue I had was once the healing drone reached it destination it would be inside of the "building" and spin around in circles. To fix the issue I created an array of static meshes connected to the building and made the drone select a point at random and make it target that location instead.
Once the drone was moving I made it so the building could heal and then respawn.

I achieved this by making a actor blueprint class called building Manager and created a function that is called via the gamemode which spawns a breakable object class of our choosing.
An issue I came across was at the beginning of the game, the game mode checks to see how many active breakable objects are in the scene to determine the level total health bar but because this function is being used to every tick to see if a building manager is being occupied by a building it doesn't get called before the health bar is set so this crash the game.
A simple fix to this was to spawn object upon beginning the game then to tell the gamemode to check after the first wave was spawned.
[gamemode blueprint checking each building manager]
Finally I needed the healing drone to recognise has been destroyed and if so to assign it self to said building so other healing drones don't attempt to heal the same building.
Within the healing drone I made it check all of the current breakable objects in the scene and also to see which building are currently destroyed and weather they already had a drone occupied to healing it. if the result was the case the building was destroyed and didn't have a drone currently occupying it then it will set the boolean within the breakable object to true via function which let other drone know it has now been assigned a drone and the drone will then processed to get the location of the building to move to. The function also take a reference to the drone that is occupying it so later on once the building is fixed it can send a message back to the healing drone saying it no longer needed and can continue looking for other buildings that may be destroyed around the map.
[The Result]
The Bad
Although the project was going smoothly at the very start it became quickly apparent how little time the three of us actually had to spend on the project. Between all members of the team having to work or having personal external issues in personal life. It came clear there wasn't a lot we could achieve in the amount of time we had for the original dead line. Although the team and I were struggling to find time to work on the project I decide to keep the original deadline of two weeks as the project was only supposed to be a small fun project where I can test my currently capabilities in blueprints and I did explain this to the team members when initially started the project to avoid unnecessary stress by the off chance work or personal issue took their time away from the project; So even though we had major set backs because of time, effecting the final product of the demo. I am still incredibly proud of the fella's who work on the small project along side me and how much they had gotten done with the UI, Art and sounds with the very little time they had to spend on the project.
Even though the demo didn't turn out the way we had planned I still learnt a lot from the experience and looking forward to reviving the project when I have learnt some new skills within blueprints, C++ and unreal.
The Future
For the time being project DroneZone is being left on standby for the development whilst the team returns to creating COTA another Vigilis group project and I progress with my learning journey. Even though the project is on freeze at the moment the team is looking forward to revisiting the project when the time is more convenient and work on making the game a more solid product for people to play.
Extras
A few extra things I worked on was the design for the main Menu UI as well as a simple blockout layout for what the first level will look like.
dPlease note Buildings used above besides the sky scraper were not built by the Vigilis team, I tried to find the creators page on SketchFab but wasn't able to.
Thanks for Reading
-Callum

.gif)
.gif)
.gif)





.gif)








.png)

Looks good, it's always tough when you can't put in the time on something you'd like because of things outtside of the project. Still, as was mentioned, everyone learned something from the experience and that bodes well for the future of all of you. The fact you didn't extend the project is also a positive as you stuck to the original deadline and did not let the 'small' project become something much bigger, which would take away from your other plans and ambitions.
ReplyDelete