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.

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.

LibGDX

Ok, I'm trying again to talk about LibGDX.

When I got it in my head that I was going to make a new game, I wanted to make my life easy, and actually have hope of getting it done in some reasonable amount of time, which meant using an existing game framework/library.

On Anguna, it was a lot of fun building everything from scratch, but I spent A LOT of time just doing the basics: animating sprites, building characters out of multiple sprites, getting backgrounds to scroll properly, etc.  On an device like the GBA, learning the weird tricks to do all that was a lot of fun. This time, on a modern smartphone platform, I just wanted to spend my time focusing on the game.

So I started evaluating different tools.  Unity and Marmalade (which used to be called Airplay, which I originally started using for the iPhone port of Anguna) are the two that seem to have the most use, but are also a bit expensive these days for a hobby project that might never get finished.

So then I stumbled upon LibGDX. It's a free open-source framework. You write your code in Java, and then it can be deployed to Android, Desktop, Html5, and iOS (using RoboVM). While Java has its warts, it's easier to be productive in than straight C or C++, which are often the alternatives. And doing my daily development on the JVM is really nice, as I've still never found a better platform for debugging code. Being able to hot-swap code during a debug session, then drop back to the stack frame and re-test makes some things SO much easier to get right.

Some other things I liked about LibGDX:

- It's open source, and has a pretty friendly and decent community. I like the idea of open source, particulary for hobby projects. But some open source communities and personalities are downright obnoxious. This one seems to be pretty cool. And they do a decent job of documentation.

- There's good support for existing tools (ie loaders for Tiled and other map editors), so I don't have to spend as long figuring out how to massage my assets to get them into the game.

- Like many of these other platforms, it is set up for 3d support, but has a pretty easy 2d api for people like me that just want to make a simple 2d game without worrying about 3d graphics math.

- Although most of the projects in gallery look pretty janky and homemade (like mine!), there are a few examples (Ingress) of "real" games that are using it. So at least it's mature enough for a real game.

So now that I've decided to use it for my project, I haven't really hit too many warts yet. That's a good sign. I ran into one place where the default Tiled map loader was pretty inefficient for large but sparse maps. Being open source, that was easy to fix. Overall, though, I've been pretty happy. It gets out of the way and lets me write my game.

