Showing posts with label Opensource. Show all posts
Showing posts with label Opensource. Show all posts

Sunday, 26 May 2013

Street Race Swipe LibGDX Scene2D Tutorial



I have been meaning to write a LibGDX Scene2D tutorial for some time now (ever since my Quack Attack FREE Duck Hunt Game got ridiculously popular). The problem has been finding the time, instead of writing blog entries I've been making games!

I had a great idea for a multitasking game, play four independent games at one time to train your brain and test your ability to multitask. The result was my 4 Games 1 Screen FREE Brain Training Game. I built this game as four separate games from the outset, with the intention of possibly building further on each minigame and releasing as standalone apps. The first of these standalone apps is Street Race Swipe Racing Game, which brings us neatly to the point of this article...


Street Race Swipe Racing Game is such a simple game at its heart that it seems like an excellent candidate for a tutorial article :) I remember being massively impressed by the example SimpleApp on the LibGDX wiki when first starting out, there was so little to it but it touched on all the basics of what is needed to make a game. I'm hoping this mini project will be almost as simple and just as helpful to others!

Saturday, 10 November 2012

Enabling the "Move to SD card" option on your android apps


Here's a quick and easy tip that your android app users will love, especially those with older/cheaper devices that don't have a huge amount of internal memory!

Take your existing android application, and add android:installLocation="auto" to the manifest tag in AndroidManifest.xml.

Example:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
   package="com.mrdt.zombiesurvivalgame"
   android:versionCode="2"
   android:versionName="1.0.1"
   android:installLocation="auto">


  • Setting installLocation to "auto" means the user can choose where to install the application.
  • Setting installLocation to "internalOnly" means the app will install on internal memory only (not ideal in most cases, especially if your app is quite big).
  • Setting installLocation to "preferExternal" means the app will automatically try to install itself of the SD card if it is present and is not full.


You'll also need to ensure that your build target (targetSdkVersion in uses-sdk tag in AndroidManifest.xml) is set to API Level 8 or greater.

Example:
<uses-sdk android:minSdkVersion="5" android:targetSdkVersion="15" />

Save your updated AndroidManifest.xml file, rebuild your app, and deploy to a device or virtual device running Android 2.2 or above. Now if you open Settings > Applications, and select your app, you should be offered the option to "Move to SD card" :)

I've just updated my android games to offer users this option, and it'll be something I'll be doing as standard in all my future apps. If you're an app developer you should consider doing the same... As a user I appreciate being given the option to choose where to install my apps - and I'm sure others do too!


Sunday, 12 August 2012

Racing Game - Powering on ahead!

I've neglected the blog for a few days, spent my time working on the app rather than writing about it. As a result, quite a lot of progress has been made in the past few days :)

Here's a video of the app as it currently stands:



Tuesday, 7 August 2012

Racing Game - Too early to go alpha?

I've still not taken care of my housekeeping tasks, but I do have a fully functional HUD now - this makes me feel a little guilty but a lot happy :)


Monday, 6 August 2012

Racing Game - HUD and Timer



As expected, I left the housekeeping for a while and carried on with the fun stuff :) There's a couple of things worth a little mention today:
  1. How to render a heads up display
  2. Introduction of a new timer class

Friday, 3 August 2012

Racing Game – Bobo’s end


In my last post I mentioned that having play tested a little I wasn’t really satisfied with how the game played. The levels were too blocky, character movement felt like it was in the wrong direction, and the story/theme was a bit forced and rubbish.
The simplest way to reduce the blockiness of the level would be to simply shink the tile sizes. Creating loads of block objects seemed a bad idea though (taking it to the extreme there could be one per pixel!). Instead I went back to the drawing board to rethink the level concept. Here’s a simple definition of a level:
  • A level row is 10px high and 240px wide
  • The viewable portion of the level is 320px high (32 x rows)
  • An example row could be: 80px wide grass, 80px wide road, 80px wide grass
  • The road sections are the same width in all the levels rows
  • The left grass section can increase/decrease in width by up to 4px per consecutive row
  • The right grass section takes up the remainder of the levelRow width
