Well our team has finally hit our Alpha stage, and I'm pleased with how it has turned out. We have a functional game that has an interesting control scheme. We have most of our mechanics worked out, and are ready to use them to create awesome content.
Now that the semester break is coming upon us, I want to design more abilities for the player to utilize as a ninja. My goal is to, at least, design three abilities. I've already thought of some cool abilities that would suit the game (and, of course, make the player feel like a bad-ass), so I've decided to share some of my ideas.
1. EarthTrap Shuriken
Being a ninja, it seems natural that we would use one of their most iconic weapons, the shuriken. However, with the supernatural/ancestor aspect we are implementing, it needs a little more spice than just a simple projectile. Thus, I am thinking of making this a type of avoidance/crowd control move. The move would initiate by having the player back-flip away from his enemies. Then, in mid jump, the player would launch a magical shuriken into the ground (or into an unlucky enemy). The shuriken would then emanate an aura that would slow down enemies within a radius (as if trying to move under shifting earth). From there, the player could either dispose of the enemies in their crippled state, or simply move past them as they struggle to give chase.
2. Shadowstitch
This would be an upfront, almost melee, ability that would activate in front of the player. It would strike in arc downwards towards the ground which would then become black. Enemies caught within this arc would be temporarily paralyzed as if bound by unseen wires. The player then could proceed to defeat the paralyzed foes, or simply leave them in their immobile state. This is a powerful ability, so its arc wouldn't be too big; it would cost a lot of energy to use as well. However, it would be a valuable tool when the player is in a bind.
3. Explosive Illusion
This ability would act as a counter to an enemy attack. When activated, it would allow the player to vanish in a puff of smoke leaving behind a small explosive. The explosive, when struck, would unleash a small blast that would damage any enemy nearby (though it wouldn't deal too much damage). As for the player, he would re-appear, in mid-air, above the spot he vanished from; from this point, he could activate any other ability that can be used in air as he sees fit. The point is to use it before the enemy is about to strike the player, so the enemy, instead, strikes the explosive. It feels like a tool a proper ninja would have at his disposal, and it would add an element of timing to the game-play.
These are the three abilities I want to design over the break. I'm quite excited about getting into the more creative aspects of game design, and will be trying my best to design fun, creative, and bad-ass abilities.
Adam Durant's Development Portfolio
Thursday, December 6, 2012
Sunday, December 2, 2012
Damageable Component
My final task for Alpha was to build a component that would keep tabs on the health of the character attached to it. This was vital to the Alpha build because it allowed the player and enemies to be defeated by depleting their health.
Again, this is going to be a component, so it can be attached to either player or enemy. Overall, this was a fairly easy class to create. When creating the component, the input will dictate how much health the character has. As for functions, I made the following methods: one that subtracts from health; one that adds to health; and one that checks if the character has run out of health. If the character has run out of health, it will delete that character, and check if it was a player. If it is the player, then it's game over.
A simple, clean class, but necessary for our alpha build. Since I worked on the projectile class, this was extremely easy to test with enemy projectiles. Fortunately, it works as expected.
Again, this is going to be a component, so it can be attached to either player or enemy. Overall, this was a fairly easy class to create. When creating the component, the input will dictate how much health the character has. As for functions, I made the following methods: one that subtracts from health; one that adds to health; and one that checks if the character has run out of health. If the character has run out of health, it will delete that character, and check if it was a player. If it is the player, then it's game over.
A simple, clean class, but necessary for our alpha build. Since I worked on the projectile class, this was extremely easy to test with enemy projectiles. Fortunately, it works as expected.
Animation-to-Sound Handler
Since our Alpha was drawing close, I was asked to start adding sounds into the game. In addition to that, I was asked to build a system that played sounds based on the current player's animations. This would be useful for playing sounds in exact accordance to what animation is playing, and provide programmers one simple location to edit/replace animation sounds.
First, I designed this to be a component, so that it could be added to any character with a reasonable amount of animations (be it player, enemy, or otherwise). This component, the AnimationSoundManager, had access to that character's avatar, and this avatar held information about what animation was currently playing. Thus, my class looks for when a new animation is played, and checks if there is an associated sound file for it. If so, it plays the sound, and waits for a new animation to activate. I give thanks to Blake who suggested a system for storing the previous animation to compare with the current one to see if a new animation had triggered.
However, I ran into a little problem. I had no way to shut off looping sounds from my AudioController class. Thus, I restructured that class as well to include a way to delete clips from the previous animation. I also programmed a function that cleaned up clips that had completed. Previously, they still existed even after they finished, but now they are properly removed. This should prove much more efficient down the road. Additionally, I programmed a simple mute functionality that would either un-mute or mute all current clips when called (i.e. it reversed the current mute setting).
Another problem arose when I realized that the Windows version of our game doesn't switch animations (because we only use a cube for our character on Windows). This proved an obstacle in seeing if the AnimationSoundManager was actually doing its job. To overcome this, I had to manually program changes in the Cube's current animation (though this change was strictly to notify me when to play a sound). I decided to keep these changes in, so that anyone playing on the Windows version would be able to hear animation sounds.
In the end, this worked out well. We now have various sounds in our game to give it a little more life. Even though most of these sounds are placeholder, they add to the experience nonetheless.
First, I designed this to be a component, so that it could be added to any character with a reasonable amount of animations (be it player, enemy, or otherwise). This component, the AnimationSoundManager, had access to that character's avatar, and this avatar held information about what animation was currently playing. Thus, my class looks for when a new animation is played, and checks if there is an associated sound file for it. If so, it plays the sound, and waits for a new animation to activate. I give thanks to Blake who suggested a system for storing the previous animation to compare with the current one to see if a new animation had triggered.
However, I ran into a little problem. I had no way to shut off looping sounds from my AudioController class. Thus, I restructured that class as well to include a way to delete clips from the previous animation. I also programmed a function that cleaned up clips that had completed. Previously, they still existed even after they finished, but now they are properly removed. This should prove much more efficient down the road. Additionally, I programmed a simple mute functionality that would either un-mute or mute all current clips when called (i.e. it reversed the current mute setting).
Another problem arose when I realized that the Windows version of our game doesn't switch animations (because we only use a cube for our character on Windows). This proved an obstacle in seeing if the AnimationSoundManager was actually doing its job. To overcome this, I had to manually program changes in the Cube's current animation (though this change was strictly to notify me when to play a sound). I decided to keep these changes in, so that anyone playing on the Windows version would be able to hear animation sounds.
In the end, this worked out well. We now have various sounds in our game to give it a little more life. Even though most of these sounds are placeholder, they add to the experience nonetheless.
Re-factored Projectile System
Our game went through a bit of a redesign in the last couple of weeks. This change altered how enemies and players were created and controlled. Thus, since my projectile system is based on the interactions between the two, I had to redesign the projectile manager a bit.
First, our new system is designed around adding components to a base character class. Therefore, what defines a player or an enemy is what components are attached. Therefore, I made my ProjectileManager class a component to be attached to either a player or enemy. Porting my code into this format wasn't too difficult.
The next step was for the ProjectileManager to spawn arrow projectiles for enemy guards to fire. Unfortunately, the way objects were drawn was altered in the redesign, so I had some trouble porting my code. However, one of our team members, Ron, had made a handy little class that handled the drawing of a model with our new system.
After all that, the logic still worked like a charm, and adding the new component to characters is rather easy now. Thus, I'm glad with how this worked out, and am excited to expand upon my ProjectileManager to handle different types of projectiles.
First, our new system is designed around adding components to a base character class. Therefore, what defines a player or an enemy is what components are attached. Therefore, I made my ProjectileManager class a component to be attached to either a player or enemy. Porting my code into this format wasn't too difficult.
The next step was for the ProjectileManager to spawn arrow projectiles for enemy guards to fire. Unfortunately, the way objects were drawn was altered in the redesign, so I had some trouble porting my code. However, one of our team members, Ron, had made a handy little class that handled the drawing of a model with our new system.
After all that, the logic still worked like a charm, and adding the new component to characters is rather easy now. Thus, I'm glad with how this worked out, and am excited to expand upon my ProjectileManager to handle different types of projectiles.
Monday, November 26, 2012
Addon System for Characters
As alpha approached, we needed a system that allowed the programmers to add various objects to the Avatar models. For example, the team wanted me to add a placeholder helmet for the guard characters. This was simply to show we had the capability to do this before the alpha stage was completed, but I decided to go ahead and create the first iteration of the system beyond just adding a hat.
To start, I had to configure the Character Factory class to include this addon system for the guard characters. This was relatively simple to do, and our robust system for adding components seems to be paying off.
My first goal, after that, was to simply create a class that put a box on top of the guards, so I used our dummy avatar class as a template (which is just a big box anyway). From there, I expanded the code to be much more adaptive. When calling the AddModel ability from within Addon component, one has to supply it with the model's location in content, and a Vector3 which is an offset to where the model will be in relation to the character's center.
At this point, the box would now appear wherever I wanted it to be, but I soon realized that my code needed to accommodate multiple objects being attached to a character within the same addon class. I heavily tweaked the containers that held the model's information to be compatible with multiple objects. The Dictionary class proved most useful in keeping tabs on information that was associated to each model (transforms, positions, etc). From there, I simply needed to tweak the Draw method to iterate through every model and draw them.
The final challenge was translating the Vector3 position to be relative the character's position and orientation. Without that, the attached object would quickly become detached once the character started moving. Thus, created a function that takes in the position, and translates each coordinate properly according to the character's orientation.
In the end, I'm quite satisfied with how this worked out. We can now freely add any models, like weapons/armor/clothing, to the characters through my Addons component. Here's a little picture showing a couple of addons being attached (do note, I did this on the Windows version which means I didn't have use of the Avatar models). I attached the little box to all the guards, and added a little shuriken for kicks.
From my testing, both objects move completely in sync with the character, so I'd say this is good progress!
To start, I had to configure the Character Factory class to include this addon system for the guard characters. This was relatively simple to do, and our robust system for adding components seems to be paying off.
My first goal, after that, was to simply create a class that put a box on top of the guards, so I used our dummy avatar class as a template (which is just a big box anyway). From there, I expanded the code to be much more adaptive. When calling the AddModel ability from within Addon component, one has to supply it with the model's location in content, and a Vector3 which is an offset to where the model will be in relation to the character's center.
At this point, the box would now appear wherever I wanted it to be, but I soon realized that my code needed to accommodate multiple objects being attached to a character within the same addon class. I heavily tweaked the containers that held the model's information to be compatible with multiple objects. The Dictionary class proved most useful in keeping tabs on information that was associated to each model (transforms, positions, etc). From there, I simply needed to tweak the Draw method to iterate through every model and draw them.
The final challenge was translating the Vector3 position to be relative the character's position and orientation. Without that, the attached object would quickly become detached once the character started moving. Thus, created a function that takes in the position, and translates each coordinate properly according to the character's orientation.
In the end, I'm quite satisfied with how this worked out. We can now freely add any models, like weapons/armor/clothing, to the characters through my Addons component. Here's a little picture showing a couple of addons being attached (do note, I did this on the Windows version which means I didn't have use of the Avatar models). I attached the little box to all the guards, and added a little shuriken for kicks.
Saturday, November 24, 2012
Ledge Swapping Mechanic
I was briefly assigned to work on a control mechanic for the game. I worked on allowing the Avatar the ability to jump to another ledge. This would apply when the Avatar is already hanging on a ledge, but needs to move around to the other side without climbing up.
Going into this, I had little information on the actual avatar movement mechanics, but I figured it would be a good exercise to learn more about it. Fortunately, there was already a movement controller (a movement controller is a class that governs how an object moves given a certain state) that was similar to what I needed to accomplish. This was in the climbing movement controller which governed the movement when the Avatar needed to climb up from a ledge. This was similar for two reasons. First, it used ray casting to see if the ledge connected to a valid platform. Second, it handled the movement of the Avatar automatically (most other movement controllers take in the player's input).
With this in mind, I set out to program the ledge swapping ability. To start, I had to figure out which way I needed to ray cast. To set the direction, I needed to get which side of the ledge the player was on. If he was the right side, I needed to set the ray's position forward and to the right of the player's position; I then needed to ray cast to the left to see if a ledge existed on the other side. If the player was on the left side, I simply needed to set the ray's position left and forward instead, and then send the ray right. This handled the logic I needed to determine if the player could swap to the other ledge in the first place.
The second task was the actual movement which was a tad trickier than I anticipated. I asked Blake to help me understand his climbing movement code. With a good bit of help from him, we were able to get the player to snap over to the other ledge by using the position given by the previous ray cast (which determined if he could grab the other ledge in the first place). We did run into a little tiff about the player not latching on to the ledge, but that was fixed by re-oriented the player's facing so it faced the wall properly (it's hard to tell if the player is facing the wall when the player is just a box on the windows version).
After all that work, the ledge swap mechanic works very well, and the player can swap to another ledge, given that such a ledge exists, at the press of a button. In addition, I learned a more about ray casting which is quite useful in 3D programming.
Going into this, I had little information on the actual avatar movement mechanics, but I figured it would be a good exercise to learn more about it. Fortunately, there was already a movement controller (a movement controller is a class that governs how an object moves given a certain state) that was similar to what I needed to accomplish. This was in the climbing movement controller which governed the movement when the Avatar needed to climb up from a ledge. This was similar for two reasons. First, it used ray casting to see if the ledge connected to a valid platform. Second, it handled the movement of the Avatar automatically (most other movement controllers take in the player's input).
With this in mind, I set out to program the ledge swapping ability. To start, I had to figure out which way I needed to ray cast. To set the direction, I needed to get which side of the ledge the player was on. If he was the right side, I needed to set the ray's position forward and to the right of the player's position; I then needed to ray cast to the left to see if a ledge existed on the other side. If the player was on the left side, I simply needed to set the ray's position left and forward instead, and then send the ray right. This handled the logic I needed to determine if the player could swap to the other ledge in the first place.
The second task was the actual movement which was a tad trickier than I anticipated. I asked Blake to help me understand his climbing movement code. With a good bit of help from him, we were able to get the player to snap over to the other ledge by using the position given by the previous ray cast (which determined if he could grab the other ledge in the first place). We did run into a little tiff about the player not latching on to the ledge, but that was fixed by re-oriented the player's facing so it faced the wall properly (it's hard to tell if the player is facing the wall when the player is just a box on the windows version).
After all that work, the ledge swap mechanic works very well, and the player can swap to another ledge, given that such a ledge exists, at the press of a button. In addition, I learned a more about ray casting which is quite useful in 3D programming.
Thursday, November 15, 2012
Projectile Prediction
For this week, I've improved the design of our projectile system. Previously, the projectile only fire to the player's position when first fired. This, of course, wouldn't be very logical as one wouldn't fire where he was, but rather where he was going.
Thus, I added a prediction system for the AI to use that allows the AI to gather the player's forward orientation and predict where the player will be in x amount of seconds (it is currently set to about 1 second). The implementation was a bit complicated, and nailing down the precise formula was difficult (3D space is infinitely harder to work with than 2D space). However, I was pretty happy with the results at the end. Now, if the player runs in the same direction when the AI fires, the player will be hit (with some error built in for good measure).
In addition to that, I've worked on re-modeling the projectile class as not just a part of the enemy class, but rather an ability that can be extended from and used for both AI and player alike. I've implemented the basics of how the class will be set up, but I need to do some pair programming with our other ability programmer, Blake. We need to get together and solidify the ability class, so that it properly extends to both the player and AI in a reasonable manner. Hopefully, we'll have a robust ability class that will serve well until the end of the project.
Thus, I added a prediction system for the AI to use that allows the AI to gather the player's forward orientation and predict where the player will be in x amount of seconds (it is currently set to about 1 second). The implementation was a bit complicated, and nailing down the precise formula was difficult (3D space is infinitely harder to work with than 2D space). However, I was pretty happy with the results at the end. Now, if the player runs in the same direction when the AI fires, the player will be hit (with some error built in for good measure).
In addition to that, I've worked on re-modeling the projectile class as not just a part of the enemy class, but rather an ability that can be extended from and used for both AI and player alike. I've implemented the basics of how the class will be set up, but I need to do some pair programming with our other ability programmer, Blake. We need to get together and solidify the ability class, so that it properly extends to both the player and AI in a reasonable manner. Hopefully, we'll have a robust ability class that will serve well until the end of the project.
Katana Model
I've taken some free time to do something a little extra for this project. Since the basis of the game is Ninjas vs. Samurai, I took it upon myself to model a little katana for the Samurai to use. Here are some pics of what I made.
I used a tutorial to help me out with the basics whilst adding a little flavor of my own in the blade and hilt. I especially like the hilt design. It's still a bit primitive, but it should work for our alpha build. Just a little something I thought would be fun to do.
Projectile Mechanics
I implemented a system that would allow the guards to fire projectiles at the player. To start, I simply needed to launch a simple projectile. Thus, I modeled a system that let the enemy take in the player's position, create a projectile at the enemy's position, then propel the projectile towards the player's position every update cycle with a given velocity. A relatively simple function, so I expanded the functionality a bit.
First, I developed a projectile manager that would handle any and all projectiles that a guard may use. This would provide a method to create and delete any projectiles that belong to a particular guard.
Second, I implemented a hit detection method for the projectiles. Every projectile would check, every update cycle, whether any of the current player's were colliding with it. The function would return true if a player was colliding with it, and false otherwise.
As of now, it works pretty well. I added a timer so the AI would only fire a projectile every x seconds, and it seems to work well in testing. I did have some problems manipulating the angle of the projectile at first, but I worked it out to face properly. I'll be refining this system to include all types of projectiles, and to compute smarter paths over the next week.
Monday, October 29, 2012
AI Mechanics
I was assigned to help work out the basic AI for our enemies. I assisted in this in two ways.
First, I helped research on the A* path finding algorithm. It was vital for our AI to find the player efficiently, so Ron and myself looked into whether this algorithm would work well. Fortunately, it did seem to fit inside our idea for the game, so I found an implementation of the A*, and sent it to Ron to tweak it to our game.
Second, I implemented an algorithm for the AI to use once it lost sight of a player. I went about this by thinking what it meant for the AI to be searching. I couldn't allow the AI to just automatically know where the player is. Thus, as a basic implementation, I simply let the AI choose a direction, and pursue in that direction for a given time. Then, after that time expired, I would have the AI choose another direction to check.
Our team hadn't finished the guard AI for the time, so I tested this using the player. Fortunately, the player moved in the way I predicted when I assigned this to a movement controller.
Ninja Theme
I've taken some free time to compose a theme for our game. I arranged it to be Japanese in the instrumentation (Koto, Shamisen, Shakuhachi). However, it has a driving beat as well to keep it interesting (I see this as a good first level piece). Have a listen if you want. Enjoy!
*Update*
The latest version has been loaded up now, and hopefully should have, at least, an increased awesomeness of 150%! I added a little to the background to fill out the theme a little, and added a little electric guitar to spice it up a bit! This was to blend a little Western flavor into the game since this game is about the player's avatar becoming a ninja; thus blending styles a bit seemed appropriate.
*Update*
The latest version has been loaded up now, and hopefully should have, at least, an increased awesomeness of 150%! I added a little to the background to fill out the theme a little, and added a little electric guitar to spice it up a bit! This was to blend a little Western flavor into the game since this game is about the player's avatar becoming a ninja; thus blending styles a bit seemed appropriate.
Friday, September 28, 2012
Audio Manager
Since we knew sound was going to be integral to our experience as a bad-ass ninja, I built the Audio
Manager class , and built it so it would be simple to use despite any drastic changes that may come down the
line.
Therefore, I made it a static class that took in a string referencing the audio clip in the Sounds folder. This
made the class easily accessible by anyone that needed to use it. Of course, I had to wrap the function a bit
to be adaptable to what the programmer needed. In particular, the ability to designate whether the sound
needed to be a 3D positional sound or a global sound the player would hear anywhere.
Thus, I built the PlayClip function to split into two functions depending on whether the player supplied a
Vector3 position. The function branches slightly depending on whether a position is supplied or not, but the
overall simplicity of accessing it is more than worth it.
Physics Engine
For our 3D game, we decided it would be prudent to search for an existing XNA physics engine to use for our game. It would save a lot of time to be able to use it to handle all of our collision detection. Looking around, I've found a few that seem to fit the bill. I first looked at Jitter which an utter mess to look at its documentation. Second, I tried JigLibX which was much more user friendly.
When tinkering around with JigLib, I found it rather easily to program in collision detection using their methods, and it seemed to work fairly smoothly. Unfortunately, we ran into some serious problems a week later. It seemed like porting it to the XBOX caused some irrevocable problems (i.e. it crashed). We had to scrap it, and Blake looked for another engine while I worked on other things.
Fortunately, he found the BEPU physics engine which is what we are currently using. The documentation is a little convoluted, but it seems to be working. The only thing we have to figure out soon is how to properly handle collision detection between two specific objects (say a player and shuriken). Hopefully we will figure it out soon and continue forward.
When tinkering around with JigLib, I found it rather easily to program in collision detection using their methods, and it seemed to work fairly smoothly. Unfortunately, we ran into some serious problems a week later. It seemed like porting it to the XBOX caused some irrevocable problems (i.e. it crashed). We had to scrap it, and Blake looked for another engine while I worked on other things.
Fortunately, he found the BEPU physics engine which is what we are currently using. The documentation is a little convoluted, but it seems to be working. The only thing we have to figure out soon is how to properly handle collision detection between two specific objects (say a player and shuriken). Hopefully we will figure it out soon and continue forward.
Debugging Tools
When we first began this project, we immediately decided upon a system that would show programmers vital changing aspects of the game. Thus, I was tasked with building a Debug class.
This dynamic class needed to be able to take any vital information and show it in the upper left hand corner of the game screen. I designed it as a static class that takes in a string which would draw to the screen every update cycle. I made sure to keep track of all the calls to the debug class, so no information would be lost if another call was made.
This has proved to be a vital testing utility for various game aspects. For example, we can easily check the player's current state (i.e. on the ground, in the air, running up a wall).
This dynamic class needed to be able to take any vital information and show it in the upper left hand corner of the game screen. I designed it as a static class that takes in a string which would draw to the screen every update cycle. I made sure to keep track of all the calls to the debug class, so no information would be lost if another call was made.
This has proved to be a vital testing utility for various game aspects. For example, we can easily check the player's current state (i.e. on the ground, in the air, running up a wall).
Thursday, September 6, 2012
5 Games for Ninja Royale
These are fives game I've played/viewed might include some mechanics we'll want to include in our game.
1. Mini Ninjas - It contains a cartoon like style we might want to emulate; it has wall jumping and climbing mechanics; and each character is a little unique which we might want to consider (like players could choose a sub-ninja class). Oh, and how did we not think of a bow and arrow for a weapon!? Video
2. Ninja Gaiden Series - It has smooth gameplay mechanics (including wall jumping), and a crap ton of weapon ideas we could probably use. Just a taste of its many weapons : Shuriken, Windmill Shuriken (basically a huge shuriken that follows you), fire wheel magic, spinning blade, after image effects, fire shield, vacuum blade, etc.
3. Batman: Arkham City - Has a great open world which could inspire map design, and it has many stealth mechanics that a Ninja would be proud to implement.
4. Shinobi (PS2 Remake) - It has many fluid ninja mechanics such as wall jumping, mid-air dashing, wall walking, etc. Plus it has a pretty good ninja running stance for reference. Video
5. LittleBigPlanet 2 - It has many stage elements that could be interesting to use in the game (such as panels that propel you). Plus, it has a wicked grappling hook that has other functions than just grappling on to walls (you can grapple other players for instance). Video
Honorable Mention - Just check out this link. It hasn’t been made yet, but it is similar in the way we might want to work with our battle mechanics.
1. Mini Ninjas - It contains a cartoon like style we might want to emulate; it has wall jumping and climbing mechanics; and each character is a little unique which we might want to consider (like players could choose a sub-ninja class). Oh, and how did we not think of a bow and arrow for a weapon!? Video
2. Ninja Gaiden Series - It has smooth gameplay mechanics (including wall jumping), and a crap ton of weapon ideas we could probably use. Just a taste of its many weapons : Shuriken, Windmill Shuriken (basically a huge shuriken that follows you), fire wheel magic, spinning blade, after image effects, fire shield, vacuum blade, etc.
3. Batman: Arkham City - Has a great open world which could inspire map design, and it has many stealth mechanics that a Ninja would be proud to implement.
4. Shinobi (PS2 Remake) - It has many fluid ninja mechanics such as wall jumping, mid-air dashing, wall walking, etc. Plus it has a pretty good ninja running stance for reference. Video
5. LittleBigPlanet 2 - It has many stage elements that could be interesting to use in the game (such as panels that propel you). Plus, it has a wicked grappling hook that has other functions than just grappling on to walls (you can grapple other players for instance). Video
Honorable Mention - Just check out this link. It hasn’t been made yet, but it is similar in the way we might want to work with our battle mechanics.
Wednesday, March 14, 2012
Pong
This one has a slight issue with scaling, so it's a little large. However, it should play just fine, and you have 5 guesses as to what the theme is...
Tetris
Tetris is a classic, so I will assume you know the gist of how to play it! The music doesn't loop, so it will get a little quiet after some time.
Ultimate Space Shooter of Doom
Because it's always better if it's of doom! The game starts from the get go, so get ready!
Due to my foolish ways in my youth, this game is heavily dependent on its resolution size to function properly. Thus, it's a bit big (you'll probably want to scroll horizontally a bit to see the whole screen).
Due to my foolish ways in my youth, this game is heavily dependent on its resolution size to function properly. Thus, it's a bit big (you'll probably want to scroll horizontally a bit to see the whole screen).
Subscribe to:
Posts (Atom)