{"id":69,"date":"2026-09-23T01:30:57","date_gmt":"2026-09-23T01:30:57","guid":{"rendered":"https:\/\/courses.etc.cmu.edu\/53-353\/?p=69"},"modified":"2026-09-23T01:30:57","modified_gmt":"2026-09-23T01:30:57","slug":"lesson-5-astral-attackers-part-2","status":"publish","type":"post","link":"https:\/\/courses.etc.cmu.edu\/53-353\/index.php\/2026\/09\/23\/lesson-5-astral-attackers-part-2\/","title":{"rendered":"Lesson 5: Astral Attackers (part 2)"},"content":{"rendered":"\n

In this week’s class, we discussed strategies for audio, and covered the Singleton pattern – a very powerful tool (but also a potentially tricky\/dangerous one) for organizing our game and exposing our “manager” scripts to the objects in our scene. The videos this week will cover updates to our Astral Attackers game to build a Sound Manager, create the Game Manager which will handle our game state and flow, and finally we will make some visual improvements to our environment and to our enemies to spice things up.<\/p>\n\n\n\n\n\n\n\n

Part 1-A: Making Better Enemies…<\/h2>\n\n\n\n

Our previous alien attackers were rather primitive – Unity primitives, to be exact. (Thank you, I’ll be here all week!) Now that we have a fancy setting, our enemies should be a little more… dramatic. For this section, we are going to look to the source material and draw some inspiration from the classic pixel-y goodness of the original, and build our enemies out of cubes.<\/p>\n\n\n\n

Why cubes? First off, they are super easy to create and work with, and require surprisingly little overhead in terms of rendering and physics calculation. Second, I want to show you how you can create a game using just the tools provided – no need for special 3D modeling\/animation software. Third, we are going to use Physics on those blocks to create a satisfying explosion effect on the alien ship that will add some fun to our game.<\/p>\n\n\n\n

First, we create a single cube, using GameObject > 3D Object > Cube<\/strong> or Create\u2026 > 3D Object > Cube<\/strong>. I’m going to want my bottom center cube to represent the “position” of the object so I will set its position to the origin (0, 0, 0). If yours is not at that location, you can select the settings dropdown from the Transform<\/strong> component and select Reset Transform<\/strong> to do so.<\/p>\n\n\n\n

Next we make copies of the cube and offset them by 1 unit increments so that you have a row of 5 cubes with their edges touching. Now copy those rows and move them up by 1 unit increments, until you have a 5\u00d75 cube grid.<\/p>\n\n\n\n

\"\"
in case you wondered what 25 cubes looked like..<\/figcaption><\/figure>\n\n\n\n

Then, we create an empty game object (GameObject > Create Empty<\/strong> or Create\u2026 > Create Empty<\/strong>) also located at (0, 0, 0) and make all of the cubes children of this empty object. Notice that when you add the cubes as children, they now indent under the parent object in the Hierarchy, and the parent object now has a small button that lets you roll-up the list.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

I expect to create a number of aliens using this same block grid, and so I will create a prefab <\/strong>object from it that I can use as a template for future iterations. I name the parent object “Base Grid” and drag it into my Asset window. Now that I have saved a copy, I want to unpack this prefab and convert everything back into a scene object so that I can make local edits. I do this by selecting Prefab > Unpack Completely<\/strong>. Once I have edited this to make an alien shape, I will save this as a different prefab. (This is my<\/em> path to create these objects, but this is by no means the only<\/em> path. Do what works for you!) <\/p>\n\n\n\n

Once I have unpacked the object, I edit it by removing some of the blocks. You can delete these, or simply turn the cube objects off using the check box next to the GameObject name in the Inspector. This way, the block is preserved, in case you want to go back later and edit quickly. Remove some blocks and make an alien shape like so:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Time to give the parent object a name. I called mine AlienFrame1<\/strong>, since I will have multiple versions of this, each one representing a frame of animation.<\/p>\n\n\n\n

Now I turn off AlienFrame1<\/strong>, and place a new instance of the AlienGrid <\/strong>template in the scene at the same position. I unpack, edit it to look as though the legs have moved, and name the parent object AlienFrame2<\/strong>. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Now I am going to create a duplicate of AlienFrame1<\/strong>, but I will call this one AlienExplode<\/strong>. This object will be out \u201cstunt double\u201d, swapping places with the other frames when it is time for the ship to blow up. To get that great explosive force, add a Rigidbody component to each of the cubes in AlienExplode<\/strong>. (You can simply select all of the cubes at once and go to Add Component<\/strong>). <\/p>\n\n\n\n

It is also worth noting that in my objects for frames 1 & 2, I have turned their colliders off. This is because I want to have to worry about managing collisions on the individual blocks – I want these to simply be a part of a cohesive whole. <\/p>\n\n\n\n

I\u2019m going to make each one of our alien parent objects a prefab by dragging it down into the Assets folder. Next, I am going to create a new empty game object and parent it to these prefabs, so that it serves as a container to the individual frames. Name this object EnemyTypeA <\/strong>and make this object into a prefab as well. I add my Enemy<\/strong> class to this, as well as a Box Collider<\/strong> component which I will resize to fit around my enemy object. (Don’t forget to change your layer designation to “Enemy”!)<\/p>\n\n\n\n

Now, let\u2019s add a little bit of scripting to bring our little attacker to life. We want to open our Enemy<\/strong> script and add variables to hold the three child objects of this particular enemy. <\/p>\n\n\n

\n    \/\/ enemy voxel frame prefabs\n    public GameObject enemyFrameOne, enemyFrameTwo, enemyExplode;\n<\/pre><\/div>\n\n\n
We define three objects (which we must populate with the Inspector), and then on Start( )<\/strong> we set their conditions so that only the modelOne model is active. I use Awake so that this is set instantly, just in case something else is going to access our models when the Start( )<\/strong> event runs.<\/p>\n\n\n
\nprivate void Start()\n{\n    enemyFrameOne.SetActive(true);\n    enemyFrameTwo.SetActive(false);\n    enemyExplode.SetActive(false);\n}\n<\/pre><\/div>\n\n\n
Next, we create a functional called SwapFrames( ) <\/strong>that will toggle the visibility of Enemy Frames 1 & 2.  cond. It accomplishes this by nesting the call and the 1.0 second yield inside of a \u201cwhile\u201d loop that will run continuously for the duration of the object because the condition is set to \u201ctrue\u201d.<\/p>\n\n\n\n
The SwapFrames( ) <\/strong>command simply set the active state of both frames to the opposite value.  For now, this function will fire when we press the “S” button.  <\/p>\n\n\n
\npublic void SwapFrames()\n{\n    enemyFrameOne.SetActive(!enemyFrameOne.activeSelf);\n    enemyFrameTwo.SetActive(!enemyFrameTwo.activeSelf);\n}\n<\/pre><\/div>\n\n\n
Now we need something to call this frame swapping function.  Our game design calls for a highly coordinated attack orchestrated by a single entity – the MotherShip (or in this case the MotherShipScript) – and so it is there that we will issue the SwapFrames( )<\/strong> call.   In the previous lesson we examined how to access a child object through the transform<\/strong> of this object, so one strategy would be to count our children, then loop through them one-by-one, accessing the EnemyScript<\/strong> component and issuing the command, but today we will look at a different method.<\/p>\n\n\n\n
Instead of individually accessing each child object, we can simply broadcast <\/strong>a command to every child object, much like a parent would yell to all of their children at once when it is time for dinner.   We do this through the BroadcastMessage( )<\/strong> function, which is similar to the SendMessage( ) <\/strong>function, but where as SendMessage( ) only calls this function on the components of a single target object, BroadcastMessage( ) will issue the message to every child object, and their children as well. <\/p>\n\n\n\n
When our MotherShipScript’s coroutine causes the attackers to move, we also issue a SwapFrames( )<\/strong> call to every object like so:<\/p>\n\n\n
\n\/\/ move to the side\nfor (int = 0; i < stepsToSide; i++) {\n    \/\/ move by the offset\n    transform.position = transform.position + sideStepVector;\n\n    \/\/ run swap frames\n    BroadcastMessage("SwapFrames");\n\n    \/\/ wait for the interval\n    yield return new WaitForSeconds(timeBetweenSteps);\n}\n<\/pre><\/div>\n\n\n
The benefit of this method of calling a function is that we can have multiple scripts that share the same method name and it will be called on all of them. (You already use something similar to this – Update( )<\/strong>, Start( )<\/strong>, and Awake( ) <\/strong>are examples of functions that respond to a message<\/strong>.)<\/p>\n\n\n\n
Part 1-B: … and cool Explosions!<\/h2>\n\n\n\n
For this next part, we want to test out our explosion effect \u2013 where we swap out our model frames with our \u201cstunt double\u201d and then apply an explosive force to the individual boxes. We do this by creating an EnemyExplode( ) <\/strong>command in our EnemyScript<\/strong>, like so:<\/p>\n\n\n
\n    private void EnemyExplode()\n    {\n        \/\/ turn off the other objects and turn on the explosion frame\n        enemyFrameOne.SetActive(false);\n        enemyFrameTwo.SetActive(false);\n        enemyExplode.SetActive(true);\n\n        \/\/ Make the enemy explosion noise\n        SoundManager.S.MakeEnemyExplosionSound();\n        \n\n        \/\/ get all of the rigidbodies\n        Rigidbody[] enemyBlocks = GetComponentsInChildren<Rigidbody>();\n\n        foreach (Rigidbody block in enemyBlocks)\n        {\n            block.AddExplosionForce(explosionForce, (transform.position + Vector3.back * 2f), explosionRadius, 0f, ForceMode.Impulse);\n\n        }\n        \/\/ orphan the explosion object\n        enemyExplode.transform.parent = null;\n    }\n<\/pre><\/div>\n\n\n
Once we have turned off our models and turned on our \u201cstunt double\u201d object, our goal is to apply the Rigidbody.AddExplosionForce( )<\/a><\/strong> to each cube in the object. This method takes three arguments \u2013 a force to exert, an origination point for the explosion, and a radius within which the explosion will have an effect. We create public float objects for \u201cexplosionForce\u201d and \u201cexplosionRadius\u201d in the class declaration, and then set those values.<\/p>\n\n\n\n
In our explode command, you see that we declared a variable as \u201cRigidbody[ ] enemyBlocks\u201d. These brackets mean that we expect to receive more than one result \u2013 an array of Rigidbody components. We then generate this list using the GetComponentsInChildren<>( )<\/strong> method which returns the array of all child objects for \u201cmodelExplosion\u201d that have a Rigidbody component in their backpack. Finally we use a \u201cforeach\u201d loop that lets us cycle through each result in our array. In each pass of the loop (that is, for each Rigidbody object in enemyBlocks[ ]) we set that object to the variable \u201cblock\u201d, and then apply our explosive force to that Rigidbody. By cycling through all of these we ensure that every object is affected by the force.<\/p>\n\n\n\n
One thing that you will notice is that our other frames keep popping back into view. This is because we set our Coroutine to run continuously. We can try to prevent this by issuing a StopCoroutine( ) <\/strong>command, but there is a better solution – let the Enemy object be destroyed on impact, like it was.<\/p>\n\n\n\n
Now, this creates a conundrum.  If we destroy the object, the children will be destroyed as well, along with our “stunt double”.  Everything will just blink out of existence.  But what if our stunt double was not a child of the enemy object?   To accomplish this, we are going to emancipate our stunt double from it’s parent object, making it an orphan (or as I like to call it, a “child of the world”).  We do this by setting the parent of that object to “null”.<\/p>\n\n\n
\nenemyExplode.transform.parent = null;\n<\/pre><\/div>\n\n\n
Now our enemy object destroys itself, but not before throwing the stunt double out into the world and applying the explosion just before it disappears.   Because our EnemyExplode( ) <\/strong>command runs prior to the command that destroys the Enemy object, our stunt double makes it out alive (but not for long).<\/p>\n\n\n\n
Finally, we are going to insert some special effects, using an explosion prefab built with Unity’s particle system.  (More on these later…).   You can download this prefab in the package posted on the course Box site.   By adding this prefab as a child of our AlienExplode<\/strong> prefab, it will appear and play once when the stunt double wakes up.  It make a fiery explosion with a bright orange light, sends out a “shockwave”, and shoots some smoking embers off into the distance. <\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Part 2: Improving the Layout<\/h2>\n\n\n\n
This still looks a lot like a Unity demo, and less like a real game.  In this workshop section, we make some simple cosmetic changes to the game to create an alien landscape.  Through the addition of some primitive shapes (a ground plane and some “mountains”), the addition of some color (via some new materials), and the removal of the skybox (by setting the camera background to solid color), we have added a lot of personality to our game.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Part 3-A: Audio Strategy<\/h3>\n\n\n\n
When we are making our game, there are a number of decisions that will center around how we want to treat the sounds in our game.  When should they be playing in our game?  What should be emitting the sound?  Do I need to have control over the sound, such as starting and stopping playback, or adjusting the speed or pitch?   Are my audio clips short or long?  How often can I expect to hear each sound?  These questions will inform our decisions as to which objects should emit what sounds, and how much control we may need to exert over them through code.<\/p>\n\n\n\n
For most of my games, my sounds tend to fall into one of four categories:<\/p>\n\n\n\n