Monthly Archives: May 2015

A Git by any other name

Ages ago I used Git for PooperPig – but had some problems & went back to SVN (which I had used previously, and so was familiar with).

Well, while faffing about recently, I wanted to go back to a previous version – and found it relatively complex in SVN with the support of XCode (i.e. there’s no support for going back at all!)

For this (and a couple of other) reasons, I have decided to try Git again.

So, I’m giving BitBucket a go.

It’s free (which is a good price) and they have all sorts of other tools (for cash) that I might decide to use…

So far it’s proving relatively easy – although I am really puzzled by the fact that can’t find any .svn files in my project – I wanted to remove them before pushing my project to git!

Right now, I”m watching the file upload to Bitbucket (the BitBucket site is really helpful, lots of tutorials and stuff to help you start – so I’m just following their instructions)

What will be interesting is how XCode handles it once it’s there!

Wish me luck.

simplicity is Always the best idea

After struggling with new Scenes, and trying to figure out how to cleanly handle having a pause screen, I decided to step back and look at it a different way.

What do I really want to achieve?

Show a new layer, with some options on it (like continue, restart, choose a level)

so why am I messing around with scenes? well, the reason was because I thought thats how it should be done. But why can’t I just shove a pause layer on top of the game?

That’s what I just did – and it works much better, with much less code.

the only thing it doesn’t do is transitions – which if I want them, I am sure I could fake up anyway!

So I introduced a pauseGame() function…

void GameController::pauseGame()
{
	stopAllFunctions();
	Globals::holdTouchFunctions = true;
	Globals::gamePaused = true;
	this->unscheduleUpdate();
}

stopAllFunctions is just a method that stops any of the user-functions (jumping, pooping etc.) that have started already; this is important if the user presses Fart and pause – or we will hear farting int eh pause screen!

holdTouchFunctions is just a flag to see if touches are going to be processed in the game. As I use areas of the screen for control, I need to disable this when paused to avoid the pig trying to jump if that area of the screen is touched.

gamePaused is a flag that I check in the main update() method – if true, I do nothing, so nothing gets updated! Simples!

I have a corresponding unPauseGame() method too – just sets the flags to false and calls scheduleUpdate.

I had a real problem when paused that, despite resetting all physical objects, my box2d object seemed to magically retain some residual velocity.
I gave up after a while and resorted to setting it back to zero in the update method – it’s only used in debug mode when I’m editing – so no real overhead.

A New Beginning

Of course I wrote PooperPig by starting with the fun bit – the game engine itself.

 

So when you start the game it just started playing.

Then I added a menu option, so I can choose levels, and that sort of stuff.

But I just kinda shoved it in there – and it was a bit of a hack.

Then I added a spawning sound to my entities. So now when I run the game I see the menu, but hear my spawning sound – because in the background it starts then pauses the game.

So now I’m changing tack, ripping it out and replacing it with a more sensible process.

Attempt 1: Coded and hacked my way through it without thinking too much- it all worked, but there were lots of small changes all through the code. It all worked more or less, but the terrain sprites suddenly had a black background.

Couldn’t figure it out quickly, so undid most of the changes and started again – with a more methodical approach (you know, like thinking first!)

We’ll see what happens!

 

… Well, what happened was it went horribly wrong!

Can;t figure out how to do the simplest thing:

Start the game, show a ‘pause’ screen.

Select a level in the pause screen

play that level

Press a pause button

display the pause screen

either select a level or un-pause

I’m tired and I have a cold. That’s my excuse!

Maybe tomorrow!

Spawn of Animation

Up until now I have had animations for the following:

  1.     Default ,
  2.     Dying
  3.     Dead 
  4.     Flying 
  5.     Spitting 
  6.     Eating 
  7.     Farting 
  8.     Pooping

and I decided to create another for Spawning.

I don’t use cocos2d-x own Animation classes – I use  my own, because, honestly, I didn’t think the cocos2d-x animation classes gave me enough control when I first looked at them; subsequently I think maybe they do, but I have my own class which is nicely flexible!

Adding a new type is a simple matter of adding an entry to a pList, together with a string representation – so I added spawning with string “Spawning”

Now I can call Animation::startAnimation(enum::Spawning) and it looks for an animation XXXXSpawning in the collection of animations for that particular Visible Object (another of my classes).

Encountered a couple of issues.

Firstly, if you die while farting(!) I needed to stop the farting animation; I’d just used showAnimation(enum::Default);

And in my reset function I call StopFarting();

So, at the start of a level, it showed the default animation instead of the spawning animation. easily fixed.

The other problem was with jumping. I have a flying animation shown when Poopy jumps. so when he lands, detected using a sensor, I changed the animation to default. Of course, this also stuffed up the spawning animation, as during spawning, Poopy would land, and the spawning animation would stop.

Again, not a difficult fix.

Now all I have to do is actually design a spawning animation! (for testing I used the dying animation, shown backward.)

These changes also gave me a new method, continuePreviousAnimation()

so now, if I am in the middle of one animation, and go off to do something else, instead of reverting back to the default animation, I can continue with the one I was showing before.

 

There’s a hole in the sky!

Well, I thought it was about time I started blogging again – if only to make me do more to PooperPig!

I just added the ability to change the surface (floor or roof) collision mask – this will let me set up places where certain entities can go through the floor or roof.

Why would I want to do that?

My idea here is that I can put some baddies above the roof. they will be activated when PooperPig comes close to them, and start following him (if they’re that sort of baddy) but can’t get to him.

Then, at some point, there’s a hole in the roof through which they can fall.

Depending on the roof height and textures, they may be invisible to the player, so the first they will know is when a bunch of baddies drop out of the sky 🙂

First try was sort of OK. It all works, but in testing it I changed the texture of the ‘sub-terrain’ above the roof – and what actually changed was the texture below the floor!

Time to put by debugging hat on!

That was easy!

Because roof and floor are so similar, but my C++ knowledge is so limited, I have a bunch of code for handling floor and roof that is similar but not quite identical.

Of course, I should have a single method so that changes to the calculation needn’t be done in two places – but it’s quite neet the way it works & I don’t need to change it at the moment. Perhaps one day!

What had happened was that in my ‘drawRoofSubterrain()’ method I had a call to the method ‘drawSubterrainFloorPortion();

Oops!

Now that’s fixed, it looks fine (i.e. the terrain above the roof changes where the ‘hole’ should appear. Now to add a baddy!

Baddy added. He falls through the hole, fine!

Unfortunately this has revealed a bug in my baddy code; the baddy accelerates toward Poopy – but if he misses (which he does if he’s stuck above the roof) he doesn’t turn around and come back for another try!

Aha! turns out that friction was set to 0 on the roof and on the baddy so applying the opposite force never changed his direction and wold at best have bought him to a stop!

Fixed that, and (having added friction) the baddy didn’t move at all!

Of course! the force being applied for chasing Poopy was too small.

Adjusted that and now all is well. Baddy chases Poopy, while stuck above the roof, until it comes across the hole, when it drops down.