Week 6

Sot his week we worked pretty hard on damages, reading levels from an XML file, and getting the assets working properly in the renderer.

For damages we found out we could utilize an OnContactListener class to find when the ball has contacted the objects and we take the mass of the object multiply it by the velocity the ball projected it at and we get the kinetic energy transferred, at least that's the rough idea behind the physics of destruction. It also won't be hard to implement a texture swap as the object takes more and more damage and that should be ready to go for the alpha.

Reading XML files was interesting, I believe I did it a long time ago in C# but I couldn't remember ANYTHING about it. It took a while but I found a simple way of reading and parsing it and that's all I really needed. I also implemented a singleton that holds all the level information from the XML file so that it can be read by the physics handler (and then passed off to the renderer) but also the gameLoop will be able to get the number of balls left and adjust them and it'll be easier that way to tell when a level is done, and since there's only one level at a time a singleton is pretty sweet, I just made sure to include a load function that loads a new xml file into the level singleton.

Getting the assets to work properly was a HUGE pain since the axis are different in MAX than in OpenGL and so it was a lot of guess and check. Also I found out that the origin for Box2D is the center of the object. If the model wasn't put exactly there it would be rotating around a different point causing problems. In the end everything is working out to be pretty cool. Here is an example I made using the assets and the xml file:

Looking towards the future, we really need to buckle down and get gameplay taken care of. With damage out of the way, that's one significant part down, but we also need to be able to launch balls at the structures and have win/loss conditions. I think we're working at a pretty good pace though. I believe we should end up with a very polished game at the end of the 16 weeks.

Week 5 Update 2

Happy thanksgiving to all! I just wanted to do another update and show more of the rendering in action. I added a ball to the mix to show the collision and I took out the long bricks for now cause I don't have a model to represent them, and you had to use your imagination with the bricks. Without further ado:

(I also put a little perspective on things)

Week 5 Update 1

This week I am working extremely hard on the graphics and rendering and I really wanted to show off what I've done. I took the data from Box2D and rendered each block. Currently we used 2 different boxes in Box2D, the square ones and the long ones, well I haven't differentiated between them yet and that's why there's the placeholder there. The boxes do their initial adjustment and then stay so once I get a scenario in which our ball knocks the blocks over we should see some real action. For now here's my achievement:

Week 4 Blog - Physics and Graphics

So this week we really focused on physics and graphics. We made some progress in that we now know how to apply forces to our projectile and we have started implementing a damage system that should be done in the next week or two. Other than that I was able to retrieve physics information in the rendering class so rendering the individual pieces shouldn't be too hard. As well, since box2d works in metric, I figured I'd also model in metric to keep everything in sync. I also found out that 39 OpenGL units = 1 meter, which will come in hand when converting from box2d's coordinates to ours.

More importantly than all I believe is that the backbone for the game has started to develop. I planned it out last week and this week started implementation, and it's been rocky with a few added problems than I expected, but if I've learned anything from software development that is to expect the unexpected. It's so hard to do something completely perfectly the first time and there most likely will be bugs and/or errors.

This upcoming week I'm definitely buckling down and turning up the heat as the graphics of this really need to be done ASAP, and it'll be good when done. I am worried about framerate though... we played a simple 3D space invaders game made with libgdx (not even incorporating box2d) on Jordan's phone and the framerate was a little low. I don't know if it's just his phone or if that's a common thing. We'll just have to see.

Week 3

It's nice seeing things come together this week. I have now a better idea on the overall backbone of the game. I took some time and I made a UML diagram of the overall game and how it would switch screens and such. As well we got box2D working in our environment and that really shows us the power of the collision engine, and once we get it working in 3D it will be absolutely amazing looking. The one thing that's in the back of my mind that I'm thinking can be a problem is scaling. Box2D uses metric, which can also be used in 3DS MAX, but how will that translate to openGL? Exactly how big is 1 meter in OpenGL units? I guess what I can do is make a meter long model in 3DS MAX and start an object at the same spot as that MAX model, then move it length wise till it's displaced 1 meter. Then we'll have a conversion from OpenGL units to metric and vise versa. I do really wish they would've done the units for Box2D in American Units but then again it wouldn't make much sense.

I also had a new thought on launching the wrecking balls... I was thinking about having 2 cranes with a band between them so that we can do a launcher more like Angry Birds. It would be much more intuitive and easier on gameplay rather that the way it was originally set up.

I'm excited about things to come, what we are lacking right now is an Artist, which would be awesome to find one.

End of Week 2 Blog

