Greedy Caterpillar - a snake game for touchscreen and TV

Little by little, TheInvaderOne is growing up. She is now three and a half years old 😮

Her little sister, TheInvaderOneX 👶, is eight months old, and is now very interested in the Sensory app. She's also interested in whatever her sister happens to be up to at the time, crawling at light speed, making valiant attempts at walking, and trying her damnedest to "eat all the things".

Big sister has smashed it on the numeracy front, and has left the Count 1 to 10 app for dust. We're in the big leagues now - she has 1 to 100 cracked, addition and subtraction of small numbers sorted, and is starting to get to grips with simple multiplication and division. Of course, we're not drilling numbers, letters, languages, etc 24/7. She loves absorbing knowledge - she's like a sponge, but we don't want her to burn out before she even hits school - being bored at school from day one due to them not teaching her anything new would likely be a disaster! No, there needs to be plenty of downtime... Sure there's loads of toys to play with, and imaginative play, and creative crafts, and baking, and stories, and a bit of tv (if you have kids around this age and want to combine cartoon time with learning, check out Go Jetters and Numberblocks, both big hits in our home at the moment), and seemingly endless unrelenting viewings of Frozen, but she's also seen what Daddy does to unwind - play and make games, and she wants in!

Ok, so making games may be a way off yet, but playing them was definitely on the cards. My other half bought me a Raspberry Pi 3 starter kit as a birthday surprise, it's now a dedicated emulation machine, with a lovingly curated list of games on there. It's pretty much a NES Mini, and a SNES Mini and a "Many Other Platforms Mini", all rolled into one. My eldest has particularly enjoyed playing Centipede and Barney's Hide & Seek. She loves the arcade action aspect of Centipede, but the move from touchscreen puzzle games to a joypad controlled action game was a pretty big step, and before she truly "got it", it was game over. Over and over again. The Barney game is actually a fantastic game for first getting to grips with the concept of pressing buttons or moving a joystick to control an onscreen character (since you can't really lose), but it seems the controller we were using (a truly excellent bluetooth one by Moga) was a bit overwhelming, and the game itself requires no real skill or engagement (drop the controller and it will complete itself on autoplay - once you realise that, what's the point in playing anymore?).

I got to thinking about what would make a good game for three year old, one who so far has only been exposed to touchscreen "jigsaw puzzles" and "smash bugs at a picnic" type games.

Here's what I came up with:

• The control scheme should be simple and intuitive
• Rules governing gameplay should be fairly straightforward and logical
• Threat should be absent, or extremely mild
• It should look and sound reasonably appealing
• You shouldn't be able to lose too quickly i.e. before you get a handle on what you're actually meant to do

I realised that we already owned the perfect game controller for a small child. It's not really a game controller at all. It's an Amazon Fire TV Remote. I mean, just look at this thing:

It's a wonderfully simple controller, and that circle up top covers all the basic actions that should be required in a simple child friendly game: up, down, left, right, and a single fire/action/select button.

I started out with an Atari 2600 myself, nearly 30 years ago. All the games I had were controlled by one of these bad boys:

Let's all take a moment to bask in the glory of its simplicity... Up, down, left, right, and a fire/action/select button. Yes, using the Fire TV Remote looked like a winner. If it was good enough for Atari in the 80's, it's good enough for me today.

Ok, control scheme and physical controller sorted, on to the next item, a relatively simple game idea. A lot of the best simple game ideas have already been done, but I'm cool with rehashing a tried and tested mechanic, not everything has to be innovative or ground breaking ☺ Thinking about simple games, I realised very few are actually forgiving enough to meet my requirements. Pong and breakout are actually quite tough games, especially if you've never played them or handled a game controller before. Miss the ball a few times and it's game over. A game of breakout could easily be over within seconds, and before any blocks were broken. No good, frustration is not fun. What about Pac Man? Space Invaders? Centipede? Same deal. Those old simple games were actually quite challenging, I guess that's what made them so addictive, and why world records exist for acing them! Then it struck me: Snake!

• Simple control scheme: up/down/left/right, press the relevant button to move in that direction
• Simple rules: eat as many apples as possible and don't bite yourself - seems like reasonable advice for anyone to lead their life by
• Minimal threat: bite yourself and you have to start again (no big deal, right?)
• Aesthetically appealing: Ok, nokia snake wasn't the nicest looking or sounding game, back in those days we didn't have much to work with, the 3310 had a 84x48 monochrome 1.5 inch screen, midi sounds, and a processor and memory to match. Luckily we have HDTVs and even HD mobile devices these days, so we can do something about that... And thanks to awesome people like Kenney and Kevin MacLeod you don't have to be an accomplished artist or composer to pull it off!
• Impossible to lose too quickly: This is where snake comes into it's own - all the other simple old games I considered were challenging, and you could lose them all immediately. The snake game is challenging, but with certain rules in place (no static obstacles, wrap around scenes, starting length of 4 segments or less) it is actually impossible to lose until you have at least managed a score of 1, and in most cases you're unlikely to lose before the "snake" reaches a length greater than the world height.

I put together a small prototype, and soon had a very simple snake game up and running on our living room TV via the Fire TV Stick. A "snake" comprised of green squares on a black background, a single red square representing the "mouse" or "apple", no score, no sound, nothing other than a very rudimentary snake that could be controlled via the Fire TV Remote that grew each time it "ate" a red square. My daughter loved it. I think she was excited to see that what I had been working on on my laptop had somehow appeared on the TV, and that she could press buttons to make it do stuff ☺

She referred to the snake as a caterpillar, probably due to us having played Atari's centipede on the RPi earlier in the day, and she called that a caterpillar too (I guess she has never actually seen a centipede, but has seen plenty of caterpillars). Maybe the fact we had recently borrowed The Very Hungry Caterpillar from the library had something to do with it too. Anyway, the Hungry Caterpillar name stuck, and that in turn helped me come up with a nice, bold, simple, child friendly, cartoonish skin:

I could have stopped right there, as at that point I had achieved what I set out to do - I had made a little game for my three year old to play on the TV using a simple controller. However, I found the whole process of developing for a TV and remote controller quite interesting. If the game had more than a single screen, maybe a game over screen announcing when a high score had been achieved, a menu screen, a help screen, an options screen, how would all that work using the remote as a controller? More interestingly, could I get the app to work well not only on TV's using a remote/game controller, but also on the more traditional touchscreen phones and tablets? If yes, why not release it on Amazon for both Fire TV and Fire Tablet devices? Could I go one step further and release it on Google Play too? I found the answer to all that stuff and managed to build a single apk that works equally well on TV and touchscreen, and that can be uploaded to both the Amazon and Google marketplaces.

I learned a few nifty tricks that I plan to write about in future (this post is already way too long...):

• How to suppress ads when running on an unsuitable platform (it infuriates me when ads appear in a Fire TV app with no way to avoid them or click through)
• How to link to the appropriate app store depending on what platform you are running on without resorting to separate builds for each marketplace
• How to handle a simple menu in LibGdx using either touchscreen or remote/game controllers
• How to make a game/app that works well and looks good in terms of the 10-foot user interface, and that works equally well and looks equally nice on hand held devices

I also ended up with a game to play with my daughter, something to publish on the Amazon and Google marketplaces (yeah, I've been slacking again), and a reason to post on my blog again :)

Oh, and the game is totally helping TheInvaderOne get to grips with controlling an onscreen character by pressing buttons on a remote controller. She is already hitting double digit scores, which is a huge improvement over what she could manage when she first tried a couple of weeks ago. I expect she will be destroying my own high scores very soon! And if her interest in the Sensory app is anything to go by, TheInvaderOneX will be bringing more competition to the table in two or three years time! ☺

Anyway, the game is free, as always. There are some ads when you play on a mobile device (a small unobtrusive banner, and a single short interstitial plays on game over). There are no ads on Fire TV. No in app purchases or subscriptions or any kind of hidden nasties on any platforms. Just a simple fun game for you to play for free ☺

Don't be afraid to be overly generous with your ratings and reviews, I'm cool with praise, don't worry, you won't make me blush 😙

Until next time, I hope you have fun 😀

LibGDX Google Play Game Services Tutorial

Google Play Game Services offers cross platform social leaderboards, achievements, and much more (realtime multiplayer, cloud saves, anti-piracy...). I've started implementing google play game services leaderboards and achievements in my LibGDX Android Games, and the purpose of this blog article is to walk through the process so you can do the same!

• I've published an example project on Google Play check it out!
• The example project is freely available on GitHub check that out too!
• You can also get the complete (free) version of Super Jump a Doodle here!

Continue reading after the jump to find out how to add these features to your own games!

One million installs!

1,066,345+ users have installed my LibGDX Android games :)

Due to reporting lag that number is a few days out of date, and it doesn't include installs from third party scraper style stores, so the real number will be a little higher, but I can safely say I have over a million installs in total. Awesome :)

So, how do the various markets stack up?

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!

4 Games 1 Screen - Musings on mobile game control

So often I hear that players hate onscreen controls on touch devices. No physical button means no tactile feedback to let you know you are 'touching but not pressing' a button. This fundamentally different interface means the traditional joystick / d-pad control scheme can no longer be the de facto standard for gaming controls across all platforms - replicating "up down left right a b start" on a phone or tablet is far from ideal (but an ouya or gamestick is another matter entirely ;)).

