Game Goals - Focusing the player

Hey long time no see!

Yeah you know how it goes.  Working alone, working on something new, life, it can all get overwhelming.  And that's fun and all, but I've found a little motivation to get back into the swing of it so I'm going to grab hold and hope my fingers don't slip too soon.  

Great! What are we working on today?

Well basically players need a goal, need some reason to want to play, because oh my goodness right now they have no reason to play.  For that purpose we're going to set up a 'high score' for them to try to beat.  So first let's figure out how to create static data.  At some point we will want a little database for encryption purposes I guess, so that they can't just edit the scores willy nilly.

How will we do that?

We already did.  We used the "preferences" file LIBGdx provides.  I'm not sure if it's encrypted or not.  It would take care of our database issue if it is..  Just 8 more lines of code gave us a high score that's updated when the player dies.  Next we need to display what the high score is when the player starts. 

Okay that's done:

We can make it beautiful later, and there's some lag issue causing first time players to miss this screen if they click too much.  The next thing we need to do is make sure that when the players die that they see this screen again and it shows their score and the high score.  

It's been so long since I looked at this code, if only I had reformatted it and added comments before.. ah well, I guess this is why good coding practices are important.  We don't always have time to reformat and add explanations later.  I guess I was a foolish foolish man!  Oh well, now I'm adding comments.  Just in time too, wandering through this code is like walking through a jungle where you know there aren't any tigers and you feel safe, but the paths you made before are all overgrown and you're tripping on roots and stuff.  Also plus some tigers might have moved in.  You aren't quite sure.  

Now lets figure out how to get the game to simply reset the player position, bottle manager, and the current score on death, as opposed to creating another new game.  Woops, whoa, seems like I finished working on that sometime in between the period of the last sentence and the first letter of this sentence.  I gotta stay on my toes for this! I'm fast!

*Days later*

What happened?

A bug.  There was a bug. It's gone now.  It was a dangerous violent bug though.  Forget everything I said about being fast.

Debugging has got to be the best puzzle game ever.  I finally stumbled across my first 'real' bug in programming.  All the little parts combine together and form some mysterious behavior.  First you stare at it in amazement.  Then you get annoyed.  Then you resign yourself to the hours of time spent trying to fix something because it's too late to restart from the beginning. For me the problem was, how should we describe it, teleporting bottle shots.  Sometimes a bottle would not just get thrown across the screen, it would literally teleport and smash into the player instantly.  We could still see the slow motion falling body frame of the bottle across the screen, well after the player was impacted.

How do you figure out what causes it?  First you eliminate as many things as you can.  I thought for a while that it was related to the 'bottle throwing algorithm.'  I thought perhaps it was throwing the bottles from too close, and they were smashing as soon as they were launched. Ho no.  Next I thought it was some kind of extreme velocity.  Easy to test for, and nope.

After eliminating the whole algorithm and just throwing them with some constants, and watching repeatedly and learning how to recreate the error, I realized it only happened after getting hit with a bottle.  The teleporting bottle shot only happened after getting hit.  This was the key clue.  It gives us the idea that maybe the bottle has some 'residue' on the ground.  It's not getting cleaned up right away.
Eventually we find that the bounding rectangles we created for it aren't getting updated because the bottle is getting initialized too soon.  The thrower turns on the bottle and tries to throw it, but it's already been smashed because it was turned on while the bounding rectangles were still under the player's feet. Why this behavior only occurred for some of the bottles, who knows, and good riddance!  Despite how much work it takes, it is really fun to solve those problems.  If only there was some way I could get some money to do that.. hm..  

What's next?

There are a ton of little things, it's hard to say exactly which one should be next.  Let's say our goal is to polish the core gameplay as much as possible.  It has got to be as fun as possible to smash those bottles.  If it's too easy or too hard, it's not fun to play.  That means we've got to optimize the bounding boxes and the throwing patterns.  As the player gets better we'll add more elements besides bottles, like rocks or grenades, boomerangs, etc.


 

There is a lot of stuff happening in this picture, but focus on the box around the player and the box around the bottles  Can you find the bottles?  Yeah we gotta make the bottles a little bit easier to see, I suppose.. These bounding boxes are too large.  The bottle and the character need to overlap a little bit otherwise we don't see the collision.  It feels "cheap" like the player got hit without actually touching.  First we gotta reduce the size of the bounding boxes.

After that, the things to work on immediately to fix the core experience:

1) Clear transition screens at death, encouraging the player to try again
2) Obvious health bar, making it red perhaps
3) Shadows on the ground
4) Better looking GUI elements
5) Attack animation
6) Better bottle breaking sound, attacking sounds like "hyah!"
7) Interesting bottle arcs.  Not too predictable, not too crazy.

Alright let's meet back here again soon!  Team break!

In a Slump

You're in a slump?

Yep, once every couple months I go up and down, and a couple days ago I was very down.

What was wrong?

Basically short term money stress, something 99.5% of you can understand.  Because even rich people get money stress sometimes.

I can't figure out how to get money in the short term in a way that makes me not hate my life..  Currently I'm in the UAE and there's not much here I can do.  

Can you do freelance artwork?  

I wish I could.. the second reason I'm in a slump.. is that people don't like my art very much.  I don't know why exactly but people just don't.  I've thought long and hard about it and it comes down to two things.  

The obvious one is the lack of technical skill, I'm still amateur.  But if you look at Deviantart there are thousands of examples of amateur pictures being very appreciated.  

The second thing, as my girlfriend pointed out, my pictures aren't special.  There's nothing really interesting or mysterious or thoughtful about them.  I don't really try to put a message into the pictures.  They're just pretty and empty.

Thinking about this caused me to go into a pretty severe two day laying on the bed coaxing myself to exist depression.

The problem is.. I don't have a message.. 

The reason for that is.. I don't value communication about serious issues.. things that are important to me.  

Why is that?  

I once read a quote that impacted me quite a lot.. It goes something like "between two equally learned men, conversation has no purpose."

That idea, combined with the experience that trying to change someone else's mind about something is a bad way to communicate, leaves me with: learning something from others, and joking around, as my two main attitudes.

Which is fine, I get along fine with most people and I enjoy their company.  Except now that I'm trying to make art that people like, and failing, I'm forced to examine both my art and myself deeply.

What will you do now?

Two things.  I'm going to try to develop a painterly feeling art style and improve my background skill to try to get some freelance work.  Anime style isn't in very high demand.