So ballistics has a concept design document and there have been some other progressions as well. We we're kind of worried about building a physics engine (albeit 2D physics rendered in 3D) as it can be pretty tricky, but we think that a physics engine that actually comes with libGDX and that is box2d. We can run a simulation with box2d then funnel the results back to the rendering engine. We'll also have to add damage as destroying things is going to be a key part of gameplay but that can be retrieved from acceleration upon collision. Anyways, I'm glad that we made this discovery before getting too far into development. As well as being a great asset to our project, this has the ability to be a game changer for future games/projects. That's about it for now, I'm looking forward to jumping into the coding. Where to start though...

BALListics and Alpha Conflict

So it's been a while since I've blogged but that's mainly cause I didn't feel like any of my workings had any big revelations that I really cared to share, but I do have two projects currently in the queue and they are taking up a lot of my time and I'm going to be updating a lot more about them here.

The game I've had in development for a while is called Alpha Conflict, and is based off my midterm project which is a top down shooter similar to something like R-Type. I have already a bunch done with the game but here's a link to it's facebook page where I have lots of my assets and updates: http://www.facebook.com/AlphaConflict

The more important thing though is that I am starting Senior Project and my group decided to take on a much more ambitious Android project by expanding into 3D. I have been playing around with what we've been using (libgdx) and I enjoy it's complexity and simplicity if that makes sense. The game is ambitious and I'm hoping to partner with an art student to dish out that work so us programmers can focus wholly on the actual game as it's going to be a long haul with the graphics and physics. We haven't started programming though, and our paperwork has just started. The sooner we get this started though the better off we'll be.

Some problems or difficult areas I can see coming up are going to be the physics handling and level designer. I want the flexibility of being able to place building materials on different angles so it's not just straight up and down. That's boring and wouldn't make for a good game, but it also eliminates a text or spreadsheet designer that I thought would be a good idea. Maybe I'll create a more visual level designer that will drag and drop objects and when exported will be list of positions, object ids, and rotations so that the engine can populate it from that output. Physics I'm hoping will be controlled by a Singleton design pattern. We can have a method that loads the meshes into a list (basically an array with functions) and then handled from there. The only thing I can see being a problem is getting the calculations beck to the screen. That might not be a huge problem, actually I might even be able to adjust the render FROM the physics handler class, but that's probably not the right solution. A better solution might be to just return positions of indexes and a method that can get the size of the list and foreach through the list from the render class. As it's a singleton, it is also static and always alive so it'll need to be cleared between levels. I have work cut out for me...

Custom Object Pool for Java

Just a foreword, this is made specifically for AndEngine but can be adapted to anything that uses lists.

Creating and destroying objects is costly on a CPU and on a platform like Android, CPU usage needs to be wise. With the method I'll lay out, we employ the use and power of Lists, where a projectile is either recycled or a new one is created.

Step 1: Initialize the list

private List enemyMissileSprites = new ArrayList();

MissileSprite is a class I made that extends the Sprite class in AndEngine. Not much is different from its parent other than it has a reset function that removes it from the screen (sets its position to (500,500) just to get it off the screen), and an update method that moves it 10 units to the left every tick.

Lists are cool, they are like arrays but they are more easily expanded. To add an element to a list one just needs to do listName.add(objectName). It's that easy. Accessing the parts of the list are different than arrays where in lists you use listName.get(indexNumber) rather than arrayName[indexNumber]. With that let's continue.

Step 2: Make the function to retrieve missiles/objects

private int getEnemyMissile()
{
   for(int x = 0; x < enemyMissileSprites.size(); x++)
   {
      if(enemyMissileSprites.get(x).offScreen(CAMERA_WIDTH, CAMERA_HEIGHT))
      {
         //Log.d("GeoFlight", "Reusing #: " + x);
         return x;
      }
   }
         
   Log.d("GeoFlight", "Expanded Enemy Missile Sprites to size: " + enemyMissileSprites.size());
         
   this.enemyMissileSprites.add(new MissileSprite(TextureRegionFactory.createFromAsset(misTexture, this, "gfx/480/missile.png", 0, 0)));
   scene.getLastChild().attachChild(this.enemyMissileSprites.get(this.enemyMissileSprites.size() - 1));
         
   Log.d("GeoFlight", "Expanded Enemy Missile Sprites to size: " + enemyMissileSprites.size());
         
   return this.enemyMissileSprites.size() - 1;
}

Here we check to see if the object has moved off the screen and if it has then it will return the number of it's location back through the function. If there are no projectiles offscreen, then it will make a new object and return its place. We can know its place as the add function of lists adds it to the end of the list, thus whatever object you add will have the index of listName.size - 1. That is really it, but here's implementation use too.