With these rules defined, I went on to rewrite the level generation code:
 public Level(int screenWidth, int roadWidth, int roadOffset, int levelLength, int rowHeight) {  
  this.screenWidth = screenWidth;  
  this.roadWidth = roadWidth;  
  this.roadOffset = roadOffset;  
  this.levelLength = levelLength;  
  this.rowHeight = rowHeight;  
  this.levelRowRoadOffset = new int[levelLength];  
  offroadAreas = new Array();  
  generateOffsets();  
  generateOffroadAreas();  
  generateFinishLine();  
  car = new Car(new Vector2((screenWidth/2)-(Car.WIDTH/2), 20));  
 }  
 private void generateOffsets() {  
  for (int row=0; row<levelLength; row++) { // for each row in the level  
  levelRowRoadOffset[row] = roadOffset;  
  // generate a random integer (between -4 and +4)  
  int modifier = (randomGenerator.nextInt(9)) - 4;  
  System.out.println("Modifier: "+modifier);  
  // apply modifier offset provided road would remain in bounds  
  if ((roadOffset + modifier >= 1) && (roadOffset + modifier + roadWidth <= screenWidth)) {  
   roadOffset += modifier;  
  }  
  }  
 }  
 private void generateOffroadAreas() {  
  for (int row=0; row<levelLength; row++) { // for each row in the level  
  OffroadArea leftGrass = new OffroadArea(0, row * rowHeight, levelRowRoadOffset[row], rowHeight);  
  offroadAreas.add(leftGrass);  
  OffroadArea rightGrass = new OffroadArea(levelRowRoadOffset[row] + roadWidth, row * rowHeight, screenWidth - (levelRowRoadOffset[row] + roadWidth), rowHeight);  
  offroadAreas.add(rightGrass);  
  }  
 }  
 private void generateFinishLine() {  
  finishLine = new FinishLine(0, levelLength * rowHeight, screenWidth, 40);  
 }  

Bobo became Car, Block became OffroadArea, and there were a few little changes to these classes, nothing really worth mentioning here. The drawing routine in GameScreen changed a little:
 for(OffroadArea offroadArea: level.getOffroadAreas()) {  
  spriteBatch.draw(grassTextureRegion, offroadArea.getBounds().x, offroadArea.getBounds().y, offroadArea.getBounds().width, offroadArea.getBounds().height);  
 }  

If you’d like to see the full extent of the changes made, the complete source can be found here.


What next?

Lots to do…
  • I can think of a couple of of efficiency improvements to do – there’s no sense in checking the whole level for collisions, and the same goes for rendering rows that are offscreen (espcecially those you have passed and won’t possibly see again).
  • I think maybe there should be subclasses of OffroadArea, ice, grass, rocks, finish line, etc, all with different behaviour, but for now I’ll leave things as they are, “it aint broke, why fix it”.
  • The level may need a little tweaking, certainly in later levels the game would need to get tougher. Deceleration when offroad needs tweaking too, it’s too sudden at the moment.
  • There’s a cheat possible where if you leave the screen bounds you race ahead, I’ll need to constrain car to world bounds.
  • The timer needs to be reintroduced, current time should be displayed oncreen, and high scores should be saved to persistent memory.
  • A delay before starting the race would be nice, maybe a traffic light graphic or “3, 2, 1, Go!” message.
  • The finish line could be improved, maybe a nice animation of the car driving offscreen?
  • Sound effects would be nice.
  • Maybe the car should rotate a little when ‘steering’?
  • Maybe some dirt particles should get kicked up when the car is offroad?
  • I’m already thinking about the third dimension. I need to forget about this for now if I ever want to produce a finished game. Maybe this game should be RaceGame2D, and RaceGame3D could be another project for another time!
There’s no doubt loads more to do that I’ve not thought of yet. I think I have plenty to be getting on with though! Don’t really know what I’ll tackle next, so the next update will be a lucky dip! Until then, here’s a bonus video of the basic game as it currently stands :)
          

Thursday, 2 August 2012

Run Bobo Run – Basic game mechanic complete