I'm also going to try to put more value on communication.  Putting myself out there, opening myself up to let others try to change my mind, learn more about them, try to foster a lifestyle of connectedness.  Having a desire to communicate is probably the basis of putting some feeling or emotion or message into an artwork that people can feel attraction to.

Is art more important than your game?

Let's say they're equally important.  I've got to be realistic and say that since there are 300 new games coming out on Android per day, mine is unlikely to make any money.  Unfortunately things come back to money in the end, way too often.  If I had some kind of fan base who liked my art, they'd be interested in playing my game.  Which brings us back to square one..

How's the art coming?

It's good, there are more collections of resources on Youtube now than ever before. 

 https://www.youtube.com/channel/UCtqLEajb5DORGv4qXWzVSmA

This is a wicked cool collection of Chinese painters, they're getting me all inspired.

Hopefully after a few days of painting I'll be feeling ready to tackle the attack animation.  I've struggled with backgrounds for so long I'm really hoping to get the hang of them..

Let's see what we churn out!

Walking Animation

How was your trip?

Awesome!  Istanbul and Amsterdam were both well worth visiting.  People around the world are very kind.  They are also a bit pushy and will definitely try to help you part with your money.  Also.. man.. Istanbul has a lot of refugees from Syria.. They'll ask you for money too, and I urge you to give as much as you can.  

Watch out for the experienced swindlers though.. that money would have made me happier if it went to the kids or musicians playing on the grand strip.

What's up for today?

Well the walking animation is passable by itself, needs a little more work, but we really need to see it side by side in the game and judge how it matches the resting animation.  I'm very worried that the perspective is too different between them and it will look awkward.

Great let's throw it in and see!

Yep that's the idea but it's been so long since I added an animation I can't remember what all the steps are..  And, lo and behold, there are no comments in the code.. I was saving that for the great refactoring which.. I assume will still be great when it happens.

Well after just a little bit of mucking around, we've got it in the game!  Here's the little update:

Next we'll work on the attack animation!  I'll be making a Youtube tutorial video out of that one.  It will be long and arduous.  We'll get there though!

Resting Animation

Woo long time no see!  How's it going?

Pretty good!  Dubai is great so far.  It's nothing like what I imagined.  Haven't been able to get my workstation set up yet so I've been roughing it on the Surface Pro 2.  Gotta say though, even though it's such a pain to use, it still lets me get the job done.  4x more slowly, but hey, I'm not complaining.  If I were complaining though, would anyone send me a Surface Pro 4?

How's the animating?

Definitely going to try to get away with doing rough colors on a rough sketch for the attacks.  Doing the lines and accurate colors takes about 10x more time.  So.. I guess I've spent about 40x more time on this one animation than I should have.  Sounds about right.  

The one on the left was done roughly and took about 20 minutes for coloring.  The one on the right took about 4 hours for lines and coloring.

So why aren't you doing them roughly now?

Ahh fear I guess.  I guess I'm just scared that if it's not perfect then it won't be good enough.  Which brings us back to where we are now.  

Now all the lines are "done" for the 15 frames and we're going to color the first one so we can figure out how long it takes and what it feels like to color on the SP2.  Doing lines feels like I'm drawing with both hands tied behind my back.  Like using my feet I suppose.

Here is what the line animation looks like.  It doesn't inspire a lot of confidence compared to the sketch, but I'm pretty sure it will serve our purpose:

This is how we make the shadow forms:

Another thing I've got to be more honest about is the viewing resolution.  I'm 99% positive I won't try to do a PC version of the game so I don't need the assets to be the big 3500px files they are.

Since the images are so small it's tempting to throw rough versions into the game.  I could spit out an animation or two every day at that rate.  I've been considering making a different game with an art style like that, just to experiment.    

Next we'll take the first frame to completion so we can get used to doing things on the demon tablet. Just a reminder, don't purchase an SP2 for art!

This is about right, give or take a few tweaks here and there.  This first frame was done with a typical base/shadow/gradient layer set for each part.

Next we spend a few seconds agonizing about how long this will take.  Let's also congratulate ourselves for getting so much done on the tablet of chaos.  I'm also a little nervous since the first time I tried to animate something with values it didn't come out well.. this is partly experimenting @_@

*time passes*

Drawing leaves a lot of the brain open for musing.  Programming on the other hand occupies all of my language center in a protracted expletive.  Here are some musings.  

What if no one wants to play this game?  Am I okay making this game even if not one single person plays it?  Hmm the answer is probably no.   But the reality will probably be a painfully similar "Not enough people play it to make more than 1$/10$/100$" 

How can I market this game?  What is marketing?  It's where we build up the appeal of something right?  We make implications at deeper meaning and hint at hidden satisfactions.  We say why they need to play this game.

I'm defeating myself a lot here, I can't find a reason why people should play this game.  It's just a game.  Play it or don't.  But that attitude must be wrong right?  What about games that I get excited about?  Why do I get excited about them?  Why do I want to play them so much?  For me.. I like big open world games of exploration and adventure.  I like the experience.  The story.  But I don't have to actually play to get that experience.  For me the games I've enjoyed lately have all been through watching Let's Plays.   

At least I'm being productive while I self destruct~

 I'm so crazy slow but some frames can be copied over with minor changes.



Looks like we're on the right track but the hair will need a little stylizing.  Also I'm thinking since this will be an infinite type game that we should have 3 difficulty modes.



The intuos+surface combination is quite likely the smartest thing I've never done in my life.  I had to wait until someone (thanks my lady) suggested I do it.  In what is probably a first for humanity, there were no driver conflicts.

I'm also seeing that the cuff on the left arm shouldn't be so stiff at the end, it should move a bit to the right..  Is it fixable!?  Yep looks like it.

Here we have some more booby bounce.  Again this was at the direction of my special someone.  "I wish the boobs would bounce more."  She said when looking at some of the earlier WIPs.  I'm not sur why I feel it's necessary to explain that.  I mean I personally also like having the bouncy boobs.  I guess I'm a coward when it come to sexually provocative things.  Good thing she's brave!  ^^;

The hair, as always, is difficult for me.  Luckily most of the issues disappear at the viewing size closer to what we'll see on a cellphone. (Tiny)


After getting to this point I had to ask for feedback.  Luckily my girlfriend was there (again!) to let me know the hair wasn't working for her.  She wanted it to be bigger and have a nice swaying motion.  I had seen an animation on Facebook recently, but as you may or may not know depending on your century, Facebook uselessly doesn't have a way to look up the "history" of what you've seen.

