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.
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!)
Up until now I have had animations for the following:
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.
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();
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.