Here is my week in review for the development of my Super Space Trooper video game. I’m thinking that I may need to start to keep an ongoing log. Even though I generally post about my progress every day or two, I’m finding that there are many important updates that I’ve completed and then forgotten.
This past week was a much more productive week than the previous, and I’ve gotten a great feeling of accomplishment the past few days. The tank track problems mentioned in last week’s Week In Review are ancient history now and I’ve since moved on.
Rewriting Scripts and Cleaning Up Code
On Saturday evening, I was reviewing some of the older code that I wrote in the first few months of the project. Having come a long way since then, I could see that there was room for improvement. What I had worked, but I could foresee future complications. Besides, you want to be sure to use as few system resources as possible.
The good thing I find about writing code, whether it be for a video game or web application, is that the second time around is almost always faster. And it’s almost always cleaner and much more lean. It was certainly the case for me on Saturday. I managed to replace somewhere in the neighbourhood of 20 scripts, and counting, with just four! On top of that the new scripts are “standardized” for my needs, meaning they can be used throughout the entire video game. So while it replaces those 20 scripts already, ultimately it’s likely it will have saved me 40, 50 or more scripts in the end. Thank you SendMessage function for allowing arrays to be sent! Why Unity doesn’t mention this fact in their documentation is beyond me.
First Video Released
Earlier this week I decided that I’d release a video capture of a test of Super Space Trooper’s first level boss. Mostly I only captured it to figure out which screen capture software I should use. If you have any suggestions, please leave a comment. Since I already had the video I figured it was time to finally add something to the YouTube channel. You can read more about the video and see it here.
Boss Animation Cut-Scenes
I was able to finish up both the boss intro cut-scene (as seen in the first video release) and the boss exit cut-scene for the first level. I will admit that I’m not 100% satisfied with them, but right now it’s not at the top of the priority list.
First Level Boss Progress Images
Last week I put up a post showing 26 work-in-progress images of the first level boss. The images weren’t made while I was working on the boss, but because I’m almost religious about saving files with new names as I do the 3D modelling, I had about 30 Blender files of my progress to use. Tip in Blender: Save a file name ending with a number (ex: myfile1). Then whenever you want to save a new file, mouse over the filename area and hit the + key on the numpad. Blender will automatically bump the number up to the next one, so you’d now have a myfile2. It’s all about streamlining!
Re-Think of Enemy Ship Animations
Late in the week I made a decision to change the way that enemy ship animations occur. Right now there’s a large box collider for each that enables the game object and it’s animation upon the player’s entry. I’ll be continuing to do it that way as it’s working well. However because the player’s ship is constantly moving forward, it makes enemy ship forward motion very difficult to manually animate. So instead I’ll be adding a forward motion script to each enemy to match the speed of the player. The forward motion script excludes the enemy ship “wakeup” collider mentioned above. Now I don’t have to worry about matching the player’s speed, I simply need to concern myself with the enemy animations within the player’s viewable area. Unfortunately this means that I’ll be trashing a good number of existing enemy animations, probably 25 or so, but the new method is so much faster I’m not overly concerned about the lost time. It’ll be more than made up for in the long run.
Weapon Damage Script
During the creation of the first level boss, I needed to find a way to implement damage points based on where the player ‘s weapons hit the enemy boss. So I wrote a script and released it on this site. Basically it uses the sendmessage function in Unity. The sendmessage sends an array of details from the child that was impacted by the player’s weapon to the parent (the boss overall). Because I was able to send an array, there was a bunch of details I was able to send including the gameobject, it’s amount of damage on impacts, which of the player’s weapons hit it, etc.
What Did I Learn This Past Week?
This week it’s mostly been about streamlining, standardization and ways to speed up the process flow. The particular change in methodology that’s had the most impact is the sending of arrays via the sendmessage and sendmessageupwards functions in Unity. I’ve also learned some of the limitations in Unity’s SetActiveRecursively function, so going forward I will likely need to take a somewhat different approach in that regard.