We made a little sketch of how the motion might go:


We're just about at a merging point anyway so we merge each frame's layers and then throw some white on top to give us a drawing surface:




And after much much trial and error I'm 98% satisfied with this one:


Well, one frame was driving me nuts.  Can you guess which one it is?  After chopping the time in half and making an extra frame and giving the hair a little extra movement I'm much happier.


And then much mucking around later, we have this:


It's not finished, but for now we'll stop working on it.  Recently someone trotted out the old "Art is never finished, only abandoned" quote and I snorted.  Scoffed.  Disbelieved.  Ah, what a naive soul I was, two days ago.

Whoa finally.  Good job!  What's next?

Next let's get this bad boy into the game!  Which if I'm not mistaken is also a great time to fix the nagging "left/right" orientation distance jump.

Hud theme design

Time to get started with the theme design huh?

Yep.. 

How are you going to go about doing that?  

Well first I guess I'll Google "Theme design." or "UI design" or  "Hud Design"  

Don't you feel supremely unqualified to design a Hud?  You've never done it before.

Whoaa I'm so negative today.. Well there's a first time for everything. :)

*Goes to Google*

After reading this: http://gamedevelopment.tutsplus.com/tutorials/game-ui-by-example-a-crash-course-in-the-good-and-the-bad--gamedev-3943

I feel that I definitely have no idea what I'm doing.  I thought I would just make some nice background images and stick then behind the bars and buttons.  Now I'm ready to meditate for a month on the existence of life.  Start with the basic questions first, I say.

What design do you want?

Yeah, I want something that's Korean-esque.  The game has lots of Korean themes, maybe we'll even say it's set in Korea.  Here are some reference images that appeal to me:

The plan was to use these shapes and patterns in various parts of the UI. 

I think that's fine, let's start figuring out what the UI consists of.

Parts of the UI:

• Life bar
• Energy bar
• Bottle count
• Timer
• Joystick
• Attack/Special Buttons

We also need a menu button right?  Anything else? It's probably time to play some games and see what kinds of buttons they have.  

First up is Zenonia 5, what do you think of it?

Zenonia 5 is a great looking game, but after my 10th "Kill 15 Crocodiles and bring me their meat" quest, I felt burned out.  I'm past that stage of my life where I want to feel like I'm working by grinding away, fulfilling a game's menial demands.  

Now I demand something more mentally stimulating!  I demand the game of making a game.

But Zenonia 5 is beautiful.  And that Hud looks awesome.. So let's see.. what can we cherry pick?  First of all, those buttons on the lower right side are very small.  I think that works well for them because they don't have any combination button presses.  Will we?

Secondly they have this nice metallic circular theme with lots of blank space.  We can also set the Opacity to be lower I believe.

Thirdly they have a shop button..  Do we want a shop button?  We were planning on selling a costume and pets.. But putting that button on the main part of the screen would be rather annoying, when players are trying to see bottles or other items.  But now we are not selling anything!

Let's take a look at another game: Shadow Fight 2

Two bigger attack buttons in the lower right.. but look at that huge touchpad on the left.  Does it need to be that big?  Were they worried players might want to see their character?

This game also lets you buy stuff, but happily no store button. Now I totally don't feel pressured to have one.

One key difference in play between Shadow Fight and Bottle Smasher is the auto-facing design.  Our character always faces the enemy.  For us, we have to decide if we want to have front and back attacks or only front attacks.  Do we want to make the player work harder?  Will that be more rewarding for them?  I don't know..  This seems like the kind of thing to decide through play testing.   

What are you thinking?

What kind of design to do..   Do we want a 'wood' feeling?  The bottle counter going dead center at the top actually might be distracting since we have a vertical attack and bottles are landing on top of us a lot.  Let's put the bottle counter and the timer in the upper right.  And a little menu button in the bottom center.  

Also green for the life bar might not be so great since the bottles are green too.  Let's make the life bar red like in these games. 

Zenonia's upper left has a little face and level and exp counter, but we don't need that face.  Right?  It's just getting in the way of the valuable screen space right?  Right?  So let's just use the 'door' design to give our life bar and our buttons a little zest.  I've got some ideas, time for a mock!  

*much time later*

 

Here is the current mock and the direction we're going.  The top elements need to be redone more sharply and with some color control, perhaps chromified.  My inner critic #8 is telling me that the circles on the bottom and the designs on the top don't match and that this is not good.  He says that people will possibly make comments about it, and that they will lose respect for the game.  He might be right, my inner critic.  However I am perfectly happy with the shape differences.

The menu button needs some love, how about a little 'see through white rice paper' kind of effect?  Yup that looks good.  Another thing I'm wrestling with is adding a timer.  I'm somewhat leaning against it..  The 'special' button will need to become a kind of 3 option slider roller ring thing, considering making it look 3d but not sure yet..

Okay next let's get to work on mocking up the new game screen, the explanation screen (loading), and the results screen!  Good luck!

P.S. The move hasn't completely destroyed productivity~ So far UAE seems alright, it's only been a couple days but the people are very friendly!

Project Reorganizing

Reorganizing?  What does that mean?

Talking with a friend helped me realize that the goals of this project need to be restructured.  I need to reduce the timeline way way down.  Cut out a TON of content.

Don't you like this project?

I love this project!  The programming is always rewardingly difficult and learning animation is incredibly INCREDIBLY helpful!

What was your goal for this project?

Yeah they definitely changed.  Originally the goals of this project were: 

- To make a first game and finish it

- To make a precursor game for a bigger version

- To relearn programming and gear up for a bigger different game

Then in the middle, after diving into animation and the Libgdx framework and getting excited about the possibility of earning money with it, and finding myself loving the process, I went into full on feature-creeper mode.

However the problem is that the game itself isn't one I'm passionate about.  I don't think "this is a game that needs to be made."  The problem is that there is another game I feel incredibly passionate about.

If I could be sure that this game would be a money maker, I would of course finish it in all of its 1.5 year long development glory.  And if people get excited about a smaller version of it, I'm more than happy to keep going with it.  However as I'd like to be a game developer, as a career and actually make a living, as opposed to the slowly dying I'm currently doing, I need to make the economic choice.  I've got to invest my time in the game I believe in strongly.

So this game's focus is going to be re-oriented as an infinite smasher.  Less levels, less effects, less attacks, less everything.  I'm satisfied with this decision.

Well, back to the Hud design as that hasn't changed much regardless of this "refocusing."

  

  