BaseShip temp = encounter1.checkForMissileFiring();
if(temp != null)
{
   enemyMissileSprites.get(getEnemyMissile()).setPosition(temp.getX() + temp.getWidth() / 2, temp.getY() + temp.getHeight() / 2);
}
if(enemyMissileSprites.size() != 0)
{
   for(MissileSprite mS : enemyMissileSprites)
   {
      if(!mS.offScreen(CAMERA_WIDTH, CAMERA_HEIGHT))
      {
         mS.update();
      }
   }
} 

Basically I have my encounter check for firing missiles, if there is one then it passes the ships information back to my game class or else it will return null. It then proceeds to get the enemy missile from our getEnemyMissile function and sets its position to be equal to that of the ship it returned. As well, I added to it where it will only update the missiles that are on screen.

I hope this helps people, if you like it please comment and follow, and if you have any critique, please let me know, I'm still learning and growing and looking to sharpen my trade daily.

Creating a Smooth Moving Character with a Maximum Speed

Everyone knows that in a game, we can have a character set their position to our finger position, but what if we don't want that character to be able to "teleport" if the player picks up their finger and moves it to another end of the screen. That's what I will be showing using AndEngine (as that's what my current project is using) but the concept can be extended to any other platform, language, etc.

 //** moveTo function - takes a destination in, and moves the ship sprite towards the destination **//
 @Override
 public void moveTo(Vector2 dest)
 {
  //This makes it so that when a finger is still, the ship doesn't "vibrate"
  //Currently I am only moving along the y axis, so for 2D movement you'd have to impliment "& dest.x >= this.getX() + 5 || dest.x <= this.getX() - 5" after 
  if(dest.y >= this.getY()  + 5 || dest.y  <= this.getY() - 5)
  {
   //Finds the difference between the current position
   Vector2 distance = new Vector2(dest.x - current.x, dest.y - current.y);
   //Normalizes the vector
   Vector2 direction = distance.nor();
   //Multiplies the normalize vector by the max speed to set the speed
   currentSpeed = direction.mul(maxSpeed);
  }
  else
  {
   //else we make sure the ship isn't moving
   stop();
  }
  
 }
 
 @Override
 public int update()
 {
  //moves the ship, pretty standard stuff
  this.current.x += currentSpeed.x;
  this.current.y += currentSpeed.y;
  
  //sets the position of the sprite
  this.setPosition(this.current.x, this.current.y);
  
  //this is for my sprite work as I'm dealing with a tiled sprite, so it looks like it tilts when it moves
  if(currentSpeed.y >= 1)
   return 3;
  else if(currentSpeed.y < -1)
   return 2;
  else
   return 1;
 }
 
 public void stop()
 {
  //sets the speed to 0
  this.currentSpeed.x = 0;
  this.currentSpeed.y = 0;
 }

In implementing you do need a little more code:

                // Deal with touch events
                scene.setOnSceneTouchListener(new IOnSceneTouchListener() {
                    @Override
                    public boolean onSceneTouchEvent(final Scene pScene, final TouchEvent pSceneTouchEvent) {
                            if (pSceneTouchEvent.getAction() != TouchEvent.ACTION_UP) {
                             playerShip.moveTo(new Vector2(playerShip.getX(), Math.round(pSceneTouchEvent.getY())));   
                             return true;
                            }
                            else
                            {
                             playerShip.stop();
                             return false;
                            }
                    }});

You need to make sure that the character stops when the player releases their finger (as well you need to update the ship using the update method in an update handler. Hope this helps! If you have any questions feel free to leave a comment.

What this blog is all about

I've been developing for Android for a couple months now and I feel like I have an insight into it that is valuable to share, as well it's good to document my ideas so that I can come back and refresh myself with my "aha" moments. I'm a good teacher and enjoy making complex things simple so that just about anyone can pick something up and work with it.

Android is the greatest growing mobile platform and the sky is the limit when it comes to just about anything in it. Unfortunately it seems like you have to be a rocket scientist to full understand some of these tutorials and walkthroughs, hence why I'd like to take a step back and make sure people understand the ideas from the ground up.

I am in NO sense a master at this, but like I said, I bring simplicity to complexity, and sense to what seems insensible. I will mainly focus on game programming as I am a Game and Simulation Programming student at DeVry University, but more specifically I will be going over Games and Applications using the Android Canvas, AndEngine engine, and OpenGL.

This is my mission statement and my plan. If you have any questions feel free to email or comment, and I'll see what I can do.

SMASH out.