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..

Parallax Background + Animations

What's up?

Not much, just working on getting the parallax background system set up.  BlazBlue's 3d rendered backgrounds are a bit beyond me right now.  In place of that we have 4 layers of background moving by at different speeds.  

Here are the current WIPs:

Sky

Mountains, far bg 

Trees, close bg (out of order here ^^;)

Foreground

Ultra foreground

Can't you just drop the images in and move on?

Well we can but the background images will get pretty long so we have to slice them up into pieces.  Then we have to load those pieces in when they're needed.  Right now we aren't worrying about only loading things near the character, but later if we need to then having the backgrounds already sliced up will be a big help.

Aren't static images too boring?

Yes absolutely they are, which is the other reason that slices will help.  The plan is to drop some animation sprites on top of those slices.  Also right now seems like a great time to take care of some image sizing issues.  Right now we are manually moving all kinds of images so that they are in the right spot, and that just won't do!!!  Not at all sir!

Here everything is being manually moved by an offset value like -40, -240.  And the pictures are being scaled by some eyeballed value of .8 or something.  Yuck. Yuck yuck yuck.  bgLayerSprite[] is the array holding the background images.  We'll change that to an arrayList of 

Before we start to figure out how to do animations, let's figure out how to properly offset and scale these images so we don't need any eyeballed offsets.

*30 minutes later*

Argh..hm..

What's the issue?

Well the code has gotten pretty messy by now with all those different cameras running around.  The parallax camera is 3 different matrix projections, and we also have our game camera, and there's the tiledmap display as well as the hud camera.. I'm not sure where our 'viewing' camera has gone, and with all of the projection matrixes and camera.combined's, I'm lost!  Need to understand how the cameras are working a little better.  ^^;

Hmm what is the difference between a viewport and a camera?

http://gamedev.stackexchange.com/questions/75991/camera-vs-viewport  

This tells us that a viewport is like a TV screen and a camera is the tool used to make the movie.  So unlike real life cameras which are constantly recording something, the cameras in programming are blank unless we put something in front of it.   Umm..

*Literally days later* 

Man.. one thing leads to another which leads to another and so on until we've built a country and annexed a small landhold and angered the neighboring Steward, causing him to cut off our vital supply of fine cloths and spices, all because we were trying to clean out a dusty cupboard.  And here's a git repository: https://github.com/jaymefosa/NightmareEscape

 In the end we finally got the parallax scrolling to be as automated as possible:

We just need to change the (.1f, 1) to a .5f or .9f to bring it closer to the camera

- game.batch.setProjectionMatrix(camera.calculateParallaxMatrix(.1f, 1));  
- bgLayerFarAtlas.findRegions("bg").get(i).getRegionWidth() * .1f)) 

What were you doing again?

I've been mulling over how to implement background animations.  I think we'll go with a BackgroundAnimationController class which will be responsible for holding an array of 'near' animations.  We'll play those ones on their respective timers.  If the animation is going constantly it wouldn't be as cool as if it stopped and started sometimes right?

Then each animation sprite will just have its position set similarly to the above parallax offsets.  This method wasn't satisfying because that means  we'll need to know the local position of the animation on its respective background.  That is totally not satisfying.  Not at all.  Horsefist.  

Also I wanted to do some background deforming animations and this method doesn't do much to aid that.  At least this method will include reading an XML file so that we can add animations without having to change the source code.  

Here's a gif of what we're going for.  Just a nice small test case to get all automated and ready for the creative floodgates to be unleashed!! (It's a little bigger before uploading to blogger)  Can you see it?  The little smoke rising from the house near the right rock?  Isn't it beautiful? <3_<3

I gotta say.. seeing even this much really whets the appetite for terrain deforming animations.  Let's just say that we'll plan to have terrain deformed animations actually just be a regular animation, and we will transfer any of the mountains or whatever that would be moving to an animation sprite.  Boom.  Bam. Done.

Here is our smoke animation and timer:  

Lots of contrived values but we'll change it to be an automated XML reading system.  Well we spent about 4 days working on that so it's time for a video update!




Pardon the ridiculous quality, still trying to figure out how to make decent videos @_@

Also this should go without saying: any comments, critical or otherwise, about the art or programming are more than welcome.  Fire away~!

Bottles bottles everywhere

How did it go today?

Pretty good!  I had a minor meltdown when trying to change the bottle class sprite to our animated guy.  A lot of the automation that exists isn't needed for the bottle since it's very simple which also meant a lot of manually finding the right values.  

On the art side we got a couple new prototype versions for bottles spinning, breaking, and the hit impact effect.  

via GIPHY

via GIPHY

Looks good, how do they look in the game?

Not bad!  It's satisfying to hear the crash and see the little flash of light.  It's hard to hit the bottles so it's more satisfying to finally get one.  Right now all the bottle breaking sounds are the same. 'Crash Crash Crash' regardless of whether it hits the ground or we break it.  Maybe if we make the bottle sound quieter when it's farther away, or hits the ground, we'll be even happier to break it.

Video soon to follow!

What's next?

The project has been running from one big system to the next without trying to work from some grand plan or design.  At some point we'll need to redesign the code.  Probably that some point should come before the 60+ list of features still waiting to be implemented.

For now we'll continue hammering out the features needed to solidify the core game play experience.

• Character animations
• Character struck reaction
• Hud UI elements
• Background animations
• Combo hit system
• Sounds sounds sounds!

And many others.  Later let's look at those animation effects in detail because the Blaz Blue 3 sprites are exceptionally helpful references!

Hello World

Writing a first post is tough. There are so many questions with vague answers. "What kind of tone should I use?" "Who is my audience?" "How much should I talk about in a post?"

That is actually exactly perfectly in line with the reason this blog exists. This blog exists to show the struggle and journey of one person trying to create a game. So I guess we are on the right track already. Showing the struggle. I'm not a professional programmer and I'm not a professional artist. I can't pretend to offer the best solutions for either of those fields. I'm just one person trying to stumble through a dark room lined with traps and sharp, pointy, objects, grasping for a light switch.


So where are we in our quest to make a game? What kind of game are we making? When can we play the game?

Where are we?

Well we are about here: 

Combined with here:

What is that supposed to be?

That is supposed to be a cross between Megaman and BlazBlue.  Well, it's supposed to be a precursor to that game.  This first game is called 'Bottle Smasher.'  We take the role of a heroine trying to learn the ultimate martial arts technique from a cranky old master who just wants to be left alone.  He tries to throw bottles at her but with our help, she will smash them all and learn the secret.  

The idea is to release it for free on mobile with some hopefully not so annoying ads.  It's currently being done in Android studio with LibGDX.  It's just, I can't get over how tiny the graphics look on mobile.  I've definitely got a PC release in the back of my head just so everything can be seen more clearly.

Oh right okay, when can we play?

I have no idea.  There is just so much stuff to do.  So much animating, so much programming.  There will be lots and lots of content to blog about! The good news is that recently I've stopped working at my ESL job in Korea so I have a mountain of time.  The bad news is.. well. Hm. No income, moving, etc. 

Can you teach me how to draw or how to program?

You know that saying 'The blind leading the blind'?  Yeah.. we would definitely fall into a pit.  This blog is more for entertainment purposes than educational ones.  I'll definitely point out as many resources as I can though!

How often will you update?

Ho ho ho.. no way I'm falling for that one.  I promise to try to update frequently.  If you're looking for quick fixes on how the journey is progressing feel free to watch my art page on Facebook: https://www.facebook.com/FosaArt/

 

Thanks for reading and I hope it will be interesting!