Painless Fonts~

How'd it go?

Finally something without hidden complications!  Fonts are a breath of fresh air.  Making them and using them is too relaxing! 

On a side note, I cannot recommend the Surface Pro 2. That probably doesn't matter much since the 4th version is what people are looking at now.  Still.  STILL.  Don't buy a Surface Pro 2.  The number of random issues is greater than the number of random perks.  

  - The track pad mouse on the keyboard will randomly get 'sticky' on some location and snap back to it like a rubber band.  

  

  - Sometimes disconnecting the keyboard causes a hard reset

  - Home and end keys stopped working for some inexplicit reason.  Probably because I need them.

  - The screen pen accuracy varies from one end to the other.  As an artist this is a mojo destroyer level 99.

  - Sometimes the mouse will wobble uncontrollably and taunt you.  You know that disconnecting the keyboard could reset the computer, but it won't stop wobbling.  Like right now. 

  - Want to use your fingers?  Sorry those buttons are too small, not going to happen.

  - Waking the Surface up from sleep mode teaches me to be thankful to my mother for her patience when she used to get me up for school.  MUST BE VERY PATIENT WHEN TURNING ON SURFACE PRO 2.

  - Windows 8.1

  - Peeling paint.  Seriously what?
  

  - The dissatisfaction of knowing you're already 2 generations behind.  

  - Ridiculously quiet speakers.  Do Microsoft executives employ mice to design this shit?


Anyway now that you've been suitably warned, back to the font!

This could not be any less quick and painless if it were  _______.  Be creative.

And that is entirely thanks to this video:
https://www.youtube.com/watch?v=dxPf1M7YORU

With a voice on par with Ben Stein, he walks you through every minute detail and after 15 minutes you have the POWER to unleash your CREATIVITY on the UNSUSPECTING citizens of the DRASTICALLY overwhelmed CITIES.

I dunno where this is going.  Trying to do everything on the Surface Pro 2 has driven me insane? Or packing? Moving to a new country?  A little nervous to be going to Dubai.  Hope it goes well, just lots of things to be OCD about. Everything is all packed up, waiting to be re-packed once I've procured a scale.  I've got desktop withdrawal.  All the art is over on it..  Okay enough excuses, let's finally figure out how to draw on this tablet.  

Here's the code for the font scene2d label above:

public void addScore(int value){
    bottlesBroken += value;
    bottleLabel.setText(String.valueOf(bottlesBroken));
}

Constructor:

chunkFont = new BitmapFont(Gdx.files.internal("chunkfive-export.fnt"));
bottleLabel = new Label(String.valueOf(bottlesBroken), new Label.LabelStyle(chunkFont, null));

What are you working on next?

I've been thinking a lot about how to make the level useful, ways to use the space.  The problem is the original intent of the game.

The intent was to be a precursor.  Not a full game.  A taste of a game.  The game I really wanted to make was a Megaman/Blaz Blue combination.  A nice big 2d side scrolling world.  Dialogues, beautiful character effects, attack skills.  But I knew that game would take a long time and people said not to shoot too high for a first game.  

The Megaman/Blaz Blue game is itself just one of the games I want to make.  I've got an idea I'm excited about for an educational RPG.    

So the problem is that breaking bottles and dodging obstacles doesn't really need a big huge world.  We've got to come up with a way to use the space a level provides.  Here are some ideas:

• Player can collect energy bottles to fill up their special attack bar
• Run from some attacks that are big  
• Dialogue trigger points, as the player walks across dialogues will pop up
• Terrain assisting, like being able to jump off a spot to see higher, see a bottle more clearly
• Hiding under some parts of the terrain to escape bottles

Any other ideas would be greatly appreciated ^_^

I'm also ready to start mocking up a full Hud with background pictures for the health bars, buttons, etc.. but.. need a real computer to do that..  Arrrr using photoshop on the SP2 feels like I'm doing surgery on the head an angsty pin.

Implementing the Overhead kick

Man with all these different posts, how are you keeping track of which one you should submit first?

Hahahaha

Okay so here we're going to figure out how to implement the overhead kick.  We're just using a rough sketch for the "prototype."  Honestly "prototype" is starting to take on the meaning "Rushed and half assed."  Using unfinished assets, half baked code, unplanned levels.  But that's okay.  Spending a full ass of time is just not practical.  Not to answer those important early questions.

Until now we've been using a pixel as an orientation.  That pixel gets lined up by the code to make sure the animations play in the right place.  

These are two frames from the current 'Jump Kick' animation.  The character doesn't actually go any higher in the image, we let box2d take care of that.  We didn't have to pay attention to the vertical distance in the drawing at all, we just moved it up a tiny bit mostly by accident.  Also please ignore how much bigger one is than the other, thanks.  

Can we do the same thing for our overhead kick?  Can we just delete the white space at the bottom of the image and stick an orientation pixel in there?  Can we just not do that and let the animation determine how high we go?  Can we please be lazy??

No sir.  Not for us, not here.  We have a box2d body that the animation is attached to.  When it jumps, we stay stuck to it.  It makes it easy to handle gravity and ground interactions.  If we don't use the box2d gravity then there might be something strange later, like the player thinks he's doing an overhead kick but really his box2d body falls to its sad death.  So we will use the box2d physics and give the body a push up.  Not unlike the time I made the mistake of helping a girl in a short skirt climb up a metal pole.  Yes both of us didn't think that one through very well.

So yes we will push our box up and then it will fall down with gravity.  Let's look at the overhead kick again with a fake little red happy box2d body.

For our first question we can ask: how high does the box need to go?  Does the box need to stay in sync at the bottom of the character?

Well, yes if we want the character to be able to move right or left while kicking.  If they can do an overhead kick while moving and we want them to be able to jump up on different platforms, yeah the red body box has to stay at about the bottom of the character in the image.


Beyond that we probably don't want a normal gravity interaction with some of our attacks or jumps.  For example as we saw earlier, when we let go of the right button we don't want our guy to slide to a stop slowly.  It's disconcerting to see our character do that.  Other objects look fine but when our in game persona isn't under our direct control it feels uncomfortable.  When we are walking in real life and we want to stop we don't slide to a stop while waiting for ground friction to do its magic on us.

For now we are setting our speed to 0 when the player lets go of the button.  Later we might use a fixture and adjust the friction setting as detailed here: http://www.iforce2d.net/b2dtut/fixtures