In my latest game, 4 Games 1 Screen, I try to make the most of a tricky situation. I've embraced the android mobile platform and the control options it offers. Our phones and tablets have accelerometers and touchscreens, the old nintendo and sega machines did not, it's time to think outside the box and make the most of these features.

4 Games 1 Screen is a challenging brain training game, the aim is to multitask by playing four games at one time, and avoid making too many mistakes. Make too many mistakes and it's game over. Each game is kept relatively simple for two reasons - first the game has to have a single objective and control method, second you have to be able to play four of these things at once so too much complexity would be too distracting for the player.

The mini games are:

• Asteroid Attack - Tilt to steer your ship, asteroid collisions damage the shields, and when the shields are gone - gameover man, gameover!
• Tap Jump Cowboy - Classic infinite scroll platform game (like canabalt, and gemserk's excellent vampire runner) tap the screen to jump, save the cowboy from running into the campfires!
• Speedy Sums Math Master - Fully engage the left side of the brain, evaluate the math problem and mark it as correct or incorrect... You not only lose a life when you get it wrong, but also when you run out of time - so think fast!
• Street Race Swipe - Swipe up or down to change lanes in this fast and furious racing game, avoid crashing into the other sports cars, too many bumps and your car will explode!

Each game can be played independently (full screen) in practice mode, but the real aim of the game is to play them all at once - the game is called "4 Games 1 Screen" afterall :) I find it fun, addictive, frustrating and challenging. The frustration is what makes it so addictive haha, I see gameover and immediately try again to "do it right this time" :)

