I've been working on my platformer game a tiny bit. It has been bugging me how the lava works. It just ramps up in speed until it overtakes the player and they lose. Even if the player does everything right, the lava will eventually flow over them. I want the player to be able stay ahead of the lava wave if they are playing well. Now, the lava has a steady speed that moves slower than the player can run. However, the lava now has a maximum distance that it can get from the player so the threat of the lava catching up is always there if the player messes up a little bit. The problem with this is that the player doesn't have much of a bubble if they come upon a room where they are required to backtrack a little bit. To solve this problem, I made the lava move slightly slower when the player is facing to the left, so when the player has to go up zigzagging platforms or run backwards, they don't get punished so much for it.
I've also been working on a space themed game that I did as a concept a while back. I didn't do much work on it, but it was playable. Original, you controlled the player's "spaceship" with the accelerometers, but I didn't like those controls much, so I recently changed it to just thrust towards the locations of the player's touch. The game has some physics involved so you have to overcome the momentum in the direction you're already moving to change directions. The power of the thrust is directly related to the distance between the player's touch location and the spaceship. The more distance between the two points, the more power behind the thrust. I wanted to illustrate this in game, so I put a thruster flame that comes out of the ship and points in the opposite direction that the player is thrusting, as you would expect. To display to the player the power of the thrust, the flame changes size based on the thrust force.
Here are a couple pictures of the game. In the first picture, the touch point is close to the player and in the second picture the player's touch is farther away, so the flame is much bigger.
Tuesday, December 31, 2013
Saturday, November 30, 2013
More Refactoring and Progress Meter Fix
Haven't been doing much lately that is interesting gameplay wise. Just some more refactoring of my vertical scrolling arcade shooter. Previously I was setting up all my textures for minions in my main game class but after the refactor the texture code for each individual minion is now in the minion class itself. Additionally, I made it so all my minions are set in a certain size since I never ended up making them different sizes anyway. As a result, my constructors for my minions have shrunk significantly in number of arguments required and everything is getting even more self contained. I've also been going through all of my classes and fixing some naming conventions that I had used when first starting the project that I'm no longer particularly fond of. Again, as this is a refactor, a person playing the game would not actually notice anything different about the game.
One thing I've done that isn't a refactor, however, is to fix the level progress meter on the side of the screen. The way it was setup originally was never really great, but it was close enough for what I originally wanted it to do. After I changed up the levels a while back to include waves that were a mix of the two minions of the level, the progress meter code broke down. Yesterday I looked into it for 15 minutes or so and now the progress meter is working even better than it was before it was broken, so I'm pretty happy with the outcome there.
Besides more refactoring and minor performance tweaks, the scrolling shooter is basically how I want it to be now. I just need to get some in-app purchasing going, but for weird Google related reasons, I can't really test any of this stuff without a new test phone. Conveniently though, I'll be getting a new phone soon, so I can do a factory reset on my current one and use that for testing, so I'm pretty excited about that. Once the in-app billing stuff is taken care of, I can start looking around for artists that might be interested in working on the game. I'm a little worried that people might not be into it though as it seems like a very large project with a bunch of animated sprites. Over 20 different minion types that all need to have animations. That seems like a pretty daunting task, but I'm hoping to find somebody who is up to the task because I think its a fun game already and when it looks good as well, it will be really solid.
One thing I've done that isn't a refactor, however, is to fix the level progress meter on the side of the screen. The way it was setup originally was never really great, but it was close enough for what I originally wanted it to do. After I changed up the levels a while back to include waves that were a mix of the two minions of the level, the progress meter code broke down. Yesterday I looked into it for 15 minutes or so and now the progress meter is working even better than it was before it was broken, so I'm pretty happy with the outcome there.
Besides more refactoring and minor performance tweaks, the scrolling shooter is basically how I want it to be now. I just need to get some in-app purchasing going, but for weird Google related reasons, I can't really test any of this stuff without a new test phone. Conveniently though, I'll be getting a new phone soon, so I can do a factory reset on my current one and use that for testing, so I'm pretty excited about that. Once the in-app billing stuff is taken care of, I can start looking around for artists that might be interested in working on the game. I'm a little worried that people might not be into it though as it seems like a very large project with a bunch of animated sprites. Over 20 different minion types that all need to have animations. That seems like a pretty daunting task, but I'm hoping to find somebody who is up to the task because I think its a fun game already and when it looks good as well, it will be really solid.
Sunday, November 10, 2013
Fire Geysers
I've been a little bugged with my platformer game recently because the lava pits are generally too easy to jump over, and the lava wave is far too easy to avoid. To make things a little harder, I started the lava at a slightly faster speed and additionally I have its speed ramp up faster.
I also have added a new obstacle to the game: the Fire Geyser. This obstacle is a little mound on the ground that spits flames that will kill the player if they touch them. As a warning, the geyser shoots out a puff of smoke twice, then the flames shoot out. The smoke doesn't hurt you, but simply serves as an indicator that the flames are coming. It repeats on this cycle in a loop. Some times you need to run back and forth to wait out the flames, and since you cant actually stop running the closest thing to standing still is switching direction fast enough that you don't really go anywhere. Here are some pictures of the Fire Geyser in action:
I also have added a new obstacle to the game: the Fire Geyser. This obstacle is a little mound on the ground that spits flames that will kill the player if they touch them. As a warning, the geyser shoots out a puff of smoke twice, then the flames shoot out. The smoke doesn't hurt you, but simply serves as an indicator that the flames are coming. It repeats on this cycle in a loop. Some times you need to run back and forth to wait out the flames, and since you cant actually stop running the closest thing to standing still is switching direction fast enough that you don't really go anywhere. Here are some pictures of the Fire Geyser in action:
Wednesday, October 16, 2013
Refactoring and New Tweaks
Not a whole lot to report lately. I did a significant amount of refactoring over the past weekend however. Refactoring, by definition results in no real change in the way the client interacts with the code base. As such, the game seems to work in the same way it did before the refactoring, except behind the scenes it is now much more encapsulated after I pulled out a lot of the minion functionality out of the EnemyMinion class and into minion specific classes like Sprayer and and Exploder.
Though it isn't really significant, I made a minor tweak to the way the Boomerang class minion shoots. Previously it would shoot a bullet down that would make a U-Turn to the right side of the screen and then would proceed back up and off the screen. After my little change, there is now a 50/50 chance that the bullet will either U-Turn towards the left side of the screen rather than the right. Very minor tweak but it make the boomerang bullets a little less predictable as before you could just dodge to the left and not have to worry about the return hit.
That's all for now, but I've determined that in the platformer game, the levels need to be significantly more dangerous. At this point it seems far too easy to outrun the lava for long periods of time, and the lava pits aren't all that hard to avoid. It needs to be more of a challenge, but I'm still not sure what obstacles I could add to make it harder. Maybe something like a counterpart of the lava pit but on the ceiling so you can't jump too high. I'll have to keep thinking about that one.
Though it isn't really significant, I made a minor tweak to the way the Boomerang class minion shoots. Previously it would shoot a bullet down that would make a U-Turn to the right side of the screen and then would proceed back up and off the screen. After my little change, there is now a 50/50 chance that the bullet will either U-Turn towards the left side of the screen rather than the right. Very minor tweak but it make the boomerang bullets a little less predictable as before you could just dodge to the left and not have to worry about the return hit.
That's all for now, but I've determined that in the platformer game, the levels need to be significantly more dangerous. At this point it seems far too easy to outrun the lava for long periods of time, and the lava pits aren't all that hard to avoid. It needs to be more of a challenge, but I'm still not sure what obstacles I could add to make it harder. Maybe something like a counterpart of the lava pit but on the ceiling so you can't jump too high. I'll have to keep thinking about that one.
Friday, September 27, 2013
Minion Mixing and Results Popup
I haven't been working on too many projects recently, but I've made a couple improvements to some of my games. First off, in the scrolling shooter, I switched up some of the minion waves. Each level has two types of minions, and previously waves of minions would alternate between the first type and then the second type. Now, every once in a while there will be a wave that is a mix of the two minion types. Also, my cousin Mitch has been testing the shooter for me. I fixed one bug with the reset button he found and he's helping me get the difficulty of the levels more in line with what they should be sequentially. Here is a screenshot of the ghost level with both minion types in the same wave:
Additionally, I've been working on the platformer game and I've put in a results popup window when the level is over. It show how many points you got from collecting gems, how many you got from just surviving in the level, your total score, and what caused your death. It also shows how much distance you've traveled horizontally through the level. That doesn't really factor into your score but I'll probably use it for an achievement of some sort eventually. The popup box also has a "done" button that will close the window and set you up for the next game. Here are a couple screenshots of the results popups:
Additionally, I've been working on the platformer game and I've put in a results popup window when the level is over. It show how many points you got from collecting gems, how many you got from just surviving in the level, your total score, and what caused your death. It also shows how much distance you've traveled horizontally through the level. That doesn't really factor into your score but I'll probably use it for an achievement of some sort eventually. The popup box also has a "done" button that will close the window and set you up for the next game. Here are a couple screenshots of the results popups:
Tuesday, September 3, 2013
Platformer Start Screen and Menu
I haven't added a whole lot to any of my projects recently, but just prior to leaving for the beach over Labor Day weekend, I managed to add some simple (but significant) additions to my platforming game.
First off, I added an actual start screen so you no longer just start running the second that you enter the game, but can now get a little set up and ready, then tap the screen to start running. It isn't anything major, but I think it has a large benefit on the game. Here is a screenshot of my little start screen text graphic:
Additionally, I added a pause menu so the player can now pause, resume, reset, and quit the game. Pausing, resuming, and quitting are basically all taken care of for you, but getting the reset to work actually took more time than I was expecting, mostly because I needed to do some garbage collection on my physics world objects and then set them up again. That is all figured out and working though, so it is quite nice to be able to play a new game without having to quit out first. Here is a screenshot of my super basic pause menu:
Readers of my last post might also notice a slight change to the thermometer gauge. I added a semi transparent background behind the meter to make it a little more visible. Near the top of the gauge there is an orange section of the background. This indicates the real "Danger Zone" because when the thermometer level gets to the orange part, it means that the lava wave chasing you is now on the screen and you are in trouble at this point. I like the way everything is going at this point, but I still want to add a few more UI things.
I would like to have a player report box pop up after the level over that shows how long you lasted on the level, how many gems you collected, and maybe a distance traveled type thing. If you got taken down by the lava wave it could indicate that or show a different icon if you fell in lava pit. Those are the only two things that can kill the player at the moment, but there is likely to be more hazards and traps in the future, so those could all be shown on a results popup.
First off, I added an actual start screen so you no longer just start running the second that you enter the game, but can now get a little set up and ready, then tap the screen to start running. It isn't anything major, but I think it has a large benefit on the game. Here is a screenshot of my little start screen text graphic:
Additionally, I added a pause menu so the player can now pause, resume, reset, and quit the game. Pausing, resuming, and quitting are basically all taken care of for you, but getting the reset to work actually took more time than I was expecting, mostly because I needed to do some garbage collection on my physics world objects and then set them up again. That is all figured out and working though, so it is quite nice to be able to play a new game without having to quit out first. Here is a screenshot of my super basic pause menu:
Readers of my last post might also notice a slight change to the thermometer gauge. I added a semi transparent background behind the meter to make it a little more visible. Near the top of the gauge there is an orange section of the background. This indicates the real "Danger Zone" because when the thermometer level gets to the orange part, it means that the lava wave chasing you is now on the screen and you are in trouble at this point. I like the way everything is going at this point, but I still want to add a few more UI things.
I would like to have a player report box pop up after the level over that shows how long you lasted on the level, how many gems you collected, and maybe a distance traveled type thing. If you got taken down by the lava wave it could indicate that or show a different icon if you fell in lava pit. Those are the only two things that can kill the player at the moment, but there is likely to be more hazards and traps in the future, so those could all be shown on a results popup.
Saturday, August 24, 2013
Game Syncing and Thermometers
I've been working with the Google Play Game Services some more trying to get a player's unlocked levels to sync for accounts across different devices in the scrolling shooter. The Game Services have some cloud saving abilities, but after spending a lot of time trying (and failing) to get it working, I decided to go a different route. Google's documentation of the cloud saving services leaves a lot to be desired, and I found their one example of how to implement it to be a bit of a complicated mess. For my solution, I tried something else, and it is not what Google would ever intend for someone to do and it probably isn't very good practice, but it's working well for me. What I'm doing is when the player starts up a game, I use the Game Services API to get a buffer filled with all the available achievements for the account. Then I step through the buffer and record how many of the achievements are unlocked. Since in the scrolling shooter game, the only achievements will be for completing a level, the number of achievements that are unlocked for the account is the same number of levels completed. Obviously this method wouldn't work if I had achievements for other things like reaching a certain score or beating a level in a certain time, but I have no intention of adding any such achievements so this works out pretty well. The game has a saved preference of how many levels are unlocked, so after I get how many achievements the player has, I compare that to the saved value of unlocked levels. If the number of unlocked levels is less than the number of achievements, I update the unlocked levels to be correct for the account. If the max number of unlocked levels is already saved in the preferences then I don't have to check for this level syncing in the first place and I just avoid any unnecessary calls to the Game Services. It's not how Google intends for people to do things and it's a bit of a hack job, but it's also pretty solid and it seems to be working well, so I'm going to stick with it on this particular app.
In addition to working on the Game Services for my scrolling shooter, I've been adding a bit to my platformer as well. Just recently I added my "danger meter" to the HUD. Its a thermometer and it shows how close the lava wave chasing the player is. As the lava wave gets closer, the level of the thermometer rises, filling the gauge when the lava actually reaches the player. It's really nice because you now have a way of telling when the lava is getting close before it actually appears on the screen. For the most part, its easy to keep the lava far enough away that the thermometer is empty, but since the lava speed ramps up over time, it will eventually catch up and the level of the meter rising lets you know its coming.
Here are a couple screenshots of the thermometer in action:
In addition to working on the Game Services for my scrolling shooter, I've been adding a bit to my platformer as well. Just recently I added my "danger meter" to the HUD. Its a thermometer and it shows how close the lava wave chasing the player is. As the lava wave gets closer, the level of the thermometer rises, filling the gauge when the lava actually reaches the player. It's really nice because you now have a way of telling when the lava is getting close before it actually appears on the screen. For the most part, its easy to keep the lava far enough away that the thermometer is empty, but since the lava speed ramps up over time, it will eventually catch up and the level of the meter rising lets you know its coming.
Here are a couple screenshots of the thermometer in action:
Monday, August 19, 2013
Gem Collecting and Game Services
I've recently updated a little bit of my platforming game. It is entirely cosmetic but I've made it so when the player collects a gem, the gem shoots up into the top left corner where their score is. It isn't that big of a change, but I think I pulled it off pretty well and it definitely looks cool, especial when you collect a couple gems right in a row. I don't think any players will need the confirmation that they did, in fact, collect the particular gem, but I suppose that is an added benefit of having the gem in question slide up to their score text.
I've also been playing around with some of the new Google Play Game Services on the scrolling shooter. I've added a leaderboard and achievement for each level and a Google+ login button on the main screen. Things seem to be going pretty well. I also made it so you now start only with the first level and to unlock each level, you have to first beat the previous level. I might try to get some cloud saving going on since its a part of the Google Plus Game Services package, but the documentation isn't all that great so I might have to scrap it. Conceptually though it would be pretty cool to be able to beat a level on your phone and have it unlocked on say a tablet as well. I'm also going to look into some in-app purchases stuff. All my previous projects have just had a lite version and a full version but I want to start just releasing a single version with limited access and then you can make an in-app purchase to remove ads and unlock all content. So I'm going to be checking that out really soon.
I've also been playing around with some of the new Google Play Game Services on the scrolling shooter. I've added a leaderboard and achievement for each level and a Google+ login button on the main screen. Things seem to be going pretty well. I also made it so you now start only with the first level and to unlock each level, you have to first beat the previous level. I might try to get some cloud saving going on since its a part of the Google Plus Game Services package, but the documentation isn't all that great so I might have to scrap it. Conceptually though it would be pretty cool to be able to beat a level on your phone and have it unlocked on say a tablet as well. I'm also going to look into some in-app purchases stuff. All my previous projects have just had a lite version and a full version but I want to start just releasing a single version with limited access and then you can make an in-app purchase to remove ads and unlock all content. So I'm going to be checking that out really soon.
Wednesday, August 14, 2013
AndEngine PathModifier Tutorial
A lot of my recent AndEngine projects have used a PathModifier for one reason or another. I have a solid understanding of them now and they are pretty straight forward after you get to know them, but I decided to write this tutorial for people who are looking to start using some path modifiers, but don't know where to start. This tutorial assumes the reader is somewhat familiar with AndEngine and has a basic understanding of creating sprites and the like.
Simple Pathing
So, lets say we want to move a sprite along a path. Well first we need a sprite, but there is nothing special we need to do to set the sprite up for pathing. We just make a normal sprite:
Now we have our sprite and we want to move it from its starting location at the coordinates (100, 100) to the coordinates (600, 350). We need to make a new path object for it to follow. In AndEngine, a Path is a series of coordinate points that the sprite will follow. It is important to remember that the sprite's origin point, or the top left corner, is what will actually moving to the points you specify in your path. So lets make our path:
In the first set of parentheses after the word "Path" we specify the number of points we are going to have in our path. In this case, we have two points. After that, we tack on our coordinate points using the ".to(x, y)" function. We start with our origin point in the series of points, then we add on any more points we want in the path.
We now have our Path object set up. We want to make our Sprite follow that path. To do this, we need to add our PathModifier on the Sprite using a call to registerEntityModifier and passing in a new PathModifier.
When we make the PathModifier, we pass in a float representing the number of seconds we want it to take for the sprite to follow the path (in this case it is 3 seconds), our Path object, and and Ease Function. The ease function is how the sprite is going to follow the path. For example, the EaseLinear in the code above will have the sprite move from one point to the next at a consistent speed. When moving a character sprite along a path, I like to use EaseSineInOut, which will cause the sprite to slow down right before they reach a point in the path, and then speed up after leaving a point. I feel it gives a more "natural" feel as things slow down to change direction and such. There are a whole host of EaseFunctions to use. A few are listed below, but there are more and you can check out the AndEngine example app under "Modifiers & Animation" to see them in action.
EaseFunctions
"Advanced" Pathing
The path we just did is cool, maybe for something like a title image sliding onto the screen or our character walking from one point to another. But maybe we want our character to patrol the perimeter of a square building and we want it to move along the path over and over. Well, we can do that.
First, we are going to make a longer, square path:
Notice that this time our path has 5 points. But why do we need 5 points? We are moving in a square, and our square only has 4 corners. Well, we need the first one to establish the origin point of our path and the additional 4 points to move the sprite 4 times (sliding along the 4 sides of the square). We want the path to be a continuous loop, so our first point and our last point are the same. In the first figure in the image below, you can see the path the sprite will take with all five points. The second figure shows the path the sprite will take if we only use 4 points on the path.
So, we now have our path set to follow a square path and return to its original location just by plugging it into our PathModifier up above. But, we want our sprite to repeat this path indefinitely. So lets add in a loop entity modifier, shall we?
And there we go. Our sprite will move in this square continuously until you get rid of the entity modifiers on it.
But we aren't done yet. Path modifiers can be set up with listeners to determine when the path is finished, started, or hits a point on the path. Let's have our sprite do some things as it moves around our square. We'll set up our path modifier with an IPathModifierListener. The listener will require us to override 4 functions: onPathStarted, onPathFinished, onWaypointStarted, and onWaypointFinished. We'll add the path modifier listener and its requisite functions to our LoopEntityModifier.
There we go. We're all set. We just need to add anything we want it to do. We'll start with the onPathFinished function. Lets say we have an integer variable called "LoopCount" and we simply want to increment the loop count whenever we the loop finishes. Piece of cake.
Now, lets rotate our sprite to 180 degrees at the start of each path if LoopCount is even. Why would we do this? Nobody knows, but we can, so we're going to.
In the code above, we check if the loop count is even like we wanted and set the rotation to 180 degrees if it is, or 0 degrees if it is odd. Notice that when we set the rotation of the sprite, we actually use the reference that was passed into the function. Here we have called it pEntity.
There we have it. Our sprite will swap rotations every time it loops around the square. We're almost done with our path here but we have one final thing we want our sprite to do. Every time the sprite reaches the bottom left or the top right corner of our square path, we want to Scale our sprite up to double its normal size and then reset the size back to normal on the other two corners.
Now, here is where things start to get tricky. First, lets mention how "onPathWaypointFinished" and "onPathWaypointStarted" work. In both of the functions, an integer value is passed in, which represents the point on the path that has resulted in the function call. For example, if it is the first point on the path, the number passed in will be 0. With "onPathWaypointFinished", the function is called sprite reaches a point on the path. Alternatively, "onPathWaypointStarted" is called as soon as the sprite starts heading to a point on the path from the previous point. In both cases it is important to realize that for the listener, the origin point is not point 0. Point 0 is the first point the sprite will move to after leaving the origin point.
We want our sprite to change scale every time it reaches the bottom left corner (point 0) or the top right corner (point 2) and have it change back to normal at every other point. Since we dont want it to scale as it move towards the bottom left corner of our path, but rather when it actually reaches the point, we are going to use "onPathWaypointFinished" instead of "onPathWaypointStarted". We're going to use a simple switch statement and the passed in value of pWaypointIndex:
And there you have it. Our sprite is now moving in an endless square shape, upside down every time the loop count is even and doubling its size every time it reaches the bottom left or top right corners.
Path modifiers can be insanely helpful for things in your app. Making title images slide in from off screen, having characters move around, or perhaps having an item slide off the screen after your character collects it. There are a lot of possibilities and a strong understanding of Pathing is great to have if you are working with AndEngine.
I hope this tutorial helps anybody who might stumble across it. If I need to explain anything more clearly or I left something out, please leave me a comment or suggestion.
Simple Pathing
So, lets say we want to move a sprite along a path. Well first we need a sprite, but there is nothing special we need to do to set the sprite up for pathing. We just make a normal sprite:
Sprite ourCharacter = new Sprite (100, 100, CharacterTextureRegion, this.getVertexBufferObjectManager());
Now we have our sprite and we want to move it from its starting location at the coordinates (100, 100) to the coordinates (600, 350). We need to make a new path object for it to follow. In AndEngine, a Path is a series of coordinate points that the sprite will follow. It is important to remember that the sprite's origin point, or the top left corner, is what will actually moving to the points you specify in your path. So lets make our path:
Path ourPath = new Path(2).to(100, 100).to(600, 350);
In the first set of parentheses after the word "Path" we specify the number of points we are going to have in our path. In this case, we have two points. After that, we tack on our coordinate points using the ".to(x, y)" function. We start with our origin point in the series of points, then we add on any more points we want in the path.
We now have our Path object set up. We want to make our Sprite follow that path. To do this, we need to add our PathModifier on the Sprite using a call to registerEntityModifier and passing in a new PathModifier.
ourCharacter.registerEntityModifier(new PathModifier(3.0f, ourPath, EaseLinear.getInstance()));
When we make the PathModifier, we pass in a float representing the number of seconds we want it to take for the sprite to follow the path (in this case it is 3 seconds), our Path object, and and Ease Function. The ease function is how the sprite is going to follow the path. For example, the EaseLinear in the code above will have the sprite move from one point to the next at a consistent speed. When moving a character sprite along a path, I like to use EaseSineInOut, which will cause the sprite to slow down right before they reach a point in the path, and then speed up after leaving a point. I feel it gives a more "natural" feel as things slow down to change direction and such. There are a whole host of EaseFunctions to use. A few are listed below, but there are more and you can check out the AndEngine example app under "Modifiers & Animation" to see them in action.
EaseFunctions
- EaseLinear
- EaseBounceIn, EaseBounceOut, EaseBounceInOut
- EaseElasticIn, EaseElasticOut, EaseElasticInOut
- EaseSineIn, EaseSineOut, EaseSineInOut
- EaseStrongIn, EaseStrongOut, EaseStrongInOut
"Advanced" Pathing
The path we just did is cool, maybe for something like a title image sliding onto the screen or our character walking from one point to another. But maybe we want our character to patrol the perimeter of a square building and we want it to move along the path over and over. Well, we can do that.
First, we are going to make a longer, square path:
Path ourPath = new Path(5).to(100, 100).to(100, 300).to(300, 300).to(300, 100).to(100, 100);
Notice that this time our path has 5 points. But why do we need 5 points? We are moving in a square, and our square only has 4 corners. Well, we need the first one to establish the origin point of our path and the additional 4 points to move the sprite 4 times (sliding along the 4 sides of the square). We want the path to be a continuous loop, so our first point and our last point are the same. In the first figure in the image below, you can see the path the sprite will take with all five points. The second figure shows the path the sprite will take if we only use 4 points on the path.
So, we now have our path set to follow a square path and return to its original location just by plugging it into our PathModifier up above. But, we want our sprite to repeat this path indefinitely. So lets add in a loop entity modifier, shall we?
LoopEntityModifier ourLoop = new LoopEntityModifier(new PathModifier(5.0f, ourPath, EaseSineInOut.getInstance()));
ourCharacter.registerEntityModifier(ourLoop);
And there we go. Our sprite will move in this square continuously until you get rid of the entity modifiers on it.
But we aren't done yet. Path modifiers can be set up with listeners to determine when the path is finished, started, or hits a point on the path. Let's have our sprite do some things as it moves around our square. We'll set up our path modifier with an IPathModifierListener. The listener will require us to override 4 functions: onPathStarted, onPathFinished, onWaypointStarted, and onWaypointFinished. We'll add the path modifier listener and its requisite functions to our LoopEntityModifier.
LoopEntityModifier ourLoop = new LoopEntityModifier(new PathModifier(speed, path, new IPathModifierListener()
{
@Override
public void onPathFinished(PathModifier pPathModifier, IEntity pEntity) { }
@Override
public void onPathStarted(PathModifier pPathModifier, IEntity pEntity) { }
@Override
public void onPathWaypointFinished(final PathModifier pPathModifier, final IEntity pEntity,
final int pWaypointIndex) { }
@Override
public void onPathWaypointStarted(final PathModifier pPathModifier, final IEntity pEntity,
final int pWaypointIndex) { }
}, EaseSineInOut.getInstance()));
ourCharacter.registerEntityModifier(ourLoop);
There we go. We're all set. We just need to add anything we want it to do. We'll start with the onPathFinished function. Lets say we have an integer variable called "LoopCount" and we simply want to increment the loop count whenever we the loop finishes. Piece of cake.
@Override
public void onPathFinished(PathModifier pPathModifier, IEntity pEntity)
{
LoopCount++;
}
Now, lets rotate our sprite to 180 degrees at the start of each path if LoopCount is even. Why would we do this? Nobody knows, but we can, so we're going to.
@Override
public void onPathStarted(PathModifier pPathModifier, IEntity pEntity)
{
if(LoopCount % 2 == 0)
pEntity.setRotation(180);
else
pEntity.setRotation(0);
}
In the code above, we check if the loop count is even like we wanted and set the rotation to 180 degrees if it is, or 0 degrees if it is odd. Notice that when we set the rotation of the sprite, we actually use the reference that was passed into the function. Here we have called it pEntity.
There we have it. Our sprite will swap rotations every time it loops around the square. We're almost done with our path here but we have one final thing we want our sprite to do. Every time the sprite reaches the bottom left or the top right corner of our square path, we want to Scale our sprite up to double its normal size and then reset the size back to normal on the other two corners.
Now, here is where things start to get tricky. First, lets mention how "onPathWaypointFinished" and "onPathWaypointStarted" work. In both of the functions, an integer value is passed in, which represents the point on the path that has resulted in the function call. For example, if it is the first point on the path, the number passed in will be 0. With "onPathWaypointFinished", the function is called sprite reaches a point on the path. Alternatively, "onPathWaypointStarted" is called as soon as the sprite starts heading to a point on the path from the previous point. In both cases it is important to realize that for the listener, the origin point is not point 0. Point 0 is the first point the sprite will move to after leaving the origin point.
We want our sprite to change scale every time it reaches the bottom left corner (point 0) or the top right corner (point 2) and have it change back to normal at every other point. Since we dont want it to scale as it move towards the bottom left corner of our path, but rather when it actually reaches the point, we are going to use "onPathWaypointFinished" instead of "onPathWaypointStarted". We're going to use a simple switch statement and the passed in value of pWaypointIndex:
@Override
public void onPathWaypointFinished(PathModifier pPathModifier, IEntity pEntity,
int pWaypointIndex)
{
switch(pWaypointIndex)
{
case 0:
case 2:
pEntity.setScale(2.0f);
break;
default:
pEntity.setScale(1.0f);
break;
}
}
And there you have it. Our sprite is now moving in an endless square shape, upside down every time the loop count is even and doubling its size every time it reaches the bottom left or top right corners.
Path modifiers can be insanely helpful for things in your app. Making title images slide in from off screen, having characters move around, or perhaps having an item slide off the screen after your character collects it. There are a lot of possibilities and a strong understanding of Pathing is great to have if you are working with AndEngine.
I hope this tutorial helps anybody who might stumble across it. If I need to explain anything more clearly or I left something out, please leave me a comment or suggestion.
Monday, August 12, 2013
Breakable Platforms and Ramps
I've added a couple things to the platform game that I think are pretty cool. First, there is a new platform type that the player has to break through to advance. They can do this by jumping (swiping up on the screen) and then swiping downwards to perform a "Ground Pound" move that shatters the platform allowing the player to fall through. In the screenshot below, you can see the player breaking through a platform.
Also noticeable in the screenshot above is a ramp section in the tunnel. I've added a few new sectors or rooms to the game that have these ramp sections. They go up or down and provide a different type of area that the player can run through, especially in sections like the one in the screenshot below with a lava pit at the top or bottom of a lava pit.
Another addition that I've made is one that I think is pretty cool, but it is also purely cosmetic. When the tunnel background tiles (the pink squares with the blue star in them) are spawned for a sector, there is now about a 10% chance that the background tile will be spawned as a different image. Currently it is just a different color star in the circle, but eventually it can be something cool and related to the theme that will break up the background a little bit. In the screenshot below you can see an instance of two of the "rare" green star tunnel background tiles among the more common blue star tunnel backgrounds.
The game is really coming together now, and besides the addition of some more sector types, I've basically added all the functionality I was wanting. I am hoping to add a couple more HUD things though. One, a meter (possibly in the form of a thermometer to go with the lava theme) on the left side of the screen that acts as a gauge to show the player how close the lava is to reaching them. Second, I would really like to add in something for the gems the player collects where, instead of having them just disappear, the move from the place they are collected up to top left corner of the screen where the score text is located.
Also noticeable in the screenshot above is a ramp section in the tunnel. I've added a few new sectors or rooms to the game that have these ramp sections. They go up or down and provide a different type of area that the player can run through, especially in sections like the one in the screenshot below with a lava pit at the top or bottom of a lava pit.
Another addition that I've made is one that I think is pretty cool, but it is also purely cosmetic. When the tunnel background tiles (the pink squares with the blue star in them) are spawned for a sector, there is now about a 10% chance that the background tile will be spawned as a different image. Currently it is just a different color star in the circle, but eventually it can be something cool and related to the theme that will break up the background a little bit. In the screenshot below you can see an instance of two of the "rare" green star tunnel background tiles among the more common blue star tunnel backgrounds.
The game is really coming together now, and besides the addition of some more sector types, I've basically added all the functionality I was wanting. I am hoping to add a couple more HUD things though. One, a meter (possibly in the form of a thermometer to go with the lava theme) on the left side of the screen that acts as a gauge to show the player how close the lava is to reaching them. Second, I would really like to add in something for the gems the player collects where, instead of having them just disappear, the move from the place they are collected up to top left corner of the screen where the score text is located.
Friday, August 9, 2013
Scrolling Backgrounds and Lava Pits
I've been doing some more work on my platforming game. I'm up to 12 regular sectors now plus a bonus sector. The bonus sector is a really easy hallway with no real obstacles and a lot of easy to collect gems, but the odds of getting one are also much lower relative to the other sectors. I also have a scrolling background going behind the level now that moves at a different rate than the player. I think it gives it a cool look to have the scrolling going on whenever you run or change directions.
After play testing the game quite a bit, I decided that it was too easy to simply outrun the lava wave for long periods of time. Eventually it will catch up to you because it slowly revs up in speed, but you can still go pretty long stretches before it hits you. To up the difficulty a little without making the lava wave just impossible to outrun, I added some lava pit type obstacles to some of the new rooms I've made. These are just little animated pools of lava that the player has to jump over because touching one is an instant game over. They are pretty cool and I'm happy with how they turned out, but in some places I was having trouble with the jumping and making it over the lava pits. The jumping was a little unforgiving so I tweaked it a little to be a bit more accommodating and now players won't have quite so hard a time jumping from platform to platform.
Below we have a screenshot with one of the new lava pits and the background. Its just a dark brown background with some lighter brown spots. I'm thinking this game might eventually looks like its taking place under ground, so I made a "dirt-like" background, but it still looks weird with all my brightly colored platforms and such. Plus it's just a bad background in general. Anyway, here it is:
After play testing the game quite a bit, I decided that it was too easy to simply outrun the lava wave for long periods of time. Eventually it will catch up to you because it slowly revs up in speed, but you can still go pretty long stretches before it hits you. To up the difficulty a little without making the lava wave just impossible to outrun, I added some lava pit type obstacles to some of the new rooms I've made. These are just little animated pools of lava that the player has to jump over because touching one is an instant game over. They are pretty cool and I'm happy with how they turned out, but in some places I was having trouble with the jumping and making it over the lava pits. The jumping was a little unforgiving so I tweaked it a little to be a bit more accommodating and now players won't have quite so hard a time jumping from platform to platform.
Below we have a screenshot with one of the new lava pits and the background. Its just a dark brown background with some lighter brown spots. I'm thinking this game might eventually looks like its taking place under ground, so I made a "dirt-like" background, but it still looks weird with all my brightly colored platforms and such. Plus it's just a bad background in general. Anyway, here it is:
Monday, July 29, 2013
Platfomer Tweaks and Collectables
I've been continuing my work on my platformer game. I'm using some basic Box2D physics and my player object, which was a rectangle shape, kept getting caught on some tiny edges where my floor pieces were connecting. They were at the same height so really there shouldn't have even been anything to get hung up on, but apparently its something that other people have been having trouble with as well. I fixed it by making my character object a hexagon instead, with a point at the bottom so that now instead of getting hung up on those little pieces, the angled surface at the bottom causes the player to just bump over it. So, that's fixed up pretty good now and the game is playing like I want it to.
I've also been adding in some coins type objects for the player to collect. They are actually like diamond/gem type things that are scattered about the sectors and some are worth more than others. The value of the gem is randomly assigned when they are spawned, with the odds of being a low value gem being much higher than the other ones.
I've also added in a threat in the way of a wave of lava that is "chasing" the player. I'm not sure if I'll stick with the lava thing (although it does tend to freak me out in video games) but right now it serves as a reason for the player to be quick about navigating the various rooms and collecting gems.
The gems are pretty easy to collect, but since there is the constant threat of a lava wall that will make grabbing them harder to deal with. There are 3 type of gems: Green, Blue, and Red, which are worth 1, 3, and 7 points respectively. So, maybe the red gem is worth going out of your way for as you leave the green ones behind.
Here is a screenshot with some crazy place holder graphics. The player sprite I'm using is the character from Androidan Summer Games, and all the platform/wall/floor types are different colors so I can tell which piece is which type of object. There is a repeating star background within the "tunnel" the player is running through, and I plan on making the blue background behind the tunnel some sort of scrolling background. The gems are actually pretty good for programmer art, but they don't stand out super well against my carnival colors backgrounds.
I've also been adding in some coins type objects for the player to collect. They are actually like diamond/gem type things that are scattered about the sectors and some are worth more than others. The value of the gem is randomly assigned when they are spawned, with the odds of being a low value gem being much higher than the other ones.
I've also added in a threat in the way of a wave of lava that is "chasing" the player. I'm not sure if I'll stick with the lava thing (although it does tend to freak me out in video games) but right now it serves as a reason for the player to be quick about navigating the various rooms and collecting gems.
The gems are pretty easy to collect, but since there is the constant threat of a lava wall that will make grabbing them harder to deal with. There are 3 type of gems: Green, Blue, and Red, which are worth 1, 3, and 7 points respectively. So, maybe the red gem is worth going out of your way for as you leave the green ones behind.
Here is a screenshot with some crazy place holder graphics. The player sprite I'm using is the character from Androidan Summer Games, and all the platform/wall/floor types are different colors so I can tell which piece is which type of object. There is a repeating star background within the "tunnel" the player is running through, and I plan on making the blue background behind the tunnel some sort of scrolling background. The gems are actually pretty good for programmer art, but they don't stand out super well against my carnival colors backgrounds.
Tuesday, July 23, 2013
Platforming
I've been trying to think of things I want to add to the scrolling shooter, but with the addition of the story type slides to the beginning and end of the levels I think its almost finished up. So, in the last couple day I've started playing around with a new game concept. This time, I'm working on a platformer. I'm going for a dynamic/psuedo-random level design. To do this, I'm making different level sections, which I call "Sectors" that have the same entrance and exit space size. Then I can chain several sectors together to make levels that are different every time. The sectors will remain the same, and the player will see them multiple times, but with enough different sector types the levels should be unique every time. I need some sort of monster or enemy chasing the player through the level, but I'm not sure what to go with yet. Initially I was thinking something like lava flooding the level, and then I was thinking some sort of giant spider, but really I need to focus on some additional level things first. I only have 2 sectors that are being randomly placed right now but that seems to be working pretty well. It still needs a few tweaks but it's definitely good enough to show this game idea has potential.
Thursday, July 18, 2013
Sounds and Stories
Haven't done much that is noteworthy lately, but I have been tinkering with some stuff. In my puzzle game, I've been adding sound effects and getting that all ready. I already has some in place for a while, but they weren't quite playing in the right places. Now I've gotten it all set up and working properly. I'm thinking this game is all set up correctly now. I just need some music assets and such to throw in and it should be already for release.
I've also been adding in some story elements (or preparations for them) to the scrolling shooter. When a new level is started, before the player sprite enters the screen, a dialog type window will pop up on the screen that will eventually show some sort of story graphics. The player clicks on it, it shows the next one, they click the second one and it goes away and the player sprite enters. When the player beats the boss, another box pops up with the same kind of deal only when its over the player sprite leaves the screen. Each level will have 2 intro "slides" and 2 outro slides. When strung together in the order of the levels, this will hopefully create some sort of cohesive overarching storyline. I only have a vague and general idea of the direction of this story, but I don't think it will be too hard to figure out. I don't plan on making it anything complicated with plot twists or anything. I just want it to be pretty straight forward and maybe have some dialog between the player character and the enemy characters. I'm pretty happy with how its looking.
I've also been adding in some story elements (or preparations for them) to the scrolling shooter. When a new level is started, before the player sprite enters the screen, a dialog type window will pop up on the screen that will eventually show some sort of story graphics. The player clicks on it, it shows the next one, they click the second one and it goes away and the player sprite enters. When the player beats the boss, another box pops up with the same kind of deal only when its over the player sprite leaves the screen. Each level will have 2 intro "slides" and 2 outro slides. When strung together in the order of the levels, this will hopefully create some sort of cohesive overarching storyline. I only have a vague and general idea of the direction of this story, but I don't think it will be too hard to figure out. I don't plan on making it anything complicated with plot twists or anything. I just want it to be pretty straight forward and maybe have some dialog between the player character and the enemy characters. I'm pretty happy with how its looking.
Thursday, June 27, 2013
Zeemote Shooter
I've all (I think) of the commenting done on the puzzle game and now I'm trying to get a hold of a friend to possibly do some sound effects for it. Other than that, I've been working on the scrolling shooter a little bit. Mostly minor tweaks not worth mentioning, but also one big addition: Zeemote Support. Several months ago I bought a Zeemote JS1 Controller for the express purpose of adding support for it in my scrolling shooter. I was working on so many more important gameplay issues that I never got around to it, but I recently remembered my initial plan and started looking into it. Thankfully, the Zeemote is actually really easy to get started integrating and it didn't take an crazy amount of time to get it going.
I've added an option on the settings page to enable support of Zeemote bluetooth controllers. It required a little bit of refactoring, but its all set up. You use the joystick to move obviously, and either of the 2 front buttons to shoot. You can hold down the fire button to have it shoot continuously like it does in the normal touch mode, or you can actually wait and time your shots. In that respect, the Zeemote actually gives you an advantage, but, for me at least, the joystick also makes it harder to dodge bullets, although it is quite fun. You can't rapidly tap the fire button to shoot faster than normal though. You'll still have the same "attack speed" as a player not using the Zeemote. This just gives you a lot more control over when the bullet actually fires. I think its a fair trade off. I'm really happy with how its working out and I think its a great option to have in the game.
I've added an option on the settings page to enable support of Zeemote bluetooth controllers. It required a little bit of refactoring, but its all set up. You use the joystick to move obviously, and either of the 2 front buttons to shoot. You can hold down the fire button to have it shoot continuously like it does in the normal touch mode, or you can actually wait and time your shots. In that respect, the Zeemote actually gives you an advantage, but, for me at least, the joystick also makes it harder to dodge bullets, although it is quite fun. You can't rapidly tap the fire button to shoot faster than normal though. You'll still have the same "attack speed" as a player not using the Zeemote. This just gives you a lot more control over when the bullet actually fires. I think its a fair trade off. I'm really happy with how its working out and I think its a great option to have in the game.
Tuesday, June 11, 2013
Puzzle Game Commenting
All the functions of my puzzle game are pretty much done. Now I just want to get it all commented up, but that task is easier said than done. With the recent refactoring of the main game activity and the major overhaul of my story page, there is a lot of new code to document. It needs to be done though. Just good practice and really helpful in the future if I need to update anything. It's a bit daunting though.
Sunday, June 9, 2013
Flamethrowers and Fireballs
Level 10. The final level in the scrolling shooter game. This level is all about fire shooting drones. The two classes of minions are just named after their weapon type: the Flamethrower and the Fireball. The Flamethrower class does what you would think and shoots a flamethrower bullet out in front of it. Unlike other minion types the "flame" moves with minion as it flies around the screen. After a couple seconds, the flame is then shot down the screen like a normal projectile. The second class is the Fireball minion. These guys shoot bullets in a fairly normal fashion, except their projectile is a ball shape instead of the thinner rectangular shape other bullets are. Additionally, the fireball grows as it moves down the screen so they are pretty hard to dodge when they get near the bottom.
Wednesday, June 5, 2013
Refactoring and Multiplayer Possibilities
Been working on my puzzle game lately. Changed up the story page a bit and it is working real well. I took out the previous/next buttons the player was supposed to use to navigate the map, and now your player sprite slides to the level you click on, following the path on the screen. It's working really well. I also did a major refactor on some of the main game activity to incorporate some swipe detection. There is some stuff where I had it set up to just rotate 90 degrees on every click, but I found that it wasn't super intuitive for players, so now if you swipe in a direction things will get rotated in that direction. I also left in the clicking to rotate it 90 degrees though so I personally don't have to relearn the controls. You have both options and the player can go with what they prefer.
I've also been reconsidering working on my zombie maze game. I had some issues with it before that made me put it on the back burner, but now I have a few more ideas of how to go about things. In addition, Google just recently came out with a real time multiplayer API where they do a lot of the heavy lifting for you. They do some quick matching and connection stuff and apparently you just have to format the info you are going to send. It occurs to me that the maze game would be a great candidate for having a 2 player cooperative mode. I might play around with some of the multiplayer stuff a little but I don't think I'll be focusing on it any time soon. I got this puzzle game nearing 100% completion and my scrolling shooter is almost finished too, so now is not the best time to be jumping on to a new big project, but the possibilities this multiplayer API presents are too good not to at least look into.
I've also been reconsidering working on my zombie maze game. I had some issues with it before that made me put it on the back burner, but now I have a few more ideas of how to go about things. In addition, Google just recently came out with a real time multiplayer API where they do a lot of the heavy lifting for you. They do some quick matching and connection stuff and apparently you just have to format the info you are going to send. It occurs to me that the maze game would be a great candidate for having a 2 player cooperative mode. I might play around with some of the multiplayer stuff a little but I don't think I'll be focusing on it any time soon. I got this puzzle game nearing 100% completion and my scrolling shooter is almost finished too, so now is not the best time to be jumping on to a new big project, but the possibilities this multiplayer API presents are too good not to at least look into.
Tuesday, May 28, 2013
Dragons!
Level 9 of my scrolling shooter consists of the inevitable dragon minions. Hopefully, when there are some better graphics in the game, they will be pretty cool looking, but for now they are lizards with semi circle wings. The two dragon minion these: the guardian class the dragonfire class. The guardian minions are orange, and they shoot normal bullets (nothing special about them) but, unlike every other minion type in the game, they take two hits to kill. The first hit will turn the guardian a deeper red color, similar to how the player turns red for a second when they get hit, only the guardian doesn't change back. Once they are red, if they get hit again they are killed. So, they are basically a normal minion with a little more beef. The second class, the dragonfire, is a green dragon. The unique thing about these guys is that they shoot 2 bullets straight down, but one of them is at a much slower speed than the other, so when there are a few of them on the screen at once, you get a hard-to-dodge wall of bullets. Neither of these minion types are quite as exciting as some of the ones from previous levels, but they are actually pretty hard to deal with.
Sunday, May 26, 2013
Puzzle Game Story Mode
For the last year, the story activity in my puzzle game was just a little slideshow the player could flip through to get the little back story that I made up for the game's visual setting. It was pretty lame and kind of misleading since when people see "story modes" they generally think there is going to be some sort of level setup and not just a couple images explaining things. So, I went back and I significantly expanded the story mode. Now there are 10 levels the player can play, each with a specific game mode and a target score. If the player beats the target score, they pass the level and can move on to the next. I've made it so that initially, only "Classic Mode" is available in the game through the normal play menu. By beating a certain levels in story, you gain access to the other game types. Beating all of the 10 levels awards you with a Scoreloop achievement.
Using some of the path modifier stuff I've learned by working on my scrolling shooter, I've made a cool little navigation setup. It's kind of like moving around levels in Super Mario Bros. in that you have a little player sprite, and going in the direction of the next level moves the sprite to the next level area and the camera follows. To explain the story, I still have something similar to the "slideshow" I mention previously, but now that is brought up on the screen by tapping a little circle with an "i" in it, which is a common symbol for 'additional information'. You flip through the slideshow using the same previous/next buttons that you use to move your character through the level. It still isn't the greatest way to get story elements across to the player, but the 10 challenge levels is something that I'm really happy about adding to the game.
Using some of the path modifier stuff I've learned by working on my scrolling shooter, I've made a cool little navigation setup. It's kind of like moving around levels in Super Mario Bros. in that you have a little player sprite, and going in the direction of the next level moves the sprite to the next level area and the camera follows. To explain the story, I still have something similar to the "slideshow" I mention previously, but now that is brought up on the screen by tapping a little circle with an "i" in it, which is a common symbol for 'additional information'. You flip through the slideshow using the same previous/next buttons that you use to move your character through the level. It still isn't the greatest way to get story elements across to the player, but the 10 challenge levels is something that I'm really happy about adding to the game.
Wednesday, May 8, 2013
Genies and Tornadoes
Back to my scrolling shooter. After my brother suggested a level with Genie characters, I came up with what is currently Level 8. As always, there are two minion classes, both genies, and they shoot tornadoes in different ways. The Cyclone class shoots a tornado straight down, similar to many other minions in the game, but once it reaches a certain distance from its origin point, it breaks into 2 tornadoes that go off at different angles. Its kind of a mix of bullet behaviors from previous levels. The second class of minion on this level is the Seeker class. The tornado bullets they shoot actually have decent homing capabilities. They will travel down the screen at a set speed, but will change direction horizontally to go towards the player. This results in the player often needing to move up the screen to get the bullets behind them. It can be pretty challenging if you don't clear the seeker minions out fast enough. Below are some screenshots of my beautiful genie minions and yet another boring placeholder background (the tan triangles are supposed to be something akin to a tornado or dust devil).
Monday, May 6, 2013
Tutorials and Roulette
Recently I released a new app called the Lucky Roulette Picker. This was just a little app I thought of one night and pumped out the next day. It's basically a random number generator that picks what you should bet on in a game of casino style roulette. It generates a choice for the possible options in the 1-to-1, 2-to-1, and 35-to-1 payout areas of the board. It is a free only app with an ad at the bottom. It's super simple and it only took me a day to make, so selling it wouldn't work out too well. Still, its a funny little app and, as a fan of roulette, I'm pretty happy with it. The Lucky Roulette Picker is available Google Play:
Additionally, I've been working on my scrolling shooter some more. Of course it needs a "How to Play" section for people to learn how the game works. I think most people will pick it up quickly because its nothing revolutionary, but people that aren't super familiar with arcade style scrolling shooters might need a refresher. In my other games, the how to play sections have just been simple slideshow type deals where you scroll through the instructions until you get to the end. However, this tutorial I'm pretty proud of. Its an active tutorial and you have to participate in the basic elements of the game to advance. The first stage requires you to move to two markers on the screen, the second part has you shoot two stationary targets. Then you have to shoot two moving minion (that don't shoot back). Then the tutorial shows how taking damage works and you have to take a hit from another minion to advance. After that, it walks you through how the powerups work and you have to collect one of each. Finally, it describes how the boss battles are triggered and has you defeat a boss that doesn't move or shoot, but this illustrates how the boss bar works and such. After that, it will start you out on the first level. I'm really happy with how it works and I think it will help a lot of new players.
Additionally, I've been working on my scrolling shooter some more. Of course it needs a "How to Play" section for people to learn how the game works. I think most people will pick it up quickly because its nothing revolutionary, but people that aren't super familiar with arcade style scrolling shooters might need a refresher. In my other games, the how to play sections have just been simple slideshow type deals where you scroll through the instructions until you get to the end. However, this tutorial I'm pretty proud of. Its an active tutorial and you have to participate in the basic elements of the game to advance. The first stage requires you to move to two markers on the screen, the second part has you shoot two stationary targets. Then you have to shoot two moving minion (that don't shoot back). Then the tutorial shows how taking damage works and you have to take a hit from another minion to advance. After that, it walks you through how the powerups work and you have to collect one of each. Finally, it describes how the boss battles are triggered and has you defeat a boss that doesn't move or shoot, but this illustrates how the boss bar works and such. After that, it will start you out on the first level. I'm really happy with how it works and I think it will help a lot of new players.
Wednesday, April 24, 2013
Deflector Shields and Lasers
Level 7 of my scrolling shooter game has laser satellite minions. The first type is the "waveshot" class. These minions shoot like other normal minions, except their bullets are wider, laser waves. Basically their bullets are just like the normal bullets in other levels, but rotated 90 degrees. The second minion class is the "reflector". These guys occasionally put up a laser shield in front of themselves and when a player bullet hits the shield, it is reflected back towards the player as an enemy bullet. The reflectors are pretty hard because they shoot their own bullets, plus reflect your own bullets back at you. It can get pretty hectic if there are a lot of reflectors going. Here are a couple screenshots of that level, still with one of my awful test backgrounds:
Sunday, April 21, 2013
Disc Golf and Lignting Bolts
I just recently released a new app called Disc Golf Cataloger. It's extremely similar to my previously released Nail Polish Cataloger, except that it is an app that I will actually use. Developing it also led to some cool new features in both the disc golf and the nail polish app. I added in some stuff people were asking for, like the ability to add notes to entries or sort by things like brand instead of just name. I also added some auto-backup things to make sure you don't lose your catalog. So, that's available now on Google Play:
Now, on to details about Level 6 of my scrolling shooter. This one is a lightning themed level. I'm not 100% sure what the minions will be visually, but they are currently angry storm clouds in my programmer art version. It's very intense... Anyway, the first minion class is called the "Zigzag", because when they shoot their bullets, the bullets zigzag back and forth down the screen. They are actually pretty hard to dodge if there are more than just a few. The second minion class is boringly named the "Pauser" because when they fire a bullet, it pauses for a short duration at its origin point before quickly shooting down the screen. When there are multiple pausers flying around you end up getting this big section of lightning bullets that are just waiting at the top of the screen, and then they all swarm down on you. It's actually pretty cool, I'm just disappointed that I didn't use a better minion class name, but that isn't really important. Here are some pictures of my awful storm cloud minions with my terrible recolored test background that should illustrate just how little I cared about making the graphics for this level:
So, that is level 6. I'm actually currently working on the last level since I finally came up with some minion ideas for it. Levels 7, 8, and 9 are already done so I will post about those in the future.
Now, on to details about Level 6 of my scrolling shooter. This one is a lightning themed level. I'm not 100% sure what the minions will be visually, but they are currently angry storm clouds in my programmer art version. It's very intense... Anyway, the first minion class is called the "Zigzag", because when they shoot their bullets, the bullets zigzag back and forth down the screen. They are actually pretty hard to dodge if there are more than just a few. The second minion class is boringly named the "Pauser" because when they fire a bullet, it pauses for a short duration at its origin point before quickly shooting down the screen. When there are multiple pausers flying around you end up getting this big section of lightning bullets that are just waiting at the top of the screen, and then they all swarm down on you. It's actually pretty cool, I'm just disappointed that I didn't use a better minion class name, but that isn't really important. Here are some pictures of my awful storm cloud minions with my terrible recolored test background that should illustrate just how little I cared about making the graphics for this level:
So, that is level 6. I'm actually currently working on the last level since I finally came up with some minion ideas for it. Levels 7, 8, and 9 are already done so I will post about those in the future.
Friday, March 29, 2013
Robot Birds and Razor Blades
I've made a couple more levels in my scrolling shooter game, but for now I'll just go over what is currently the 5th level. In this level, the enemies are robot birds. There is the "Layer" class and the "Boomerang" class of minion. The Layer gets its name because when it is killed, it leaves behind (or lays) a robot egg pod thing. The player must kill this also or in 3 seconds it hatches into a miniature version of the Layer called a Hatchling. With the Boomerang class, their projectiles are quite unique for minions in the game. They shoot out their spinning razor blade bullets, which go out to a specific distance from the bottom of the screen and then hook back and leave the screen at the top. Basically the bullets follow a tight, long U shaped path and if you aren't paying attention, you can get hit by the returning bullet that you previously dodged. Overall I'm pretty happy with this level. The enemies are unique and it is pretty challenging. Right now it is only level 5 (I want to get at least 10 levels in the game upon release) but I think I might have to move it back to be later in the game on account of the difficulty level. Below are some pictures of my crappy MS Paint robot birds (the background is my crappy test background
Friday, March 22, 2013
Pink and Yellow Ghosts
So, I've been doing some more work on the game, but I haven't added in that level select menu. I have, however, I've completed my ghost level. There are two types of ghost minions, as with all other levels. The first ghost minion class is called the "Fader" and it is currently a pink guy that shoots normal bullets, but the thing with him is that he is in his transparent white/invulnerable mode most of the time, so you have to wait until he 'materializes' to kill him. It really just becomes an exercise in timing to take these guys down. The second minion is the "Confuser" class ghost and they look similar to the Faders but they are yellow. These guys shoot normal bullets like the Fader, but they also shoot a yellow confuse ray bullet. These bullets don't damage the player, but it applies the "confusion" debuff I added to the game.
The Confusion debuff screws with the player's controls. It turns the player a yellow hue so you know whats going on, but it also reverses the player's control in the X direction. So, if your finger is on the right side of the screen, your player sprite will be on the left. It doesn't mess with your controls in the Y direction though. That would be too mean. The confusion lasts for like 3 seconds and then it wears off. You get a half-second shield at the beginning and end of the confusion, just as a courtesy so that the sudden change in location of your sprite doesn't make you run into 5 bullets on the other side of the screen. Below are a couple screenshots of the new minions.
There's also a quick graveyard/fog background going on, but hopefully it will be something cooler in the final version. I still want to get a few more of my level ideas completed, but I really should start working on the level select menu I've talked about. These levels are starting to pile up and even though I can skip through them, its still kind of annoying when I need to test the same level repeatedly. I'll see if I can resist the urge to add more minion types and actually get some menu work done.
The Confusion debuff screws with the player's controls. It turns the player a yellow hue so you know whats going on, but it also reverses the player's control in the X direction. So, if your finger is on the right side of the screen, your player sprite will be on the left. It doesn't mess with your controls in the Y direction though. That would be too mean. The confusion lasts for like 3 seconds and then it wears off. You get a half-second shield at the beginning and end of the confusion, just as a courtesy so that the sudden change in location of your sprite doesn't make you run into 5 bullets on the other side of the screen. Below are a couple screenshots of the new minions.
There's also a quick graveyard/fog background going on, but hopefully it will be something cooler in the final version. I still want to get a few more of my level ideas completed, but I really should start working on the level select menu I've talked about. These levels are starting to pile up and even though I can skip through them, its still kind of annoying when I need to test the same level repeatedly. I'll see if I can resist the urge to add more minion types and actually get some menu work done.
Thursday, March 14, 2013
Shields and Slimes
Well, I got a lot of what I mentioned in my previous post completed. When the player takes a hit, the phone vibrates for something like .125 seconds (oddly, fractions of a second longer felt like it was too long). In addition, when the player takes damage, their sprite will now flash red for a split second as further feedback that they were hit. In the screenshot below, the player sprite is flashing red because it has just collided with an enemy minion.
I also implemented the shield feature I wanted to get in there. Minions now have a chance to drop the shield powerup, and should they player collect it, they are rewarded with 5 seconds of invulnerability where colliding with enemy sprites will not damage them, but will also not hurt the enemy minion (it will however remove enemy bullets from the screen). If the player collides with a boss, they will be given a similar shield that only lasts 2 seconds, but gives them enough time to reposition their sprite where they won't be hit by the boss again. In the screenshot below, you can see the dashed oval of the shield around the player sprite, along with some new minion types that I will be getting to.
I've added another level to the game. This one is composed of squirmy black slime creatures. The two minion classes for these guys are "splitter" and "exploder". The splitters are the ones shown in the screenshot above. When you shoot them, they split into two smaller versions of themselves (designated as "splits") that must also be destroyed to advance. These guys don't shoot to much because the number of enemy bullets can get quite overwhelming to deal with when you have a bunch of splits swirling around. The second class of minion for this level is the exploder. In my temporary paint graphics, they look like black squids, as you can see in the screenshot below. These guys explode when they are killed, releasing 3 bullets out , so if you kill a wave of them in quick succession you have to deal with a wall of bullets coming down towards you.
For my next level, I'm going to try to make some ghost type minions. I'm not sure what their unique little deal is going to be yet, but at least one of the types will go invisible or transparent. I'm learning a lot about AndEngines various modifiers with this project and I think I will be able to do some cool ghost stuff with the AlphaModifier. I also need to start thinking about making a level select menu page now that I'm starting to get more and more levels going. I rigged the menu button on the device to skip you to the next level but I'm going to need a level select menu eventually anyway, so I might start playing around with that soon. I have some interesting boss ideas so I'm looking forward to implementing those as well. Still a long way to go, but the project seems pretty promising so far.
Saturday, March 9, 2013
Multiple Levels
My recent work on my scrolling shooter game has resulted in both levels being playable, without having to change any code and reinstall the game. As I've been wanting to do, I have added the code needed to switch levels once a boss has been defeated. Since there are only 2 levels in my game right now, it isn't particularly hard to beat the game, but I can easily see this amount available in the Lite version of the game (with some better graphics and a few additions of course).
I also added some pathing for the player sprite when a level begins and ends. When the level starts the player's sprite rises on to the screen from the bottom. There is an image on the HUD displaying what the current level is. After a couple seconds, this display disappears and the player assumes control of their sprite. Similarly, when the boss of the level is defeated, the words "Level Cleared!" are displayed, and the player sprite follows a path off the screen at the top. The level of the game then increments and the next level is handled in a similar fashion.
Everything seems to be going pretty well and the game is nice an playable at present. I might need to look into my level progress bar again as it seems to be a little off at the end of the game. It might be a threading issue, but it isn't currently on the top of my priority list, so I'm not too concerned. What I am more concerned with is how to handle a collision between the player and a boss sprite. It was a non-issue with player/minion sprite collisions as I simply damage the player, kill the minion, and the game continues. However, since I can't just kill off the boss during a collision, it becomes more of an issue. I currently have the player being "teleported" back down to the very bottom of the screen if they collide with the boss, hoping to move them out of the way. If they were simply left there, another collision between the boss and the player would be detected and the player would be dead before they understood what was happening. This method worked pretty well, until I made the second boss dive low on the screen. When the player is teleported, they are still (at times) within the collision distance to the boss, so they still get hit multiple times. Obviously this isn't good for the player because they should always be able to tell when they are being hit. As a result, I've decided to trigger 2-3 seconds of invulnerability when the player hits the boss. They will still take a single hit of damage, but assuming they survive that hit, they will not take damage for another 2-3 seconds. When I have this functionality added, I will also be able to make a 3rd powerup that allows the player several seconds of invulnerability, similar perhaps to a star in any of the Mario Bros. games, but I likely wont give the player the ability to destroy minions via collision while in the invulnerable state.
Keeping in line with my thoughts on making sure the player realizes when they take damage, I'm also going to cause the player's device to vibrate whenever they take a hit. There will be a button to toggle this feature off in the eventual settings page, of course, but I think it is something most players will benefit from leaving on.
I also added some pathing for the player sprite when a level begins and ends. When the level starts the player's sprite rises on to the screen from the bottom. There is an image on the HUD displaying what the current level is. After a couple seconds, this display disappears and the player assumes control of their sprite. Similarly, when the boss of the level is defeated, the words "Level Cleared!" are displayed, and the player sprite follows a path off the screen at the top. The level of the game then increments and the next level is handled in a similar fashion.
Everything seems to be going pretty well and the game is nice an playable at present. I might need to look into my level progress bar again as it seems to be a little off at the end of the game. It might be a threading issue, but it isn't currently on the top of my priority list, so I'm not too concerned. What I am more concerned with is how to handle a collision between the player and a boss sprite. It was a non-issue with player/minion sprite collisions as I simply damage the player, kill the minion, and the game continues. However, since I can't just kill off the boss during a collision, it becomes more of an issue. I currently have the player being "teleported" back down to the very bottom of the screen if they collide with the boss, hoping to move them out of the way. If they were simply left there, another collision between the boss and the player would be detected and the player would be dead before they understood what was happening. This method worked pretty well, until I made the second boss dive low on the screen. When the player is teleported, they are still (at times) within the collision distance to the boss, so they still get hit multiple times. Obviously this isn't good for the player because they should always be able to tell when they are being hit. As a result, I've decided to trigger 2-3 seconds of invulnerability when the player hits the boss. They will still take a single hit of damage, but assuming they survive that hit, they will not take damage for another 2-3 seconds. When I have this functionality added, I will also be able to make a 3rd powerup that allows the player several seconds of invulnerability, similar perhaps to a star in any of the Mario Bros. games, but I likely wont give the player the ability to destroy minions via collision while in the invulnerable state.
Keeping in line with my thoughts on making sure the player realizes when they take damage, I'm also going to cause the player's device to vibrate whenever they take a hit. There will be a button to toggle this feature off in the eventual settings page, of course, but I think it is something most players will benefit from leaving on.
Wednesday, March 6, 2013
Points and a 2nd Boss
I've recently completed my second level boss. I find it to be sufficiently difficult. It shoots two large bullets at diagonals in a similar fashion to the sprayer class minions that constitute half of the level. He also dives quite low on the screen at times similar to the striker minions on the level. I think its a fitting boss fight.
Also, I added a point system. Its pretty straight forward: the player gains 100 points for killing an enemy minion, they lose 20 points for taking a hit, and get 1000 points for defeating a boss. In addition, the player loses 10 points every 1.5 seconds, resulting in a higher score the faster you complete the level. It works out pretty good, but also allows for some differentiation between player scores on a future leaderboard.
In addition, I altered the way minion spawning works. Previously, it simply assigned a path to the minions based on how many were in the wave, which got to be a little bit to predictable for my liking. While I want the minions to be a little bit predictable (so that the more you play, the easier it is to defeat them), I also don't want the game to go stale after only a few plays. So, now the game "shuffles" the paths before assigning them to a minion. When the max number of minions is spawned, the player will see no difference, but when only say two or three minions are spawned, they will randomly be assigned one of the available paths. This will cause the minion path combinations to be different from time to time, which is exactly what I'm looking for.
Also, I added a point system. Its pretty straight forward: the player gains 100 points for killing an enemy minion, they lose 20 points for taking a hit, and get 1000 points for defeating a boss. In addition, the player loses 10 points every 1.5 seconds, resulting in a higher score the faster you complete the level. It works out pretty good, but also allows for some differentiation between player scores on a future leaderboard.
In addition, I altered the way minion spawning works. Previously, it simply assigned a path to the minions based on how many were in the wave, which got to be a little bit to predictable for my liking. While I want the minions to be a little bit predictable (so that the more you play, the easier it is to defeat them), I also don't want the game to go stale after only a few plays. So, now the game "shuffles" the paths before assigning them to a minion. When the max number of minions is spawned, the player will see no difference, but when only say two or three minions are spawned, they will randomly be assigned one of the available paths. This will cause the minion path combinations to be different from time to time, which is exactly what I'm looking for.
Saturday, March 2, 2013
Bosses and Explosions
I've recently made several exciting additions to the scrolling shooter. First of all, I added the explosions I wanted to get in there. Now, when you kill an enemy minion, the sprite is quickly replaced with an animated explosion. Its simple enough, but I actually ran into some annoying problems with it when I was adding it in. It turned out to be a rather simple threading issue, but it took me quite a while to track down after a decent amount of debugging, so that was annoying. Everything is fixed now and the explosions are working quite well.
I've also been working on getting some bosses added to the game. I have some cool polymorphism going so that I can have each boss be a separate child class of my base "Boss" class. The first boss is pretty easy, moving from left to right on the screen, occasionally shooting overly large bullets at the player. they are easy to dodge and the pattern they are shot at is very simple, but that's pretty much what I'm looking for out of a first boss. In addition to the boss, I've added the bar I mentioned in my last post that shows how close to the boss the player is. A small icon moves up the bar and when it's at the top, the boss appears. I also made it so that when the boss appears, this "progress bar" is replaced by the boss's health meter. Making use of the above mentioned explosions, when the boss dies it is replaced by 6 explosion animations and the player beats the level.
I've created minions for a new level, but the game only plays one hard coded level at a time. Currently I have the second level's minions combined with the first level's boss. The second level minions are bugs that come in two classes that I have deemed "Sprayers" and "Strikers". The Sprayers shoot two slow-moving bullets at a time at diagonals. They don't shoot very frequently, but there ends up being quit a few bullets on the screen when there are multiple Sprayers flying around. The Striker class minions don't shoot bullets at all, but their movement paths cause them to dive very low on the screen and the player has to either kill or dodge them as they make their charge. These minions also tend to move quite fast so the player has to have quick reflexes. In the screenshots below, the green bugs are the Sprayers while the red ones are the Strikers, both flying around above my MS Paint lava flow background. The red and gray triangle is the player sprite and the small blue triangles are the player's bullets.
I've also been working on getting some bosses added to the game. I have some cool polymorphism going so that I can have each boss be a separate child class of my base "Boss" class. The first boss is pretty easy, moving from left to right on the screen, occasionally shooting overly large bullets at the player. they are easy to dodge and the pattern they are shot at is very simple, but that's pretty much what I'm looking for out of a first boss. In addition to the boss, I've added the bar I mentioned in my last post that shows how close to the boss the player is. A small icon moves up the bar and when it's at the top, the boss appears. I also made it so that when the boss appears, this "progress bar" is replaced by the boss's health meter. Making use of the above mentioned explosions, when the boss dies it is replaced by 6 explosion animations and the player beats the level.
I've created minions for a new level, but the game only plays one hard coded level at a time. Currently I have the second level's minions combined with the first level's boss. The second level minions are bugs that come in two classes that I have deemed "Sprayers" and "Strikers". The Sprayers shoot two slow-moving bullets at a time at diagonals. They don't shoot very frequently, but there ends up being quit a few bullets on the screen when there are multiple Sprayers flying around. The Striker class minions don't shoot bullets at all, but their movement paths cause them to dive very low on the screen and the player has to either kill or dodge them as they make their charge. These minions also tend to move quite fast so the player has to have quick reflexes. In the screenshots below, the green bugs are the Sprayers while the red ones are the Strikers, both flying around above my MS Paint lava flow background. The red and gray triangle is the player sprite and the small blue triangles are the player's bullets.
My next objectives include adding in a point system, making the second boss, and then getting the game to the point where a second level starts when the first level is beaten. From there I can start working on even more levels with more exciting minions and different bosses.
Sunday, February 24, 2013
Bullets and Power ups
I've added a decent amount of functionality to the scrolling shooter. First of all, there is a player "character" that is controlled by dragging your finger around the screen. The player sprite shoots a bullet every 1.5 seconds, so there is no need to tap a fire button or anything messy like that. The enemy sprites also shoot back now, and as a result there is a health meter depicting the player's current status. The first "level" currently in the game consists of waves that alternate between two minion types. The different types have different path patterns that they fly around in. As you get past waves, subsequent waves start having more minions in them. After something like 12 waves, the level is completed. Right now nothing happens at this point, minions just stop spawning. In the future, a boss character will appear. I'll be working on that soon.
I've also added power ups into the game. Currently there are only two types: health and bullet increase. There is a chance that either type will be spawned when an enemy minion is destroyed. As you might expect, collecting the health power up heals the player for one hit. Collecting the bullet increase power up increments the number of bullets the player shoots. By default the player shoots a single bullet straight forward. Collecting the power up will cause them to shoot two bullets away from them in a diagonal line. If the power up is collected a third time, they will shoot the two bullets at a diagonal as well as the straight forward bullet for a total of three bullets. The "3 Bullets" level is where it is capped. Picking up the power up after that won't do anything. However, taking a hit from an enemy minion will cause the bullet level to drop down one tier, with the default being the minimum. The health power up spawns less frequently than the bullet power up, but both of their drop rates will need some tweaking as it is too easy to stay at bullet level 3 and close to full health.
My next priorities are adding explosion animations when an enemy minion is killed, making some of the minion paths a little better, and then adding in a level boss when all the waves are cleared. Tia and I talked about putting a meter vertically along one side of the screen to show how close to the boss fight the player is, so I'm going to try to get working on that as well. Overall things are going good and the game is actually playable. Its easy to see that this game has a lot of potential, provided I can make the levels varied enough to keep it from going stale.
I've also added power ups into the game. Currently there are only two types: health and bullet increase. There is a chance that either type will be spawned when an enemy minion is destroyed. As you might expect, collecting the health power up heals the player for one hit. Collecting the bullet increase power up increments the number of bullets the player shoots. By default the player shoots a single bullet straight forward. Collecting the power up will cause them to shoot two bullets away from them in a diagonal line. If the power up is collected a third time, they will shoot the two bullets at a diagonal as well as the straight forward bullet for a total of three bullets. The "3 Bullets" level is where it is capped. Picking up the power up after that won't do anything. However, taking a hit from an enemy minion will cause the bullet level to drop down one tier, with the default being the minimum. The health power up spawns less frequently than the bullet power up, but both of their drop rates will need some tweaking as it is too easy to stay at bullet level 3 and close to full health.
My next priorities are adding explosion animations when an enemy minion is killed, making some of the minion paths a little better, and then adding in a level boss when all the waves are cleared. Tia and I talked about putting a meter vertically along one side of the screen to show how close to the boss fight the player is, so I'm going to try to get working on that as well. Overall things are going good and the game is actually playable. Its easy to see that this game has a lot of potential, provided I can make the levels varied enough to keep it from going stale.
Friday, February 15, 2013
Enemy Minions
Been doing a little more work on the scrolling shooter lately. I cleaned up a little bit of the scrolling background code and it is now working fantastic. It was pretty good before, but if you changed the background enough times, the animation started to get choppy because the previous backgrounds weren't getting detached. That's all fixed up and its running smoothly.
In addition, I've started adding enemy sprites to the game. There is no player character yet, so the enemies, which I have dubbed "minions", go unopposed, but they fly around a bit while the background scrolls beneath them and it looks pretty cool. I read in the minion type and number for the wave from an xml file and then spawn the number of minions and send them out on a specific path to move along. Currently there is only one minion type, but that will change and the minions will have different paths depending on their designated type.
After I play around with the pathing a bit, I need to add a player ship so that you can actually fight the minions. I might make the minions shoot (at nothing) first. I'm not sure yet. So many options.
In addition, I've started adding enemy sprites to the game. There is no player character yet, so the enemies, which I have dubbed "minions", go unopposed, but they fly around a bit while the background scrolls beneath them and it looks pretty cool. I read in the minion type and number for the wave from an xml file and then spawn the number of minions and send them out on a specific path to move along. Currently there is only one minion type, but that will change and the minions will have different paths depending on their designated type.
After I play around with the pathing a bit, I need to add a player ship so that you can actually fight the minions. I might make the minions shoot (at nothing) first. I'm not sure yet. So many options.
Saturday, February 9, 2013
Puzzle Game and Scrolling Backgrounds
Been a while since I posted but I've got a little bit going on. Nearly a year after starting work on my puzzle game (and my first taste of AndEngine) I finally feel like it is ready for release. It still needs good graphics (the ones I made are terrible MS Paint things) and some sound effects to go with the new graphics. Other than that, all the functionality is there, Scoreloop leaderboards for the 5 game modes, a cool power-up I added, and some pretty cool achievements to earn by doing specific things and playing the additional game modes. I'm pretty excited about how far the game has come. It is somewhat similar to games like Bejeweled so fans of that type of game will enjoy it, but at the same time has elements that make it unlike any puzzle game I've personally seen. I'm pretty happy with how original of a concept it is.
The other project I've just started recently is a top down, vertical scrolling shooter. I haven't done much work on the actual code yet, but Tia and I have spent quite a bit of time hashing out things like characters, a little bit of the storyline, bosses, power-ups, and some of the general look of the game. Going only off of the notes I have in my notebook and the images I have in my head, its looking pretty great.
With this game I'm trying to do a significantly better job of encapsulating code, and I'm off to a pretty good start with the very little I've done so far. I'm starting with the aspects of AndEngine I'm unfamiliar with in an attempt to figure them out before there is a lot of other pieces fit in. So far I've just scratched the surface with some Parallax Background work. Basically a parallax background is set up so you have a main background that slowly scrolls, and then another background layer composed of background objects like clouds, that move at a slightly faster rate, giving a "realistic" appearance to the background. Since the player in this new game will be flying at what is presumably a great height, the ground should appear to be moving underneath them at a slower rate than the closer objects, like the clouds, and then both backgrounds continuously scroll on repeat. AndEngine has a nice Parallax Background class, but for some reason the official stuff only supports horizontal scrolling (not good for a vertical scrolling shooter). Luckily, a quick search of the AndEngine forums turned up some modified code some community members had worked on that fix the issue.
So, I started out by just having a light blue background with a big black X on it so I could tell if it was moving. For the foreground I put some oddly colored triangles pointing out. I don't know why I went with that decision, but it worked out all right. This is what it looks like:
Then, partially to test out my encapsulated background code but more to have a better example of the reasoning behind the parallax background, I made a second set of background that are clouds over a grassy area with a lake, some streams, and what I guess is a road leading up to the lake, again in MS Paint. It turned out surprisingly good for the time I put in:
This second background really illustrates what I'm going for here. The clouds scroll downward at a little over twice the speed of the "ground" under them. I'm really happy with how it turned out and I'm excited with the possibilities for additional "levels". Canyons, cities, some sort of volcano. All good options. I just need to keep myself motivated with this new game. The amount of stuff I have to work on to bring it to where I want it to be is a little daunting to be doing solo, especially given the fact that my most complicated game took a year to finish and probably wont see release for quite some time. We'll see how it all goes.
The other project I've just started recently is a top down, vertical scrolling shooter. I haven't done much work on the actual code yet, but Tia and I have spent quite a bit of time hashing out things like characters, a little bit of the storyline, bosses, power-ups, and some of the general look of the game. Going only off of the notes I have in my notebook and the images I have in my head, its looking pretty great.
With this game I'm trying to do a significantly better job of encapsulating code, and I'm off to a pretty good start with the very little I've done so far. I'm starting with the aspects of AndEngine I'm unfamiliar with in an attempt to figure them out before there is a lot of other pieces fit in. So far I've just scratched the surface with some Parallax Background work. Basically a parallax background is set up so you have a main background that slowly scrolls, and then another background layer composed of background objects like clouds, that move at a slightly faster rate, giving a "realistic" appearance to the background. Since the player in this new game will be flying at what is presumably a great height, the ground should appear to be moving underneath them at a slower rate than the closer objects, like the clouds, and then both backgrounds continuously scroll on repeat. AndEngine has a nice Parallax Background class, but for some reason the official stuff only supports horizontal scrolling (not good for a vertical scrolling shooter). Luckily, a quick search of the AndEngine forums turned up some modified code some community members had worked on that fix the issue.
So, I started out by just having a light blue background with a big black X on it so I could tell if it was moving. For the foreground I put some oddly colored triangles pointing out. I don't know why I went with that decision, but it worked out all right. This is what it looks like:
Then, partially to test out my encapsulated background code but more to have a better example of the reasoning behind the parallax background, I made a second set of background that are clouds over a grassy area with a lake, some streams, and what I guess is a road leading up to the lake, again in MS Paint. It turned out surprisingly good for the time I put in:
This second background really illustrates what I'm going for here. The clouds scroll downward at a little over twice the speed of the "ground" under them. I'm really happy with how it turned out and I'm excited with the possibilities for additional "levels". Canyons, cities, some sort of volcano. All good options. I just need to keep myself motivated with this new game. The amount of stuff I have to work on to bring it to where I want it to be is a little daunting to be doing solo, especially given the fact that my most complicated game took a year to finish and probably wont see release for quite some time. We'll see how it all goes.
Subscribe to:
Posts (Atom)