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

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!