Robo-Ninja gets a makeover

Thanks to Chris Hildenbrand, who made the amazing artwork for Anguna, Robo-Ninja is getting a makeover! Here's his new look:

Here's a video clip of just a few of his new animations, which I'm still tweaking to get the timings/transitions looking correct.

Thanks, Chris!

Trippy video

That picture yesterday didn't capture how weird this is. So I decided to post a video tonight....

I'm currently working on using that funky weirdness in the background of the new dimension, to make it look nice and weird. Which means I still have to come up with a slightly different interesting transition to the area. 

Shaders (getting trippy here)

So for this next area of Robo-Ninja, I've been trying to figure out how to do some crazy wavy-screen effect as Robo-Ninja teleports into the new dimension. Suddenly, my lack of knowledge about modern computer graphics really shows up. The Gameboy Advance and DS used their own proprietary 2d graphics systems, and so far I've just been using some high-level 2d libraries in libGdx, that protect me from having to learn much about the actual openGL stuff that's actually going on.

But to do this crazy effect, it looks like I'm going to have to use shaders. So I'm going to have to learn a little bit. Thanks to some nice folks on the libGdx IRC channel, I found a page with some nice example code of something vaguely like what I'm trying to do. Playing around with that example code, I've turned Robo-Ninja into a serious trip-fest:

So...that's weird. Not exactly what I'm going for, but I think I can use that to get pointed in the right direction of what I want for the transition. The real question at this point is, how much time do I spend really learning this stuff properly (the syntax of the shader language isn't complicated, but to really understand it, I need to have a much better understanding of 3d graphics than I do, which could take quite a bit of time and work to really get there), vs just barely understanding it enough to achieve the effects I'm looking for (which is pretty likely in this case, since it's just for this one visual transition, and not crucial to the game itself). We'll see what happens....

Final Robo-Ninja tileset

I'm finally sitting down and building the file world graphics tileset for Robo-Ninja. The end is in sight!  I'm using this simple tileset from OpenGameArt. For each tileset, I usually have to spend some time massaging it to get it to work. I need my graphics to be in 16x16 tiles. But, like this tileset, often the source material isn't on any sort of grid, so I have to do some work to shove it into a grid. Then, to prevent any blurring of neighboring tiles during any possible scaling, I run it through a gimp script that converts it into 18x18 tiles, where each tile has a duplicated edge on each outside border. So any neighboring pixels for scaling are just the same as the original pixel.

Then I have to import it into my tile editor (Tiled), and then set up map properties (such as which tiles are spikes, etc), pick out a backdrop image for the tileset, and THEN can finally start making maps with it.

With this new world area, I decided I needed something different than normal, though. I've nearly exhausted all the ideas I have for obstacles and tricky jumps in the standard Robo-Ninja mechanics. So I decided that for this area, Robo-Ninja will have entered a strange alternate dimension. A dimension where time doesn't flow normally. In fact, time speeds up the longer you stay alive in it. So the challenge of these next rooms is going to be that the game is going to start playing faster and faster as you progress.

Should be interesting.....

Jeopardy

For an upcoming church business meeting, we decided on playing a game of Jeopardy. Now at our church business meetings, we have a history of going all-out with some sort of gameshow-type theme. Last year we played Hollywood Squares, with a complete giant 3-story box to make it work:

So for this years' Jeopardy game, I knew we couldn't do it half-heartedly. I spent awhile searching for good Jeopardy Board-making tools online, but I didn't really like any of them. And what we REALLY wanted to do was also build a podium with score screens for each player, with their name and score, like the real game.

So I decided to write some code to slap it all together and make it happen. The main board is just a single-page html/javascript page, with some json data for the questions and answers. Then I set up another page (to be operated by someone backstage) with buttons for modifying the player scores. Then another page (one for each player) that just shows their name and score, and refreshes itself every second, to stay in sync with the scorekeeping tool:

If you are interested in using this, you can grab the source from my bitbucket repo: https://bitbucket.org/gauauu/jeopardy 

At this point, I haven't made it very generic or user-friendly. Use it at your own peril.

Stuck on silliness

Last night I got stuck on a silly problem. I was trying to add an array of item colors before my graphics definitions:

ItemColors ;This is the new array
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44
        .byte #$44

ItemGfx
        .byte #%00000000;--
None
        .byte #%00000000;--
        .byte #%00000000;--
        .byte #%00000000;--
        .byte #%00000000;--
        .byte #%00000000;--
        .byte #%00000000;--
        .byte #%00000000;--
        .byte #%00000000;--
KeyIcon
        .byte #%00001100;--
        .byte #%00001000;--
        .byte #%00001100;--
        .byte #%00001000;--
        .byte #%00001000;--
        .byte #%00011100;--
        .byte #%00010100;--
        .byte #%00011100;--

...etc

The ItemGfx array was already there, with many more item graphic definitions following it. Everything worked fine. But when I added that ItemColors array, suddenly my items wouldn't appear anymore once the enemies were killed in a room! It wasn't even referencing the ItemColors array anywhere. And I was looking up ItemGfx by the label, so it shouldn't have mattered if it was offset by a few bytes. I even fired up the debugger to verify -- the item graphics were still being properly loaded.  I removed the array just to double check, and it started working again. I spent a good hour and a half stepping through on Stella's incredible debugger trying to figure out what was going on.

Turns out, it was a bug in a different section of code. Thanks to a suggestion from yllawwally, I'm storing a position for each room layout that things (items) can spawn in. That gets specified in an array immediately after the itemGfx arrays:

SafeSpawnX
    .byte #100
    .byte #100
SafeSpawnY
    .byte #30
    .byte #30


Well, it turns out that my code to read those spawn arrays was buggy, and I never noticed. It wasn't actually reading those arrays, but instead some unintended byte at some random address that happened to be in the middle of the itemGfx array (not really "random", because it was the same byte every time, but random in the sense that the selection was made by the nature of the bug, not on purpose). I just lucked out that it happened to be a reasonable value that wasn't so far off from my hardcoded safe value, so I never noticed. Until I inserted a few more bytes before, meaning I was now hitting a new "random" value, which didn't have the magic coincidence of working.


Sheesh.


Anyway, I'm back on track now. I'm currently sidetracked playing with trying to move some code to bank 2, and reducing the amount of space my code takes up -- I realized I only have about 700 bytes of space left in bank 1, and I have a lot more I'm hoping to put there. At the current rate, I won't have space for the game as designed, unless I manage to move a lot to bank 2 and trim things up a bit. Or switch and use a different bankswitching mechanism.  We'll see.