Wednesday, November 27, 2013

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

Friday, November 15, 2013

Pebble New SDK

Well, go figure.

A week after I finish writing my medsAlarm, Pebble releases their new version of their SDK. Which isn't backwards compatible. And has new better ways of doing everything that I'm doing. I guess I need to rework a number of the bits of functionality in the app now.

Tuesday, November 5, 2013

Pebble MedsAlarm

So I previously mentioned the Pebble Alarm Clock App that I've been working on. I just came here to say that I think it's finally finished. If anyone is interested in helping me test it, let me know, as it's probably full of all sorts of bugs.

And just to clarify, MedsAlarm (my terrible name for it), is an alarm clock app for pebble that lets you manage up to 10 "complex" alarms. The alarms are all configured using a simple web interface on the server component. Each has a name, and can be set to go off either at a certain time each day, or repeat every X amount of time throughout the day, and each alarm can have a different "snooze time" setting. The watch syncs (via httPebble) with the server app when it is available (But attempts to function independently when it isn't, so it can be used in situations where cell phones aren't allowed). In the evening you can optionally press a button to put the watch "to sleep" so that repeating alarms will not continue to go off through the night, until you awaken the watch in the morning.

When no alarm is going off, the watch app shows the current date and time, as well an indicator telling what the next alarm to go off will be, and how long until it goes off.

Anyway, again, let me know if anyone is interested in helping test (or using the watch app once it's fully tested and any remaining bugs are sorted out)