No onscreen controls, and a game that would not really be possible on traditional gaming platforms, this is truly a mobile game designed for mobile devices. I hope you go on to check it out (it's FREE, so why not!) and if you also like making your own mobile games that you might consider some of the thought behind the concept - don't lament the lack of physical controls, instead make the most of what is available!



Finally, does this mean that I won't ever release a mobile game with onscreen controls? No. Definitely not. A future project will be a traditional platformer, with android enabled consoles like the ouya and gamestick firmly in mind. I will no doubt make a mobile version of this game with onscreen controls (it would be silly not to). I'm not against onscreen controls, I'm against not thinking up interesting ways to make the most of what the mobile platform offers. I believe a platformer will only work well with traditional controls, but we don't always have to make traditional games :)

Happy gaming boys and girls!

Try before you buy (or in this case, try before you download for free!)

How awesome is this!? You can now try playing Quack Attack in your browser :)

The game plays a lot faster and smoother on a real android device (I think the slower your internet connection, the worse the appsurfer gadget performs), but I still thought this cool idea was worth sharing here.

Something tells me I'll be using AppSurfer to help promote my next game, the fact that tilt is simulated is especially cool :)

Scene2D Investigation... Result: Quack Attack Free Duck Hunt Game!

I started looking into LibGDX Scene2D recently. No real reason, other than it looked like it could be something interesting to learn, so why not! :) Best way for me to learn is to just get stuck in, so I got to work on a Duck Hunt tribute, and learned as I went along...

It's clear that Scene2D UI is the way to go for menus and the like, so much cleaner than my past approach. Scene2D UI combined with table-layout makes setting up menus and HUDs a breeze. Even better, tweaking layouts becomes pain free, a real bonus! I'll certainly be using it again in future games.

