Wednesday, January 8, 2014

Back-story

My friend left a comment today asking some good questions about the story of Robo-Ninja. "Have you given any thought to the all-important backstory?" he asks. "Is the protagonist a ninja who became a robot, or a robot who trained as a ninja? And what does Robo-Ninja hope to achieve?"

So here's my rough draft. Who knows how much of this will change by the end (if there ever is an end!)  Like Anguna, I'm purposely going for a short and cheesy story:

One day, Professor Treeblot was finally putting his finishing touches on Robo-Ninja, his newest invention, a robotic ninja designed to defend the world from Evil Bad Guys.  But to his dismay, as he was finishing, the Evil Dr (insert name here) came, kidnapped Prof Treeblot, and scattered all of Robo-Ninja's ability modules throughout the land. Without these modules, Robo-Ninja could do nothing more than run forward.  Now Robo-Ninja must travel the land to search for and recover his lost abilities, so that he will be powerful enough to hunt down and defeat Dr (?) and save Professor Treeblot.

So you start the game with the ability to DO NOTHING AT ALL. Robo-Ninja just runs, you can't even control him. Luckily you pretty quickly collide with and equip your first ability module, the "Jump Servos", which let you jump.

So that's pretty much it. You search the world for your abilities, then use them to go find and defeat Dr (whatever).  Not much to it. And it only vaguely helps make sense of what you're doing in the game. But hey, like I said, I enjoy purposely making the story lame. (And yet that's what got the most complaints in Anguna) Oh well.

And if anyone has cool suggestions for the Evil Dr's name, I'm all ears. I'm shooting for something almost over-the-top silly for his name.

Oh, and my friend Rob just sent me some awesome icons he made for abilities, so that's taken care of. Thanks Rob!

Tuesday, January 7, 2014

Sliding and regressions

Well, as it usually goes, I didn't get much done on the game during the holidays. Although I did a little more than I feared.

Mainly, I finished the first of Robo-Ninja's powerups: the slide ability. He can now slide through narrow passages.  This forced me to flesh out my implementation of ability powerups, but my rough design was pretty close to what it needed to be, so this was pretty straight-forward. I ran into one hiccup where if you switched from "slide" mode to "jump" mode while still sliding, you'd never stop sliding, and could jump around while still sliding.  That was amusing.

The harder part was making the sliding not look stupid. I figured I'd do like mega-man and have a single-frame animation for sliding, and have him slide along the ground. Unfortunately, unlike mega-man, it looked ridiculous. So I'm playing with it to hopefully make it look a little better.
Mega-man makes this look awesome. Robo-Ninja makes it look ridiculous.


The other thing I'm running into is regressions of earlier bugs. My work on code for abilities suddenly threw off my jumping physics that I spent forever tweaking. Turns out I was now properly calling an update function that I had forgotten to ever call before. And that update function had left-over code that borked my jumping. Oops.

And I had originally added a delay that forced you to see the "new item acquired" screen before accidentally tapping and dismissing it as soon as it appeared. But somehow that stopped working as well. (The problem with it was that my delay timer was declared as an int, but I kept adding fractional (float) seconds to it. Which of course, got rounded away every time, so it never really incremented.) I fixed it now, but I'm not really sure how it actually ever worked right.

So now my son will be happy -- he bugs me every day or two to hurry up and add more abilities to the game. Really, he just wants me to add the "jet-pack" item that you won't get until the very end of the game. That way he can fly over spikes and never die. Maybe I'll have to do that one next....

Monday, December 23, 2013

And now I need icons....

Well, the time has now come that I've been dreading. I need to figure out how to come up with some icons to represent each of Robo-Ninja's powerup abilities. I can probably find some free art resources for the general template of these icons, but I'll still need to do a bunch of graphics work to make the icons themselves. And come up with a consistent look between them.

This is going to get ugly.

So if anyone out there feels inspired to help me make some icons, let me know.

Saturday, December 21, 2013

And sometimes things are easy.

Occasionally it turns out that my code design is actually decent, which means that on those rare occasions, adding things is easy.

Halfway through my cave level, I decided it needed boulders dropping from a hole in the ceiling that you had to dodge (by timing jumps when they go by). I didn't have any code in place yet for moving obstacles, although I had vague ideas about eventually including them, so luckily I had at least designed for the possibility.



Turned out, it was REALLY easy. It took about 15 minutes to find, download, and edit a Creative-Commons licensed boulder sprite. About 20 minutes to write the code for the boulder itself. Then about 15 minutes to write the code for initializing the boulders from the tile-editor level definition. BAM, the whole feature was working in less than an hour.

That felt good, after wasting so long reworking my collision code the other night.

Next I'll work on the 2nd cave room, which includes the first major ability powerup item. So I'll have to write the code to handle the UI for switching abilities. And I need to hurry and do that, because Aaron has been pestering me all day to hurry up and add a new ability. Well, when he's not running around the house jumping over things and pretending to be Robo-Ninja.

Friday, December 20, 2013

And this is why I do level design early.

So I started on a harder cave level, with some pretty hard and messy jumps and collisions.

And realized my collision code wasn't good enough. 

I had originally gone for an overly simple collision model, which I hoped would be good enough: check for collisions at each corner of Robo-Ninja, and deal with whichever is the "most important" collision.  Well, as Robo-Ninja is taller than a single 16x16 "block", I was running into instances where the head would go above the block without colliding, then the feet would collide with the block from beneath, and all sorts of brokenness would ensue.  This also got me into trouble when I put ramps too close to other collisions, as it would get confused about what is colliding where.

So tonight I overhauled and reworked the collision system. Which, once again, leads me to my previous statement: Ramps are weird. It only took me about 30 minutes to get the basic collisions working with my new model (checking multiple points around the perimeter of the bounding box, processing each point's collision separately).

Then another 2 hours to get ramps working. Now I'm tired. The good news is that the ramps work more smoothly than before. Previously, going down a ramp, you'd run too far ahead, your feet would leave the ground, then you'd bounce down a bit, then run too far ahead again, and so forth. Which was bad, because it made it really hard to jump while running down a ramp. (you had to time it perfectly when your feet hit the ground). Now, your feet lock to the ramp on the way down. 

So now I can continue on with my hard cave level. It took me about 25 tries to get through it while testing. My son was extremely excited about the existence of this cave level, but was rather unhappy that it was so hard.....

Wednesday, December 18, 2013

Working on some early level design

So I decided to put the actual programming on pause at this point, and do some early level-design. Mainly because I don't actually enjoy the details of level design very much. I really enjoy drawing a big rough map of the world, and planning out the overall gameplay. But the details of each little level? It's tedious.

Which is weird because when I was a kid that dreamed of making video games, I loved drawing out each level in minute detail on paper. Now that just bores me. Maybe because when you are 8 years old and drawing levels, you don't have to pay attention to making them the appropriate difficulty level, and interesting to look at, at the same time.

Anyway, so I've started on the first couple of "real" levels/rooms in the game. The first is pretty simple, without many things that can kill you. The second is full of death. And I'm realizing it's going to take a lot of work to make the challenge level right for this game. I'm not yet good enough at my own game to know which jumps and arrangements are going to be hard, and which are going to be easy, and which are just impossible to get through. There's one spot that I had to put in a checkpoint/save-point just for testing, so I could play it over and over again just to see if there was any way to get through it (yes, there is. It's not easy though).

So I've got a couple of possibly-finished levels (out of about 50). But that's why I started now. If I finished all the programming, and just had level design to do, I'd get so bored. So I need to pace myself: work on a few levels, then go back to coding. Work on some levels, then back to coding.

My current plan is to make the levels up until the first major ability item, then actually add the UI code for managing items. Then I need to write the code for the minimap. Which, I learned from Anguna, is a giant pain.  Hopefully I'll be smarter in how I write it this time around.

I also found yet another bug with my ramp code. Robo-Ninja can't jump while running down a ramp. Because I depend on the game's gravity to lower you down the ramp, it thinks you are in a freefall, so it won't let you jump. Oops.


Monday, December 9, 2013

Silly Mistakes

So I'm realizing that with this project, I don't have as interesting things to talk about as I did with Anguna. Anything that takes more than 30 minutes to implement in Robo-Ninja is usually because I made a silly mistake, not because I have to do cool stuff to make it work.

Tonight I was working on handling the back button on the Android build.  I wanted it to pop up a simple exit-confirmation type of menu.  LibGDX provides a nice handler for catching the back button (see the docs and this post on Stack Overflow), and it was pretty easy to pop up the menu. Quitting the game or canceling the menu were both no problem, but I kept having trouble whenever I'd use the "Main Menu" button.

No, this is not the final visual design for the menu. Yes, that button says Robo-Nina.  Oops.

I could get it to take me back to the Main Menu without issue, but the next time I'd hit the back button, the menu wouldn't appear. I spent a good 30 minutes stepping through with the debugger before I figured out my mistake:

When I started the game over, I instantiated a new UI/menu overlay object that controls all the on-screen popups (the Hud object). My back button handler, which I didn't re-instantiate, was holding on to a reference to the old Hud, which wasn't being displayed anywhere. So the old Hud, off in limbo-land, was trying it's hardest to show me a menu, it's too bad I wasn't actually DRAWING the old Hud.


NES Anguna

Well, I had a little bit of time still, while Frankengraphics is finishing up her game Project Blue, to have a little downtime on Halcyon, s...