Blogger app for Android (don't use it!)

Hmm, so I started typing a long post about LibGDX, using the Blogger android app. That was a mistake. While typing, I toggled over to a web browser to check something. When I came back, it had deleted my entire post. Turns out that wasn't a one-time thing, that's just how it works. I guess whoever at Google made the thing didn't read their own document about  the Android Lifecycle. Ah well.  Maybe I'll try again tomorrow.

Ramps are weird

So I've got most of the real core of Robo-Ninja complete. Not that that means I'm anywhere near complete. The basic core (map loading, characters moving and animating, collisions, etc) is the easy (and fun) part. The details are what takes all the time.

Anyway, after getting the basics of collisions working, I suddenly decided (for reasons I haven't really figured out) that I needed to add ramps. I wish I would have been smart enough to think of that earlier, as my design for collisions didn't really take ramps into account. And ramps are weird.

Overall, wall collisions are pretty easy, although slightly harder in a game like Robo-Ninja than they were in Anguna. In Anguna, you just check for collisions, and revert the character's position if he collided with a wall.  There were a few other gotchas, (type of wall, since you can sometimes walk over water. Or checking vertical collisions separate from horizontal so you could "slide" diagonally across a wall), but it was easy.  In Robo-Ninja, vertical collisions need to work similarly (walls above you will suddenly stop any upward velocity. Walls below will stop downward velocity). But horizontal collisions will make your guy suddenly switch directions.

Now ramps. Now we've got a collision that, being a diagonal ramp, is suddenly a vertical AND horizontal collision at the same time. And it should not only change your vertical velocity (stopping downward momentum), but also your position (as it needs to nudge you up vertically if you are moving left, but not send you jumping up in the air). And the tiny magic intersection tile between ramp tiles is really a normal tile. Which meant if Robo-Ninja moved a tiny bit too far forward in each frame, he'd collide with THAT tile instead of the actual ramp tile, and decide to turn around and run the other way.

I can't tell you how many times I kept bouncing off that highlighted tile until I  stopped being dumb and fixed my code.

Anyway, none of that should actually be hard. But it would have been a whole lot easier if I had decided I wanted ramps BEFORE implementing the rest of my collision code, so I would have actually designed with that in mind. Oh well. It works now.

Now I'm on to items/powerups, and the UI associated with them.

An unexpected turn of events

So one thing I didn't count on is my 5-year old son become interested in the process of making this game.

The other day while he was bored, I was letting him play with my phone, and he discovered a new game in the games folder, Robo-Ninja. And even though there were only 2 short levels, and they were pretty hard, he loved it.

This morning he wanted to play it again, and asked why it was so short (he didn't realize it was a game I was in the process of making). So I explained that I was making it, and could make some more levels for him. (and some easier ones). Then I had the realization that the level editor was easy enough that HE could make levels. That REALLY got him excited.

So we spent a good while this morning letting him design some levels. They're a bit...um...random. But he loved it. And I loved helping him do it.

In case you can't tell, that's supposed to be a forest in the top-half of the screen.

But now I have a dilemma. He's going to want to play his version on my phone. But I'm going to want my version on there to show off, mess with, etc. So I ended up adding a menu item in the game to let you choose between Aaron's version and the real version.

Eventually, if I ever get close to finishing this thing, I'll probably have to pull his content out (there's no way I can distribute a game with the Ninjago Theme Song as background music, which is the case with his levels). But it's pretty fun to have my son excited about the process right now.

That may end up slowing down my development a bit (it did today!), but realistically, if it's between having fun doing this with my son and actually finishing, I'll take the former any day.

Starting a new game

Well, I'm finally starting a new game.

Actually, I've been working on it off and on for a couple months now, but I've been hesitant to talk about it, as I'm not sure I'm mentally committed to finishing it.  I'm still not sure I'm ever going to finish it, but I have trouble not talking about things. So despite the fact that I hate yapping about things that I'm not sure I'll ever finish, here goes.

Like Anguna, I'm attempting to make a game that I want to play. (See my discussion of where I failed to achieve that mark for Anguna)

So I'm working on a cheesy little game called "Robo-Ninja." The main character, is in fact, a robot ninja.

So what I really want to make, a large metroidvania-style adventure game, generally requires better input mechanisms than a phone provides. There's a reason there's 8 million tap-to-jump games (Like The Impossible Game, which did it the best, and Wind Up Knight, which got tons of attention but was ultimately incredibly boring). Like I've talked about on this blog before, I really love the exploration part of a simple but large 2d world. So I started thinking about ways to make a metroidvania game work on a phone.

I really also like incredibly frustrating games where you die. A Lot.  (See the Impossible Game, above). I was completely blown away by VVVVVV, which is both incredibly frustrating AND a metroidvania-style game.

I also have to limit the scope of the game. I don't want to spend 3 years working on this like I did Anguna.

So I set out to combine all of those, and decided on the gimmick: a metroidvania game where the only controls are the crazy tapping-to-jump mechanism.   (well, to jump or do an alternative action depending on what items you have -- I was picturing some sort of Ninja dude as I was brainstorming), You could also tap on a corner to cycle through your inventory of items. To make it harder, your dude never stops running forward. Except when he hits a wall, then he turns around and runs the other way. (thus the Robot part, because he's dumb and just runs) So you have to work your way through a frustrating world of pits and spikes and frustrating timing, exploring and choosing routes by forcing your guy to bounce off the right walls or jump through the right holes.

Here's an example of me falling in a pit, about to die. I do that a lot in my tests.

So far, it's been a lot of fun. I had to pick a framework/game engine (LibGDX, which I'll talk about some other time), find art resources (there's quite a bit of free art out there, the hard part was finding enough that matched up to get some sort of consistent style to the game), figure out what tools I wanted to use (Tiled for mapping, I think), and then start coding!

Now that I've finally broken down and admitted I'm working on this, I'll plan on posting more thoughts about the game as it progresses (or stalls out and dies if I get bored).

Although, for now, I will say that my 2 testing levels are hard enough to frustrate me as I test it. That's a good sign in my book. ;-)