As for making use of Scene2D in the game itself (over and above the HUD), it was tricky to start with... All the tutorials I've read so far have advocated the MVC approach, and it seems that MVC is not really possible when using Scene2D (the model and view are tightly coupled). Still, I've not been doing this long enough to be stuck in my ways, so I figured I could just ignore some of what I'd learned in my earlier projects and just go with the Scene2D flow.

I was surprised that there aren't more tutorials available on the subject to be honest, but I muddled through with various bits and pieces I could find. The most valuable resource when getting started was the LibGDX suite of tests, they are always a good starting point when looking at something new. The official wiki was helpful too. It's a bit presumptuous to think that I'm in a position to write tutorials on the subject (due to me being a newbie myself), but I think I'll post a few code snippets in the coming weeks to share some getting started tips, maybe even an open source step-by-step mini game "how to" if I have the time.

I like how Scene2D lets you encapsulate Actor behaviour in its own act() method, it's pretty cool just instantiating an Actor and then just leaving it to its own devices. My first Scene2D game (Quack Attack) has the game logic class spawn a Duck object at various intervals, the Duck class itself keeps track of how it should behave (overridden act() method sets various actions for the duck to perform dependent on its current state), and it also takes care of drawing itself via the overridden draw() method. It's really nice to be able to look at that single Duck class and immediately "get" exactly what a duck will do in the game, without having to look at various other classes. I guess this is one of the main Scene2D strengths, but on the flipside it's what makes MVC impossible...

I'm sure the coupled view and controller will make things difficult on larger more complex games, but for simpler games I don't think it's a big problem. I guess if I were ever to try porting a Scene2D heavy game to a different platform it'd be a problem too, I am pretty sure porting Racing Game or Evil Monkey Touch Defense or Zombie Game to XNA would be pretty straightforward (if we ignore the tilt/touch control issue), but porting Quack Attack to a library without a similar scene graph implementation would not be so straightforward (would probably have to port the whole of Scene2D too!). Again I don't really care about that right now as I'm focusing on Android only, so I think it's quite likely that I'll be using in-game Scene2D in the future.

I've just published my first Scene2D game on Google Play, it's totally free (ad supported), so feel free to install and check it out. If you like it, I always appreciate a nice rating/review :) Check it out here: https://play.google.com/store/apps/details?id=com.theinvader360.duckhunt.quackattackfree

I think it turned out quite well, and am pleased with what was achieved in a relatively short amount of time. Keep an eye out for future blog posts featuring mini Scene2D tutorials if you're interested in that kind of thing :)

Until next time - happy gaming, and happy game developing!

Monkey Magic!

UPDATE - As a result of a request from Fox, this game has been removed from the Google Play market. I may create a new version at some point using all original graphics (i.e. not the Family Guy monkey), but in the meantime why not check out one of my other games?

I released a new free game recently - Evil Monkey Touch Defence. You control a "good" Evil Monkey / King Kong type character, his job is to try and protect the tower from incoming missiles!

This was an experiment in creating the simplest possible control scheme for a casual game, while still making a game that's good fun to play. When you touch the screen the monkey starts dropping his aim, when you release the screen he fires. No buttons, no tilt, no nothing, just touch and release anywhere on the screen to control the game - it couldn't get any simpler! The longer you survive the faster the missiles get, and the more missiles you destroy the higher your score, simple and addictive fun...

You can check out Evil Monkey Touch Defence here. I'd love it if you would leave a nice rating or review if you like the game :)


On the subject of free monkey based casual games for android... A friend of mine recently released his first game, you can check out his Monkey Game here - it's a fun casual physics game that uses Box2D behind the scenes. There's nothing in the least bit evil about this monkey, he just wants to eat his fruit (and not get eaten by a croc!)

Tower Defence - Slacker's Diary

I've been slacking recently. Between work, Christmas preparations, and home improvements, there's not been a whole lot of time left over to work on Android games. Anyway, that's enough of the excuses, question is - what am I going to do about it?

I've made a little progress on Tower Defence, but the plan is to put it on the back burner for now, keep working on it whenever I have a nice block of time to dedicate to it, but if I only have an hour or so available at a time to work on more trivial projects instead. I love the momentum that builds up when working on really small simple games, and I'm hoping to get a few of these little games started and finished in the next few months, and just keep chipping away at TD as a longer term project.

Here's a video of the tower defence game as it stands:

