Overview
An RTS that I developed, where you use ninjas to defeat the enemy sensei for the Ludum Dare 7 Day RTS competition.
Complete Developer Log
Day 0001
Brainstorming
Started brainstorming a few ideas. The first idea I had was for an RTS where you would use garden crops like carrots, corn, and potatoes as your units. However, this seemed like it would be too much like Plants vs Zombies. Then I thought about all of the other themes for RTS games. There have been medieval/fantasy, space/sci-fi, and military RTS games. However, as far as I’m aware there has never been a Japanese ninja themed RTS, so I went with this idea.
Picking a Name
I take picking a name seriously, and I like to get the name of the title right the first time so I don’t have to change it later. Obviously, the first name that came to mind was “Ninja Craft”, but I think that would result in legal problems if I ever decided to sell the game. Games like MineCraft and GunCraft can get away with it because they are not in the same genre as WarCraft. I had to think hard about other names that RTS games have used, and determine if there is any common theme in the names. One problem a lot of RTS games can suffer from is that by the name and the box art, the potential buyer would never know it is an RTS. Honestly, I always thought Company of Heroes was an FPS. Other themes in RTS names are “war”, “battle”, and “empire”. I considered “Ninja Empire”, but there is already a puzzle game with that name. The name “Command and Ninja” crossed my mind, but it again it sounded too much like a knockoff. The Japanese translation for “war” is “sensou” so I considered “Ninja Sensou”, but I didn’t think it conveyed the essence of the game very well. After thinking about the gameplay more today, I settled on the name “Ninja Squad Commander”. I think it gives the feeling that you will be commanding a number of troops.
Gameplay
This game will be heavily influenced by other popular RTS games like Warcraft and Command and Conquer. However, I hope to alter the parts that I always found to be a headache. For instance, I won’t have gathering or mining as a part of this RTS, since I’ve always found it to be tedious and pointless. The player will simply gain resources by placing shrine buildings in their camp along with the main base.
Next I started listing units for the game. The ranged ninja will use shiruken as a projectile. I’m thinking of having three classes of damage. Blunt damage will result from weapons like nunchakus and staffs. Slash damage will be from swords and katanas. Pierce damage will come from pointed objects like sais and arrows. Weapons can be purchased and unlocked from the blacksmith building.
There will also be different classes of ninjas. Ninjas will be generated (trained) at the dojo building. Addons will be available to the dojo to train the ninjas in advanced concepts, which will each be related to a fundamental element of nature. The fire dojo will allow creation of fire ninjas, who can burn opponents for damage over time (DOT) effects. Water ninjas can douse enemies to slow them down. Wind ninjas can gain invisibility, which will allow them to sneak past opponents unseen. Finally, earth ninjas will be able to use herbs to heal the wounds of their allies. I may decide to add a few additional classes to buff allies with additional attack and defense. The color of the ninja’s garb will be related to their element, such as red for fire ninjas and blue for water ninjas.
Another thing I’ve never liked about RTS games is the micromanagement of units. I’m thinking about allowing the player to generate squads instead of individual units. There will be choices for the types of squads to create, such as balanced (mix of healers, melee, and ranged), high damage, and high defense. I will need to have a way for player to combine squads, because a squad of one or two units will be sitting ducks. An alternate method would be to have the health on the squad level, so that all squad members are defeated when the squad’s health reaches zero. The user will also be able to control the movement of units at the squad level, instead of having to select individual units.
I also considered adding a ranking level for units or squads, which would be based off the Japanese karate belt system. However, this may be confusing with the elemental colors for each ninja.
Writing Code
I now had enough of a design to start writing code. First, I created a title screen, with a title graphic text that I created in Blender. I decided to continually rotate the 3D text on the title screen, which I think is a nice effect. The one problem that I still have in Unity is that when you import a model from Blender, it automatically rotates it -90 degrees (or 270 degrees) on the X-axis to convert from Blender’s Z-up coordinate system to Unity’s Y-up coordinate system. This is fine for static objects, however when manually rotating your own objects, you must remember to rotate it by -90 on the X-axis before applying any other rotation if you assign the rotation to Quaternion.Identity first. Another problem I faced was that the title text would not rotate immediately after the game started. I found that this was due to some of the animation settings that I had changed for the object.
After creating the title screen, I decided to model some of the buildings in Blender next. First, I modeled the dojo and temple. Next, I modeled simple humanoid figures for the ninja.
Selecting Units
The next big step was adding code to be able to select units. Keeping track of the selection was easy, but the unknown part was converting the mouse click to an action on one of my units. After doing some research, I found that there are Ray hit detection methods in Unity which will return true when the ray from the mouse location to the object is connected. Adding debug lines using Unity was a good way of testing this. For the selection click, I used a tag on the ninja object which allows me to determine if the user has clicked on a ninja. Finally, I added code to set the ninja’s color to green if they are selected and to white if they are not selected. After looking at multiple code examples, I was successfully able to get this to work.
Also, somewhere along the way I added controls so that the user can move the camera around using the arrow keys.
Day 0010
Moving Units
Spent some time today getting the units moving around. The tricky part was getting the the 3D coordinates of where the player clicks the mouse on the ground, but Unity provides Raycasting helper functions to do all the complex work. I found a good example on the Unity wiki for getting an object to move to the location where the player clicks. I had to rework the code a bit, to allow multiple units to be moved to the location. Additionally, I had to ensure that each unit moved at a constant pace. If I had done a straight interpolation (Lerp in Unity), then units far away from the destination would appear to be moving faster than units close to the destination. After getting units moving around properly, I went back and updated the conditional statement so that only selected units are moved when the ground is clicked.
Finally, I added a group offset for each unit. This way when the units arrive at the destination, they will not clump up on one spot, making it look like one unit. I will need to rework this code later to evenly space a greater number of units.
I also created a video describing the progress I’ve made over the past two days.
Day 0011
Players
Tonight I worked on adding the concept of two separate players. To do this, I had to convert the ninja units and buildings to prefabs. Then in my generator gameobject, I instantiate the buildings and units for each player. Each player has an ArrayList of units and buildings. I also added an instance variable to each unit, which is the player number. This will be beneficial in determining if a unit should attack another unit.
Combat
I started implementing the combat system by adding a sphere collider to the ninja unit. I couldn’t have two colliders on the same GameObject, so I created a child GameObject of the ninja, which will hold the sphere collider for the attack range. I made the range of the collider 8 units. However, when I added this, I was no longer able to select any of the ninja units. This is because the attack range collider is larger than the basic select collider, so the attack ranger collider will be the object returned when I try to select a unit. This is not the desired result, so I had to remove the attack range collider, and determine if a unit should be attacked based on the distance between the current unit and the enemy unit in the script.
Finally, I added a health variable for each unit. For now, when an enemy is attacked, then their health is decreased by one. I also added an attack cooldown variable, so that the unit will only attack when the cooldown is zero. This will prevent the unit from continually attacking on every frame. When a unit’s health reaches zero or below, I remove the unit from the player’s array of units and call Destroy on that GameObject to free the memory allocated to it.
Day 0100
Resources
Made some simple changes tonight. Right click now moves selected units instead of left click. Also, the player may now only select units on their team. In the web player settings, I had to set the player to “No context menu”, otherwise a popup window would display every time the user right clicks the game screen.
Next I added a resources variable to track the amount of resources the player has to buy units and buildings. I always hated gathering, so I’m going to have resources slowly increase over time. The player starts with 200 resources, and the base will gain 10 resources every 5 seconds. I also plan on having shrines increase the amount of resources gained on every tick.
The shrine building has been modeled and added to the game, however it does not play a role yet. I’m planning on having a “research art” option for the shrine, which will allow the creation of fire, water, wind, and earth ninjas.
Using the simple buttons in the lower right corner, the player can now spend resources to purchase buildings (dojo and shrine) or add ninjas. The temple building is selectable on the world, so the next step is to make all buildings selectable, and only allow the creation button choices for the currently selected building. I also added checks to verify that the player has enough resources to buy the building or unit. Otherwise, the player could have a negative amount of resources. I will need to add a warning message or sound when the player tries to purchase an item that they do not have enough resources.
Currently, the player can not select where to place new buildings. The logic for allowing the player to do this is more than I want to tackle tonight. Therefore, I just kept a building position variable, and offset the position for each new building created.
Day 0101
Shrines
Updated the code so that the player can now build four different types of shrines, one related to each element. To make this simple, I just have a type variable in the shrine code, and I modify the material color based on the shrine type. The next step will be to modify the button handler so that ninjas of the shrine’s element can be trained at the dojo.
Updated Ninja Model
I created a new ninja model, which looks much better than the quick one that I made before. Using Blender, I made a rig for the model and created walk and standing animations. Blender’s interface for saving animations can be really aggravating at times. Pressing the “F” button next to the animation name appears to force the animation to the saved, otherwise the animation may be lost.
Another quirk with Blender and Unity is that whenever a model with no animation is imported into Unity, it must be manually rotated by 90 degrees on the X-axis. However, if your model does have animation and is set to Legacy mode, then the rotation does not need to be applied.
Another thing that I had to fix is the selection of the new ninja model. The rigidbody and box collider had to be added to the new model, along with tagging the new model as “Ninja”. Since the mesh is now contained in a child game object, the renderer must be acquired with gameObject.GetComponentInChildren<Renderer>(), instead of simply using the renderer property on gameObject.
Day 0110
Sensei Unit
Added the new sensei unit to the game. The sensei is the leader of the ninja troops, so the objective of the game is now to defeat the sensei of your opponent. I’ve never liked RTS games where you had to tear down every single building of your opponent, so I think defeating the enemy sensei is much more straight forward. He’s sort of like the king in a game of chess. Additional sensei can be created, but at the steep price of 5,000 resources.
As I did with the ninja, I created run and standing animations for the sensei. I copied most of the ninja variables, such as health, speed, and movement values. However, the sensei moves at about half the speed of the ninja and he has 50 health instead of the 3 that regular ninja have. I thought it was important to allow the sensei to take many hits, since his defeat is the objective of the game.
Enemy AI
I also added some simplistic enemy AI to the game. For now, if the enemy does not have a dojo, it will create a dojo first. Then it will start pumping out ninja every time 50 resources is gained. It will randomly keep about half of the units at the base to protect the sensei, and send the other half out to attack the player’s base. For now, it just sends ninja to the starting base coordinates, so it is easy to avoid the enemy by moving the sensei away from this location.
Health Values
The amount of health for each unit is now displayed over the head of each unit. The fastest way for me to do this was to add a TextMesh object as a child to the model. If the unit is a player controlled unit, then it is displayed in green. If the unit is an enemy unit, then the health value is displayed in red. This was a simple way to distinguish between friendly and enemy units. In the future, I would like to have some part of the unit’s clothing signify which team they represent.
Music
For a few of my previous Ludum Dare entries, I used PxTone Collage to create the music. It is a great tool, but the number of instruments are limited and the tracks generated sound really dated like an 8-bit game. I didn’t think that would fit the theme of this game very well. I bought a music creation package from Steam during the Summer Sale, since it was supposed to have a wide variety of instruments, but I was not able to figure out how to record input. Finally, I tried the Garage Band app on my Mac laptop and it was much better than I had expected. It had a vast number of instruments, and keyboard input was very simplistic. The only hassle is getting the music out into a format that I can use instead of the native “.band” format. To do this, I had to export my track to iTunes, and then export it to MP3. It is a bit of an annoyance, but it does the job.
Sound Effects
I used Bfxr again to create the sound effects, but I’m really not happy with some of the computer generated sounds. If I had the time, I would make the sound effects myself using an audio recorder. However, making sound effects and cleaning them up can be a good day’s worth of work.
End States
Finally, in order to make this a real game I created the win and lose states. Basically, I just added a method to return the number of sensei for the player number passed to the function. If the player (1) has zero sensei then the game is over and the player loses. If the AI (2) has zero sensei, then the player wins. I set a simple boolean value signifying that the game is complete, which displays a button to return the player back to the main menu.
Wrapping Up
The biggest problem left to fix is the clumping up of the units when multiple units are moved at once. All of the units will move to the same exact point, which results in the units overlapping each other. Originally, I resolved this by adding a group offset value at the beginning of the game. However, this will not work for dynamically generated units, so I will need to go back and calculate the offsets for units as the player selects them.
Another problem is the selection mechanism. Selecting units by left clicking them works, but it does not feel like a real RTS. Ideally, I would add a box selection tool, but I don’t believe I’ll have time to get that working with one day left. Hopefully, I can at least get all units deselected if a non-unit is left clicked, because deselecting each unit is a real hassle.
Before this miniLD is over, I would also like to implement the simplistic technology tree that I had planned. Currently, the player can create any unit regardless of which buildings they have created. This should be easy enough to handle by disabling or hiding the buttons for the units that do not have the requisite building. This will also require methods to loop through the player’s building array list and return a positive value if the player has the requisite building.
I would also like to add some special effects like fireballs for the flame ninja and damage effects.
Day 0111
Fixing Issues
Today, I spent most of my game development time resolving the biggest issues with the game. The most noticeable by me were the multiple selection and clump on move problems. To fix the multiple selection, I had to add a new array data structure which holds all of the selected units. Previously, each unit just had a selected instance variable, which can probably be removed now. A new check to see if the shift key is being held down while left clicking was added. If shift is not held down, then I call a new method that I created which sets all units in the selected array to unselected (to remove highlighting) and then clears the selected list. Then, the new unit is added to the selected list.
The next problem was the clumping of units on the move destination point. I already created a group offset variable in the units, so I just needed to set it appropriately whenever a new unit is added to the list. For now, I just have the units in a triangle formation. The math calculations for this formation was relatively simple. I can probably also reuse some of the code in Marching Band Simulator 2013, in case I decide to finish developing that game.
This introduced a small problem, when unit is defeated while selected. When a unit is defeated, its instance is completely destroyed. Since the unit is still in the select list, trying to set its selected property will result in an error. Adding a null check resolved this problem.
Technology Tree
I also worked on fixing the technology tree, because every single building and unit were available from the beginning. First, I made a slight game rule change. The sensei unit was incredibly expensive (5000 resources). I decided to drop the cost of this unit to 500, and add the constraint that there had to be at least one temple for each sensei. The temple costs 2000, which still forces the player to pay a price to get a new sensei unit. I want the sensei unit to be costly, since defeating them is the objective of the game. If there are too many sensei, then I think players would get frustrated in tracking them all down. This new game rule change also allows the player to make a new sensei at a relatively low cost after additional temples are created in the case that they do lose one of their sensei units.
Next, I added logic to disable the appropriate buttons if the requisite buildings do not exist. Unfortunately, I didn’t have time to dynamically place the buttons, so they just pop into place whenever the requirements are met.
Unit Special Powers
With less than an hour until midnight Eastern time, I ran short of time to implement all of the cool special powers that I had planned. So to compensate, when a fire ninja is created I set the attack power instance variable to 2 instead of 1. Bam! Special power done! Water ninjas… cooldown frames set to 30 instead of 120. Another special power done! Wind ninjas… hmmm… walk speed… double it! Another special power done. Finally those earth ninjas. How about 10 health instead of 3? Sounds good to me. All special units complete! I did have to modify the Start method in my Ninja script. Apparently the Start method is called after any initialization was done, so the “special abilites” were getting set back to the default values. Therefore, I created a setup method which assigns the default values, which is called after I create the Ninja instance and before I assign the “special powers”.
In Conclusion
I enjoyed writing my RTS, and it turned out a lot better than I expected. There’s a long way to go in order to turn it into a respectable game, but I definitely feel that I layed the foundation for a good game. The most obvious change that would need to be made next is improving the graphics, with texture mapped models and more scenery. I’ll also admit it isn’t the most elegant code I’ve ever written, since the game really evolved over the week. A lot of the code for ninja and sensei is duplicated, so I would like to have a “Unit” script that handles all of the basics of a unit. I believe Unity allows two or more scripts to be assigned to a GameObject, so that would allow me to keep all of the Ninja and Sensei code in their respective scripts.
So play it now and let me know what you think!
You can also watch the latest Ninja Squad Commander gameplay video.
Videos
Released