This month I continued to work on SDL Shooter, which is a space shooter written in SDL and C. This game started as a presentation demo for the December 2019 Knoxville Game Design meeting. The project source code is available on my GitHub account. I’m hoping to release it on more platforms when it gets to a point where I feel that it is complete. Right now I’m just having fun adding new types of enemies.
Foxtrot – Moves a few units either vertically or horizontally, pauses, and then moves in a new direction.
Golf – Snake type enemy that has a random number of tail links. Each link of the tail must be damaged before the head can be damaged. Moves in a sine wave at variable rates.
Hotel – Stationary enemy that constantly fires projectiles in a radial fashion.
India – Large enemy that explodes into four smaller enemies when damaged. When the four smaller enemies are damaged they explode into eight even smaller enemies. I need to make the explosion angles random, instead of the standard 90/180/270 and 45/90,135, etc angles.
Juliett – Hopper enemy that jumps in a parabola one to three units horizontally. One issue is two of these enemies can jump to the same spot and overlap. This could be solved by adding a target location variable for each enemy, and determine if another enemy has claimed that spot before jumping there. I would also like to have the enemy attack the player’s ship in some way. Either charge the player’s ship when it is aligned vertically, or shoot webs at the player’s ship to slow it down like in Zekkou no Tomodachi.
Kilo – A random number is displayed on top, and the player must shoot the correct binary sequence to defeat this enemy. Added the current “attack value” below the target value, which makes completing the binary sequence a little easier. The enemy has between 3 and 5 bits, so the maximum value for a 3 bit enemy is 7 and the maximum for a 5 bit enemy is 31.
Lima – A bat type enemy that starts sleeping, and then awakes and chases the player when the ship is near. The enemy is only vulnerable when it is not sleeping. The amount of time that it takes for the enemy to wake up is random. The second level enemy moves faster and takes more damage to defeat.
Mike – Color orb enemy. Three small orbs revolve around the center, which are either red, green, or blue. The player must shoot the correct revolving orb to match the center. If the center is yellow, cyan, or magenta, then it takes the correct two orb combination to defeat the enemy (such as cyan = green and blue). Shooting an incorrect orb will make the orbs revolve faster for a short period of time and the enemy will shoot at the player’s ship.
I checked my Microsoft developer dashboard today to see if the XBox One Creators Program was still running. I noticed that Kitty’s Adventure has now passed 50,000 acquisitions between XBox One and Windows Store. It is by far the most popular game that I’ve released to this day.
Also this month, we had a great turnout for the online Knoxville Game Design Meeting. This month’s topic was Java Game Development.
I spent some time updating my two college work pages for Georgia Tech and the University of Tennessee. Links to those two pages are now displayed on the main menu on my site under Education. I also found more of my old websites, which I uploaded and linked on my wiki page under Historical Pages. I uploaded the source code for some projects that were missing, such as the Predator database projects.
Classic beat ’em up action. You must guide the planet and defeat the evil planets to save the universe!
Videos
Post Mortem
World Fighter, The Cosmic Warrior was my thirteenth game developed for the main 48 hour Ludum Dare game development competition.
Dylan, Joe, and myself got together at Panera on the Friday night before the competition for a Ludum Dare kickoff. We speculated about what the theme would be. In previous competitions, we could get an idea of what the final contenders would be based on voting in previous rounds. However, those metrics are no longer available, so it was anyone’s guess.
My previous two games that I had developed over the past month were both collectible games. Note Chomper was a 2.5D Pac-Man clone that I developed for the MiniLD #73. Miner Madness was a platformer that I developed in GameMaker for GM48 where you avoid the bats and collect the gems. I knew I wanted to develop something for this competition where you attack and blow things up.
One of the themes that caught my interest was “A Small World”. As with some of my previous entries, such as One Gunman, I knew I could take the theme and make it the protagonist of the game. I told our group that I was thinking that I could make a fighting game, with a character like Globey from Pee-Wee’s Playhouse as the main character. He would fight other planets across the universe.
My original idea was a fighting game similar to Street Fighter II. The title is a play on “Street Fighter, The World Warrior”. At first, I thought about just switching the words “street” and “world”, but “The Street Warrior” really didn’t fit when I decided that the environment would be space, so I decided to go with “The Cosmic Warrior”. I had never made a beat ’em up game, so I decided to make the game similar to classic arcade games like Final Fight or Double Dragon.
For the player’s character, I decided to make it green with blue for the facial features and hair. I tried adding a nose to my character by modifying the mesh in Blender, but then it really didn’t look like planet so I kept the original sphere shape. I think Joe was the one who suggested using moons for punching, which I think turned out well. I modeled the planet character and animated the moon punching in Blender. I tried keeping the planet and two moons as separate objects in Blender, but that caused problems when importing into Unity, so I combined the three meshes into one, with three bones in the armature. I created an idle animation and a punching animation. I assigned one capsule collider to the planet character, and then a sphere collider to the moon used for punching. Unfortunately, this means that the moon “fist” collider has to be reassigned whenever the model is re-imported into Unity. I haven’t found a good way around this yet.
The enemies are similar to the player’s character, except they have a different texture. I tried making them look like Mars, with white hair to look like the northern ice cap of Mars. I made it so that each enemy could be destroyed with one hit. I had planned on having multiple enemies with varying levels of health, so that some would be more difficult to defeat than others. I also hoped to have a boss planet character, that would need to be defeated in order to clear the level. I ended up just having a counter for the total number of enemies and the player just needs to defeat all of the enemies to clear the level. I also wanted to have life bars displayed for each of the enemies, but time ran out before I could add that feature.
The movements of the player and enemies were handled with Playmaker addon for Unity. The enemies continually check to see if the player is a certain distance away. Once the player is close enough, then the enemy will move to the player’s location. When the enemy reaches the player’s location, it will start attacking. After each attack, it will check to see if the player is still in range, and move toward the player again if the player has moved away. Both the player and enemies bob up and down, which I think turned out well. It gives a bit of liveliness to the characters. I had to manually write the turning code myself, since the default rotation was not always in the direction that I wanted. I always wanted the player to rotate with the front facing towards the camera, so I had to take that into consideration in my rotation code.
I used the Blender Cell Fracture plugin again for making the planets explode. I put the explosion animation in a separate prefab. When an enemy is defeated, the enemy GameObject is destroyed, then an enemy explosion prefab is instantiated which plays the death sound effect along with playing the cell fracture animation. The one problem I still have with the Cell Fracture plugin is that you can’t define what the inner parts of the exploded object look like, so it just appears to be random parts of the texture. There are lots of options for the plugin, so I probably just need to look into it some more.
I used Audacity again for the sound effects. I didn’t try anything really experimental this time. I used the pitch modification to lower my voice and added a little bit of an echo. I used an envelope for the punch swipe sound. The one thing that I find frustrating with Audacity is that I think it should make the folder of the file that you opened the default when saving or exporting the modified file, because it wastes a lot of time having to dig through the directory tree to find your sound effect folder each time. However, it is a free tool so I can’t complain. The Audacity source code is also on GitHub, so I could actually change this if I really wanted.
The music was composed in GarageBand on my MacBook Pro, as I have done in previous competitions. Again, I used my regular process of making a couple of melodies, then I changed up the instruments and made slight modifications and mixed the melodies together. I also made a slower version with fewer instruments for the title screen.
I made the starfield background using a tutorial that I found years ago when making my Earthball pinball game. I changed it up a bit to suit my needs. I left out the supernova stars to create a skybox background. I learned that the skybox settings are hidden in the Window Lighting settings, and it is specific per scene. I had to change the Environment Lighting Source to a solid color, since the starfield skybox source made everything too dark. I put two stars down as a guide on the ground texture for the bounds for where the player can move.
The game world is composed of a number of “blocks”, similar to a street block. Each block has three enemies, which are somewhat randomly placed. There are two starport type objects, which I modeled and texture mapped in Blender at the last minute, which also form the bounding area of where the player can move. I had envisioned that these would be destructible and produce items, similar to the trash cans in Final Fight. The level could be improved by having an invisible wall that prevents the player from proceeding until all of the enemies on a block are defeated. I have a case statement that does add an invisible wall before the first block and after the last block to prevent the player from falling off of the ground.
I am happy with the game that I made for this Ludum Dare competition, but I don’t feel like I learned or tried anything new. There are definitely things that I want to fix and enhance in this game. However, after three back-to-back game jams I’ve decided to take a break for a little while. I think I want to try a new game engine or new modeling tool next time.
Dropping Blocks is a falling blocks game that I developed as a warmup for Ludum Dare 37. Drop the blocks and complete the lines to add to your score.
I took a different approach when developing this game, as I did not create a board structure to hold the blocks. Each of the blocks is just a Unity GameObject, with a Block script attached which contains its row, column, and center offset for handling rotations.
Every time a piece is dropped, it checks all of the other pieces to determine if any of the blocks are directly below any of the blocks in the actively dropping piece. If so, then the status of all of the blocks in the currently dropping piece are set to “not dropping” and a new piece is generated. The downside to this approach is that all of the blocks must be checked every time a block lands. It may be improved by creating a hash structure using the rows as keys, so that only the blocks in the row below the piece will be checked.
A piece is generated by generating a random number from 0 to 6 and instantiating the block in the arrangement for that piece. An array of Materials holds all of the colors of the pieces, and is assigned to the block based on the piece types.
The line check code loops through each line index, and then determines if there are blocks at every column in the line. This is also inefficient, since all of the blocks have to be checked to determine if a block is in each column for the row. Again, a hash table structure may make this more efficient for checking the row and eliminate some of the unnecessary looping. When I play the game in the Unity editor, there is a noticeable delay when a block lands. However, in the Windows build the delay is not apparent so there may be some optimizations made for the Windows build.