Most of the basics are there really, but getting the game finished involves quite a few tasks, not all of them trivial - adding enemy waves, turret upgrades, multiple enemy types, multiple turret types, lots of level maps, level unlocking, graphical improvements, game balancing, etc. I might put an early unfinished version of the game up on the market at some point, maybe with rough graphics, just a handful of levels, and not the best balancing, but I worry that if I do that I might never finish the game properly!

On a positive note, keep your eyes peeled for a new project starting soon! :)

Tower Defence - First Progress Report

My last post was very wordy. This one should make up for that...

Here's what I've got so far:

It's starting to look a little like a TD game :)

Next up - I think it's time to get them turrets a'shootin!

Kicking off a new project - Tower Defence!

I've started working on a new game... Yayness!

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!

Zombie Survival - now available free on google play!

The question was - Can I make a game in a weekend? The answer was no. Or yes. Or, well... maybe. Kinda. I don't know...

Last Friday I started work on a totally new game - Zombie Survival. By the end of the day Saturday, I did have a playable "game". Or more accurately I had a working game mechanic. There was a good guy, zombies, an objective, and it was fun to play, it even looked pretty good. I guess that could be called a game. Except, it can't. Not really.

A game is more than just the mechanic and the graphics. The mechanic is what really matters at the end of the day, but there's a lot of additional stuff that you have to pack into your game no matter how simple/casual the market - this stuff isn't really optional anymore.

It took an additional four evenings and nearly a whole Saturday morning and early afternoon of effort before Zombie Game was ready for the marketplace. In that time I added screens for highscores, help, gameover, paused, etc, saved/read settings and highscores to/from persistent memory, improved the look and feel throughout, implemented sound and music, did some refactoring (I'm learning as I go, so tend to clean up / rework as and when I have a lightbulb moment), playtested and tweaked difficulty to get things just right (the fine line between challenging and frustrating is where the fun is found!), carried out lots of testing on multiple devices, and did a little bug fixing.

All in I reckon it took about 45-50 hours effort spread over 8 days to go from nothing to published, and I'm really pleased with that. But 48-ish hours effort is not the same as 48 hours elapsed time (lots of problems solved themselves in my head overnight, the subconscious mind is a wonderful thing!), I guess Ludum Dare will have to wait.

I'm sure my girlfriend will be glad to know that I'll be giving it a rest for at least a week or two now... A full time job plus putting in full time hours on an android game resulted in this being quite the antisocial week! Anyway, the game is up on google play, and it's a free download, so why not give it a go? Cute zombie fun just in time for halloween :)

          

Making a game in a weekend… Can it be done?

UPDATE - Download the finished game for free here!

I’d like to enter a Ludum Dare 48 hour competition one day, but I don’t think I’m ready yet. Create a finished game in a single weekend, sounds like a monster task!

This weekend I decided to give it a test run, see how far I can get in a couple of days. The answer is – further than I’d have guessed! Here’s a runthrough of the process…

First 3D project

As expected, I ended up starting a new project... It's quite a leap up from what was achieved in Race Game.

Laptop video (shows 2D and 3D rendering plus raw map files):

Android video (shows smooth 3D rendering on android device):

Next steps will include:

• Control scheme to suit android devices
• Nice 3D models for keys, treasures, etc
• Animated opening doors (quite how is a mystery!)
• Cartoony / cutesy graphics and sound
• Level select screen
• Level complete screen
• Game complete screen
• Efficiency improvements
• Lots more level maps

I think I'm going to drop the 'score' aspect, instead an achievement based level rating sounds good... Finish level for one star and ability to progress to next level, finish level having collected all treasure awards additional star, finish level in under X seconds awards additional star. Quite easy to progress through the levels, but replays required to get 100% perfect three star level rating.

Interestingly, Race Game has a fair number of android 1.6 users. Considering how few 1.6 devices exist, it's clear that there are people out there with low spec devices that want to play casual fun games. With this in mind, I'm going to keep striving for as near global compatibility as possible.

This game will be an arcade/maze/puzzler/adventure mashup. I'm going to leave out enemies, make it more about getting to the exit quickly, exploring, etc. This simplifies things for me, and should result in a game that appeals to quite a wide market.

A separate game that introduces first person shooter elements (zombies, weapons, and a darker art style) could be built on top of this base later on.

The code is freely available here, and there's a demo up on google play - check it out!


          

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:

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 :)

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

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 :)

          

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!