This update was good fun to write, feels like quite a lot was achieved in not a lot of code :) I've now implemented collision detection, tilt control, a level timer, and world forces (gravity and terminal velocity).

Collision Detection


I added a bounding box to both the Bobo and Block classes. Bobo's bounds are updated whenever he is updated, this is not necessary in the case of static Block objects. The main game loop calls checkCollisions() each cycle, this is an inefficient but perfectly functional collision checking method:

private void checkCollisions() {
   int numBlocks = level.getBlocks().size;
   for (int i = 0; i < numBlocks; i++) {
      Block block = level.getBlocks().get(i);
      if (block.getBounds().overlaps(level.getBobo().getBounds())) {
         level.getBobo().hitBlock();
      }
   }
}

If any Block bounding boxes overlap Bobo's bounding box, call bobo's hitBlock() method, which slows him right down:

public void hitBlock() {
   velocity.set(0, -20);
}

The efficiency of the collision checking routine could be massively improved by only checking for collisions with nearby blocks that Bobo could possibly collide with (as opposed to every single block in the level), but I'm lazy and this will do the job for now...

Tilt Control


I made some changes to the handleInput method:

private void handleInput(float deltaTime) {
   if (Gdx.app.getType() == Application.ApplicationType.Android) {
      level.getBobo().moveBobo(deltaTime, Gdx.input.getAccelerometerX() * -50);
   }
   if (Gdx.app.getType() == Application.ApplicationType.Desktop) {
      float moveBobo = 0;
      if(Gdx.input.isKeyPressed(Input.Keys.LEFT)) moveBobo = -100f;
      if(Gdx.input.isKeyPressed(Input.Keys.RIGHT)) moveBobo = 100f;
      level.getBobo().moveBobo(deltaTime, moveBobo);
   }
}

The if statements allow for platform specific controls - on Android use the accelerometer, on the desktop use the cursor keys. The user input results in a call to Bobo's moveBobo() method:

public void moveBobo (float deltaTime, float moveBobo) {
   velocity.x = moveBobo;
   update(deltaTime);
}

Basically, alter Bobo's velocity in accordance with the passed in parameters, then call bobo's update method:

public void update(float deltaTime) {
   if (-velocity.y < TERMINAL_VELOCITY) {
      velocity.add(Level.gravity.x * deltaTime, Level.gravity.y * deltaTime);
   }
   position.add(velocity.x * deltaTime, velocity.y * deltaTime);
   bounds.set(position.x, position.y, WIDTH, HEIGHT);
}

If Bobo has not yet reached his terminal velocity on the y-axis, apply acceleration/gravity (a property of Level - "gravity = new Vector2(0, -30);") to his velocity, then update his position in respect of his velocity (and the time since last update), and update his bounding box to match his new position.

Level Timer


Finally, there's a timer to keep track of how long it takes to get to the end of the level. Currently it just outputs a message to the console, but that's enough to prove it works.

When the level is created, the current time is recorded (startTime = TimeUtils.nanoTime();).
checkGameover() is called on each cycle of the main game loop:
private void checkGameover() {
   if (level.getBobo().getPosition().y <= level.getLevelEnd())
      System.out.println("Finished level in "+(TimeUtils.nanoTime()-level.getStartTime())/1000000000+" seconds!");
}

And here's the Level getLevelEnd() method:
public int getLevelEnd() {
   return -((levelHeight * Block.HEIGHT)-Bobo.HEIGHT);
}


That's it, nothing more to it :)

What Next?


At this point, the basic game mechanic is complete. I could (should??) go on to implement the other screens, the in game heads up display, the high score recording... But, err, I'm not happy with the game. The setting/story is a bit too convoluted, the uniform blocky walls are a bit rubbish, and the tilt controls feel a bit weird when controlling a character that's facing you and running down the screen.
I'm going to revisit the level generation code to get things looking a little less blocky, change the direction of play to up not down, and maybe change the setting from a running clown to something a bit more "normal", a racing car on a road, a speed boat on a river, or the old classic - a helicopter in a cavern.
You can checkout the game in its current state here if you like. It should look quite different come my next update!