Which brings us back to the overhead flip.  We can see that the time spent going up and the time spent going down are very short.  To capture this effect in the game lets first try increasing the gravity for just the character.  Then we'll increase the force of the push.  Later to get some fancy "flying through the air" effect we could try setting her gravity lower during the animation or attack.



Here we set up the bounding boxes for attack, hurt, and orientation.  (Can't see the last one)

Then we use the gdx texture packer to put all the files into an atlas.











Next we load them all up in an XML file to read them into the program.  (Making sure to duplicate the frames that last for .1 seconds instead of .05 seconds.)

Then after loading up the animation and adding a new state and input method (all of which I'll go into excruciating detail with later) we've got our overhead kick!

The last thing is to add another button to the HUD.  Scene2d is not well documented in terms of table layouts and getting things to line up.  It's less like programming and more like playing the lottery.

*Time passes*
Well we played long enough and got what we wanted for now:



And here's the code so you don't have to keep rolling the dice;

controls = new Table();
controls.setHeight(stage.getHeight());
controls.setWidth(stage.getWidth());
controls.align(Align.bottom);
controls.add(touchPad.getTouchPad()).expandX().align(Align.bottomLeft).padRight(stage.getWidth()*.8f);
controls.add(kickButton).maxHeight(stage.getHeight() / 4)
        .maxWidth(stage.getHeight() / 4).align(Align.bottomRight).expandX();
controls.add(kickButton2).maxHeight(stage.getHeight() / 4).expandX()
        .maxWidth(stage.getHeight() / 4).align(Align.bottomLeft);

I gotta say, this new attack makes hitting the high flying bottles a lot more rewarding..  Waiting and trying to get the timing is just difficult enough to be satisfying and not so hard that it feels cheap.

Prototype First Reactions

Whoa so we showed the game to some people!

Yes my phone was put into the hands of a few other indie dev type people.  Without any explanation of what the game was or how to play. It was incredibly helpful to watch them.  Watch them like a total creeper.  Because the game is so basic they didn't have much feedback to give.  There were a few "Nice direction.  Good art" type comments. But the most important thing they told me wasn't something they communicated with their mouth face part.  It was the way they played the game.

It would be easy for me to be disappointed because they only played the game for about 30-45 seconds before handing it back.  But what they did when they played, man that was awesome.  They were focused, trying to figure out what to do.  They were fully absorbed, for 30 seconds.

One guy mashed the attack button.  One guy immediately walked across the game world and ignored!? the bottles.  Another guy tried to time his attacks carefully.  No one was able to break 15 bottles and clear the level.  (Not that they kept trying after they died.)

The takeaways from this:

• The bottles that go off the screen are too hard to anticipate for an absolute beginner
• There must be something preventing a player from continuing on in the level, some kind of obstacle that they have to overcome
• It's too hard for players to see the character right now, it's just a bunch of lines
• There's no sense of reward when they break a bottle, the tiny little 'flash' effect is barely visible
• The life bar is too hard to see or keep track of
• The character's attack trajectory is too hard to anticipate in relation to the bottle 
• As expected, without any sense of accomplishment or way to gauge their progression, or reason to continue, players have little interest in going multiple rounds or getting better.. 

So the next steps in development will be:

• Making the character's movement stationary/player dependent during left/right attacks
• Adding a 'tweeny' effect to the font (where the score number gets bigger and shrinks when they break a bottle)
• Changing the score font to something visible/exciting
• Throwing down some super rough values on the characters so they are vaguely more visible
• Changing the bottle throwing function so that I can optionally control the height of the bottle trajectory.  (To keep the first batch of bottles on the screen so that players can get used to them)
• Changing the bottle breaking sound so that the sound is different when they hit it, as opposed to when it hits the ground, or hits them
• Figure out how to make moving across the level harder/slower/staggered
• Add the Hud bg images

And of course, keep working on those animations @_@

Before I had a bunch of questions I wanted to ask people but now I just want to see them play.  Observational Scientist Mode Activated. O_O

Player controls

What are we doing today?

We're going to work on something that I kind of stupidly haven't yet thought about in much detail.  How the player moves and attacks and what kind of abilities they have.  Yep.  Just the minor stuff really. Not like anyone really cares about that.  People are going to play this game for the gratuitous panty shots.  No, I jest.  50%.  Lets jump into the storm of braining.

How do we do this?

I have no idea.  

I guess we look at other games and say "Yes, your idea is good enough to steal." In this case that would be MegamanX and BlazBlue and Zenonia.    Because although Bottle Smasher! is a small game, don't forget we've got our eyes on expanding it to be a much larger game... ..next year. 

So lets ask a question, we have to focus.  "What do players need to do?"  

*Raises hand* They need to break bottles and dodge other weapons and navigate the terrain.  

The need to dodge gives us related movements like jumping, ducking, sliding, dashing. 

The need to break bottles gives us attacks: Attack.

Is this going well?  

No it feels too basic to do this kind of analysis.  We've got the shield ability, attacking ability, healing ability.. woo maybe a time slow ability?  Hooo boy.. that.. hm.. mm.. i dunno.  For attacks, something like.. hmm we could have 'left attack' and 'right attack' buttons or we could make them be 'front attack', 'top attack' and 'back attack.'

How about combos?

Yeah it would be good to have combos!  Definitely pressing the attack button two times should do a different move.  I'm not sure about combining moving with attacking.. But without it maybe it will feel too clunky.  Not being able to move and execute an attack at the same time..  Right now the attack I've been using has an auto move built in and it locks the keys.  Perhaps there should be two kinds of key lock, one for moving and one for attacking. That way some moves will let you be mobile during their execution.

How many buttons do we need?

So far.. 3 attack buttons, plus two special buttons.. that's 5 buttons.  That's way too many.. right? Maybe the special abilities are scrollable.  just swipe to switch... okay it's time for a mock up!   

What's next?

Now we need to design the attacks.  They'll all be kicks because that's her style.  They all need to be useful too.  A question we have to answer is.. does the character's facing direction affect the kick?  For example if she's facing right, and the player hits the left button, does it do a back attack?  Or does it do the "left" attack..  Let's answer that later.  Now we need a mock to show kick hitbox ranges.

The inner bands represent the first attack, with the outer band being a double tap.

I'm not sure yet but I'm leaning towards having different attack animations when the player is moving.  Though to be honest it might be best to have only two buttons, an attack button and a special move scroller.  Or perhaps just left/right.  Hmm.. a little perplexing but not the biggest issues to address yet.  Let's move forward and get those rough animations done quickly so we can get a prototype out!  

Disposing

Making a death screen huh?

Yep, hoping this one will be pretty fast.  Our prototype will have ugly barebones screens that may need to be refactored later.  Perhaps even the death screen should just be the new game screen.  Yeah.. Okay so let's just dispose of everything, load the new game screen, and reload the game.  (For now)

Great, what needs to be disposed of?

According to this list: https://github.com/libgdx/libgdx/wiki/Memory-management  At least a lot of stuff.  So let's call that dispose() method and figure out how to find memory leaks with the debugger.

if (hud.bar.getValue() == 80) {

    game.setScreen(new TransitionScreen(game));
    this.dispose();
}

Let's die at 80% health to speed this up.  Our first error is..!?  Crash to desktop!  Congratulations!

1) "Process finished with exit code -1073741571 (0xC00000FD)"

This seems like a great time to learn how to use a debugger, let's give it a whirl, setting a breakpoint at this.dispose().

Ahh, the culprit was calling world.dispose() two times.  Once in our playscreen dispose() and once in the Bottle class dispose().

2) AL lib: (EE) alc_cleanup: 1 device not closed

This happens because after we dispose of stuff our render method is still being called.. had to add a little 'disposed = true' check in the playscreen render().

update(delta);
if (disposed == true){
    break;
}

3) Couldn't load file: Spritesheets/explode2.png

Which was fixed by disposing an atlas in the bottle class.

4) Memory leak crash


Each spike set represents starting a new game and the plateau is the 'new game' screen after we die.
Well.. I guess it's a memory leak.. it doesn't seem like very much memory is being used, definitely something isn't being disposed but it crashes before it gets very high.. debug time!

Any progress?

This blog has an amazing post about how to hunt for memory leaks: 

http://www.theshiftingbit.com/Fixing-Memory-Leaks-in-Android-Studio

I've got the programs it lists and I'm fired up! Let's dive into the matrix and be the Neo!

What is this?

Here we tried running the game three times, so we can see three big PlayScreen objects and their.. timers.  The timer class is.. big.  Like opening the bathroom door and finding your dog sitting on your toilet reading a newspaper.  It's just confusing.  A dog?  A timer?  What?    

I didn't even know I had a timer in PlayScreen.  And why only that timer?  There are a bunch of timers kicking around doing useful things.  

Upon closer inspection.. it's our beautiful nested timer.  The same one we made last week for the background animation.

*1 day later*

Whoa what happened?

Man.. I'll tell you what happened.  Disposing.  That's what happened.  The silly utterly naive me of last week went around adding resources willy nilly.  Drop a new local texture here, plant a new pixmap there.  So careless.  YOU WERE SO CARELESS! DO YOU HEAR ME??  I can't talk to my past self but I can talk to my future self.  Don't worry buddy, I got your back.  No more carelessness.  I promise.  You are looking at a changed man.  

It's fitting that I almost didn't even think this blog post would have any experiences worth recording.  "Don't even need a death screen.  Just dispose and make a new playscreen. That isn't even a paragraph."  I was happy for about 30 minutes when there was something interesting happening.  And then for 10 hours, I was less happy and more determined, and also somewhat confused and hesitant, like a mouse approaching a cheese.  Fully engaged, but man.  I was on the brink of getting down to that big rewrite which is inevitably coming.  All for want of a new playscreen.

Good job.  How do you feel after fixing all that?

A little burned out.  There's so much moving stuff happening in my life, about to head out to a new country (UAE) and be with my lady.  I want to just focus on making the game but there are furniture removers to call, friends to meet, classes to have, cleaning and throwing stuff away.  It's really not that much work I guess.  Just mentally taxing.  Very happy to get rid of the useless junk I've collected.    

Let's see if we can somehow stay productive throughout the move.  And also let's see if we can avoid being stressed out if we aren't all that productive.  Gotta enjoy the inconveniences too!

Still hoping to get a prototype out before the end of the week!

Fixing the Joystick + Adding Buttons

Now we're working on the Joystick huh?

Yeah, when the player lets go of the joystick the character should stop moving immediately.  None of this inertia nonsense that Box2d provides. 

Since I don't want to make my own physics yet (though may need to later) we have to explicitly tell the character to stop.  When do we tell it to stop?  It should stop when the player lets go of the joystick!  

What if the player is falling or jumping?  What if the player is doing some attack or move that pushes them forward?  In these cases the character should keep moving.  How do we tell it to stop moving except if it should keep moving?

Until now I had this:

Which is getting too lengthy.  Instead lets have a boolean 'currentlyActing.' Any action besides walking will set currentlyActing = true.  Some attacks may have their own movement, and they will tell themselves to stop accordingly, and walking may be able to interrupt that motion, but only at times we allow by setting keysLocked to false before the animation ends.

Why are you making things bold?

I dunno.. suddenly I wanted to.  I thought it might make things easier to read.  It's not very consistent with the rest of the blog though is it?

Nope, is that a problem?

Could be!  Let's find out!

Every other action will set currentlyActing = true and sometimes keysLocked = true. So whenever we release the left or right joystick, we simply check if currentlyActing = false and if it does, set the motion to 0.

Well, the actual system is turning out to be more complicated.. The reason is that we have 'States' and 'Actions.'

public State getState(){
    if(b2body.getLinearVelocity().y > 0 && currentAction == null)
        return State.JUMPING;

This is our getState() function which will tell us which animation frame we need to get.  If Kicking was a 'State' then we would have to say 'if the player is moving up AND the state isn't kicking, make it jumping.'  Later that would be 'not kicking, not punching' and so on.  Better to make it a separate field.

    else if(b2body.getLinearVelocity().y < 0 && currentAction == null )
        return State.FALLING;
    else if(b2body.getLinearVelocity().x != 0 && currentlyActing == false)
        return State.RUNNING;
    else if(currentAction == State.KICKING)
        return State.KICKING;

    else        return State.STANDING;
}

Now our 

@Overridepublic boolean keyUp(int keycode) {
    Gdx.app.log("lkey up","");
    if ((keycode == Input.Keys.RIGHT || keycode == Input.Keys.LEFT) && player.currentlyActing == false) {
        Gdx.app.log("lkey up","");
        player.b2body.setLinearVelocity(0f, 0f);
        player.currentState = Sarah.State.STANDING;

Is working just fine again, for our keyboard inputs.  Now we need to figure out how to get TouchUp from the Libgdx touchPad().

*Time passes*

Which doesn't exist.  Instead we just do a check to see if the touchPad is at 0:

if (hud.touchPad.getTouchPad().getKnobPercentX() == 0f && player.currentlyActing == false) {
    player.currentState = Sarah.State.STANDING;
    player.b2body.setLinearVelocity(0f, 0f);
}

And this lets our walking work nicely.  Now we stop when the touchPad is released.




Hmm does it look a bit shabbier because it's a JPG?  Hmm I need to work on getting the highest quality image possible pretty soon..

What's next?

Next we'll add a button for our kick :)

It's all working nicely, here's the code:

TextureAtlas kickButtonAtlas = new TextureAtlas("kickButton/kickButton.pack");
kickButtonSkin = new Skin(Gdx.files.internal("uiskin.json"));
kickButtonSkin.addRegions(kickButtonAtlas);
Button.ButtonStyle kickButtonStyle = new Button.ButtonStyle();
kickButtonStyle.up = kickButtonSkin.getDrawable("buttonUp");
kickButtonStyle.down = kickButtonSkin.getDrawable("buttonDown");

kickButton = new Button(kickButtonStyle);
kickButton.addListener(new InputListener() {
    public boolean touchDown (InputEvent event, float x, float y, int pointer, int button) {
        //Gdx.app.log("my app", "Pressed"); //** Usually used to start Game, etc. **//        kickButtonPressed = true;
        return true;
    }

    public void touchUp (InputEvent event, float x, float y, int pointer, int button) {
        //Gdx.app.log("my app", "Released");    }
});

And the table, because that stuff drove me nuts!

Table controls = new Table();
controls.setHeight(stage.getHeight());
controls.setWidth(stage.getWidth());
controls.align(Align.bottom).setFillParent(true);
controls.add(touchPad.getTouchPad()).expandX().align(Align.bottomLeft);
controls.add(kickButton).expandX().maxHeight(stage.getHeight()/3)
.maxWidth(stage.getHeight()/3).align(Align.bottomRight);
stage.addActor(controls);

However.. now we've got a multiple button press issue.  If we press the touchPad on the left, the kick button ignores us.  Google!

*Hours later*

Turns out that even if you are using a touch device, such as the Surface Pro 2, scene2d multi touch doesn't work on desktop.

Try it out on the device!  Multi touch works great!  But I've got an error in my fragment shader: cannot convert from 'const int' to '4-component vector of float'

So switching our nice color *= 5 to color = color + color  + color + color + color solved that.. T_T

Lastly, the fruits of our labor!

Organizing the Project

How's it going?

It's alright!  The resting animation is coming along nicely.  

The next programming bit to work on is going to be saving and related things.  Beyond that though the lack of a schedule or timeline is causing me a great deal of stress.  Without knowing how long things will take I'm constantly pressed to get it done as quickly as possible.  And despite working nonstop, I never feel like I'm making good progress.  There's a list of programming features to add to polish the game and I can make rough guesses as to how long each one will take, and do the same for the animations and assets, writing, etc.  The issue is that sometimes seemingly minor things can suddenly take days.  If I had more experience it would be easier to guess.. Well let's do the best we can!  

The list of programming things to do (So far): Time guesses D = day h = hour: 69D

• Debug + Skin Joystick:  2D
• 'Pooling' ?: 2D
• Disposing stuff: 2h
• Font change: 3h
• Fix dialogue double click: 4h
• Post level stats: 1D
• Level high scores: 4h
• Saving data/Encrypting: 2D
• Loading saves screen: 5h
• Mana boosting items + spawns: 2D
• Level timer: 2h
• Flashing eye dialogue: 2D
• Combo hits?: 3D
• Camera jerking on special move: 1D
• Level select screen: 5h
• Skill view / select screen: 2h
• Pets / Costumes / Extras: 4D
• In game payment: 3D
• Ad support: 3D
• Pet AI: 5D
• Level manager dialogue finder: 1D
• UI attack buttons: 3h
• UI menu screen: 4h
• UI health/time/score frames: 4h
• Sound/Options screen: 3h
• Other weapon types / attack physics: 10x2D
• Shadows (player/weapons): 1D
• Global leaderboard: 3D
• Share on Facebook: 1D
• In game 'currency'/Points/Linked to payment: 2D  
• Falling death: 4h
• Incline/decline terrain: 4h
• Lives / Waiting system: 2D
• Life buying: 1D
• Fix empty life bar: 3h
• Bottle pass through ground: 6h
• Bottle smash sound variations: 2h
• Weapon direction reaction: 1D
• Button hit combinations: 1D
• Optimization/Restructuring: 4D
• Multiple/Ordered button press recognition: 2D
• Set up 'effects' sprites for attacks: 2D
• Dialogue skinning?Json?Image?: 2D

Graphics to do (So far): 342D O_O

• Animations
• Resting: 15D
• Walking: 15D
• Dashing: 10D
• Sliding: 10D
• Jumping/Falling: 10D
• Attacks(3/4): 30D
• Attack/Moving Effects: 15D
• 10 Object types: 2D x 10
• 10 Levels: 4D x 10
• 3 Pets: 10D x 3 
• 1 Costume: Each animation x 2D
• Bg Animations: 4D x Level
• Hud
• Life/Mana/Timer/Bottle Frames: 3D
• Dialogue frames: 1D
• Transition screens
• Home: 2D
• Loading screen: 2D
• Options: 2D
• Saving/New/Loading select: 1D
• Level select: 2D
• Goals/Quest: 2D
• Failure/Finish: 2D
• Skill select: 4D
• Pet/Costume 'purchase': 2D
• Life purchasing/waiting: 2D
• 10 Character busts: 10x 5D
• Promotional art: 10D

Music/Sounds: 1-2 Months?

• Level themes: ??
• Hit effects: ??
• Character attack sounds?: ??
• Text scrolling sound: ??
• Score totaling sound?: ??
• Timer sound?: ??
• Menu select sounds: ??
• Screen opening sound: ??
• Weapon sounds: ??
• Dying sound: ??
• Other character sounds: ??

Writing: 15D

• Character dialogues = Level #: 15D
• Game promo stuff?: ??
• Storyline: Combined with above

This total puts me roughly around 471 days.  471 working days.  Not every day gets enough time to be considered a working day.  I was only getting about 4 working days per week.  A little more these days.  Much less in the immediate future as I'm moving and there are travel plans.  Whoa.  Oh my god.  Until now I was entertaining fantasies that I could finish this in about 4 months.  100 working days.. 

What's the problem?  

Moneyyy.  Money.  MONEY. The work is incredibly fulfilling.  Loving every exhausting minute of it.  Unfortunately both of my part time teaching jobs stopped recently (As ESL part time jobs do.)  Which fits perfectly with my moving plans.  Depending on how the next few months play out I'll probably be in a position where I need to get another full time job.. I wanted to avoid doing a Kickstarter for many reasons.. My credibility, fan base, target demographic, are all not quite enough for a successful Kickstarter.  I mean I'd need tens of thousands of dollars AFTER rewards, taxes, etc.

What will you do?

Well shortly after recovering from this sudden, massive, debilitating and unmotivated state I currently find myself in..
I should either plan to get another teaching job in 4 months, push Patreon as hard as I can, create a Kickstarter, or..


*hours later after life stuff*

Well, let's see what happens!

What is the next direction for the game?

Next let's work on getting the barebones prototype into the hands of my friends.  The prototype basically exists to get the feedback process going.  I don't believe the 'game loop' is the measure of a game's satisfaction, but it definitely needs to not get in the way.

What makes a game enjoyable?

Ahh man that is a huge concept to unpack.  It's got lots of aspects and layers.  At it's most basic a game is fun if it is satisfying.  Satisfaction comes in so many different ways to different people.  It could be:

• Having a better score than someone else
• Solving a puzzle
• Seeing the answer to a mystery
• Feeling their skill improve
• Connecting with other people
• Feeling important
• Making creative expressions using learned knowledge

Another important concept is that we see games through the lens of our life experiences.  Many people don't enjoy games because they don't get any satisfaction.  Part of that is because the game doesn't let them use any of the skills or experience that they have learned are important to their life.

So how will you do all that?

Yeah I'll try to nail as many of them as I can, but everyone enjoys them a little bit differently.  Some people like really hard puzzles, some people don't.  Some people want a lot of story, some don't.  

What's the next thing to work on?

I have to admit, knowing that this game won't be finished for over a year frees me from feeling pressured to finish it in a few months.  Next we'll get the feedback process rolling by putting it in people's hands.  

To do that we need to:

• Fix the joystick
• Add the attack buttons
• Add the rough attack animations
• Set up a level

One thing to be careful about is the kind of feedback I'm asking for.  Obviously I don't believe that the rough prototype will be 'fun', or satisfying, so what is the question I need to ask them?

Hmm maybe "Is it responsive enough." Or.. "Is it too hard to hit the bottles?"   Okay let's make a list.

1. Is it too hard to hit the bottles?
2. Are the controls responsive enough?
3. Is it hard to keep your fingers in the right place?
4. Did the bottle smash sound get annoying?
5. How much did you pay attention to the background?
6. What kinds of other attacks do you want?

Yeah that should be a good start!

Here we go!

Player Hit Effect

What's up today?

Not much! Actually not much in the way of results.. X_X  For the past couple days the resting animations have been kicking my ass.  They are hard.  The idea is since there won't be that many animations in the game, they should all be higher quality.  Also they are a little fan servicey, with panty shots or somewhat suggestive movements.  

This one was the original concept but the motion looks half finished.  Finding a way to push the motion further has been vexing.

Then an art buddy suggested trying a fresh attempt which resulted in this:


But this one looks like she should be on a dance floor.  Which is no surprise, the reference was a dancing girl.  There are some things appealing about it but overall I thought 'nope nope lets make it be a bouncy taekwondo style'



But that concept didn't really appeal to me either so I went back to the first one again.  And sunk another 5 hours into it.  I'm loving the art practice.  Art is hard and improving is fun.  I totally don't mind spending MONTHS just working on the art.  Time just flies by.

At which point I realized I need a 1 hr per day programming rule to make sure the project doesn't grind to a halt.

Nice, so what are we doing now?

Next we're going to do a somewhat easy (hopefully) hit reaction.  When the player is hit by a bottle there should be some reaction.  I don't want to do a reaction animation for each situation.  (Not yet) Instead we'll do one of those 'quick freeze and flashing white' things.  Maybe the player is invincible for a couple seconds after getting hit?  Nah.. That makes it too easy.

Sounds good, what's first?

Well-

Wait do you think people will be thrown off by this 'stream of consciousness' style question/answer format?

Yep definitely, which is why they should check out David Morrell's book http://www.amazon.com/The-Successful-Novelist-Lifetime-Publishing/dp/1402210558

and try it out for themselves, it's a very helpful tool to prevent all kinds of mental blocks.

Cool, so where were we?

First we gotta figure out how to make a white layer on top of our character sprite.  Sprites have a setColor() function so let's use that.

Hm.  

*Some time later*

Turns out that the set color function tints the sprite.. it's a little like a multiply layer in photoshop.  Which means we can't 'tint' white..

*Much time later*

Well shaders are a really interesting option..  Look at all this crazy nonsense: http://glslsandbox.com/

*Day later*

So we've got a shader set up that makes something very white-ish. I'm liking it.

I'm tempted to figure out how to throw a solid black outline on it but.. we'll leave that until much later

The code breakdown goes like:

The shader stuff is more than a little confusing and it's going to need a lot of time to for me to learn it. Definitely check out some Youtube tutorials.

What's next?

Now we gotta make it flash white..  We could use a nested timer like we did with the smoke animation.  We could.. hmm let's see how many flashes would look good.. Let's make a mock in Photoshop.

Yeah I guess 3 flashes at .1 seconds each looks good, but maybe 4 flashes is better.. somehow 3 doesn't feel like 3 right?  It feels like 2 unless you really look at it?  I'm not sure.. not sure.. hm..

What are you thinking?

I'm not sure if the player should be invincible for the .3 seconds after they get hit and If they are I'm not sure how that would affect the code design.  We could use an attribute on the character class 'FlashState' and we have a nested timer that turns it on and off every .1 seconds.  Or we could have a counter and count the time in the render method.  I guess the counter would use fewer resources but it's less appealing code-design wise.. For now let's go with not invincible.  

The Timer.Task needs to be cancelled before you can call it again, but that's fine it, it actually looks better than if the flashes were getting overlayed on top of each other.  (I guess)  Also the setShader method is apparently heavy and meshes are recommended, but I'm not sure how to go about creating a mesh for the sprite..  Something to look into when we get closer to the optimization phase

And here's the video of our progress!  Yep.. the trees are flashing.. because they are easier to see than our little stick man..