Missle Tow!

This week's game is Missle Tow! GET IT?? Okay, so I have to apologize for that joke, and I also have to apologize for posting this so late! (Monday at 2:30am doesn't quite count as Sunday).

Whoo boy, I wish I had started this before Friday. You'll definitely be able to see that there are a lot of places where some extra love could have benefited this game. Like adding level boundaries. Or better handling what happens to your character when it flies into a wall:

(The answer, by the way, is that you go careening into the air. Don't worry though - jumping will reset your movement pretty reliably).

I can tell when I'm really into the game I'm making when I find myself spending a lot of time taking screenshots of it, and I took a lot of screenshots of Missle Tow. I also spent a lot of time getting the character and the missiles to feel just right (and I didn't even quite get it where I want, either), and I really like the way the two movement systems interact. The player makes super sharp turns, and the missiles can turn on a dime too, but their movement is way more fluid. Makes for some pretty screenshots:

I really pushed for there to be fun ways to interact with the missiles. Getting chased by them was only so engaging, and I always knew I wanted to emulate that moment in movies when the ace pilot shakes the heat-seeking missiles by fooling them into a wall or canyonside... or into the enemy's face. So I always knew that I was going to be having the players bring the missiles to goal-zones. The hurdle-barriers came along when I realized it was really fun to be able to jump through narrow gaps with the missles right behind you.

Actually, I lied in that earlier paragraph (Blogs written at 2:30am tend to become a bit unhinged), my very first idea for Missile Tow was that you would just be this arrow that can turn at high speeds, but only by jumping. I really wanted that dichotomy of movement, where you get someting for giving up something else. In this case, you give up maneuverability for speed, and you need to time your jumps for just when you need to turn, so there was a nice little game there too. That's the system at the heart of Missle Tow, and I figured the rest out from there once I saw how it was actually working in Unity.

Speaking of Unity, you might notice that I've finally moved into Unity 5.1 for these game-a-weeks. And that represented its own hurdles. For one thing, you may notice a little development console appear on your screen when you destroy the goals. This apparently only appears for people who have the Unity editor installed on their machines, and there's also apparently nothing I can do to disable it. I may have that wrong. I did the research at 2:00am.

Play Missle Tow here!


Menu music by CynicMusic. Level music by JobroMedia. Both songs used under this license.

P.S. I swear that that saxophone track seemed like the most fitting music I had while I was making this. I apologize for any bleeding ears.

Catch and Release

(Skip to the game)

There's something interesting that Mark Rosewater mentioned in his podcast about things every game needs (or maybe it was his podcast on designing for emotions, I can't remember). He said that a common pitfall of junior designers is to build a game which is interesting, but not fun. Maybe the mechanics work together in an novel way, but the player isn't necessarily being engaged on a deeper, emotional level.

Catch and Release, and a lot of the games here, fall into that category, I think. Now, of course it's going to be difficult to emotionally engage someone when you're dealing with just rough primitive shapes and audio you've found online, but that doesn't make it impossible. I think both Shoot the Moons and Bolt had an aesthetic appeal which engaged a certain emotion.

In Catch and Release, I tried to polish up the experimental design I submitted here two weeks ago. I only made three levels, but I think I got the mechanics working the way that I wanted them to work. What I wanted to find out was how much design space would there be if you took this idea and turned it into a AAA production. My verdict is I'd still love to make this into a larger game. A thief in a medieval fantasy setting would be a great basic concept to spring from, and adding a third dimension and a second dagger really increases the applications of the teleportation gameplay.

Something you can do in this game is drop a dagger to block the beam of a laser, which isn't something I had though of doing initially. Having incentive to leave a dagger behind really makes later parts of the level very interesting. At any point, you can teleport back to the dagger, so it makes traversal and backtracking kind of... cool? You can also choose to bring your dagger back to you at any time, but imagine what happens if the player maybe sticks the dagger into some sort of keyhole, or into the gears of a mechanism or magical contraption. The dagger has to stay put, or whatever trap or machine it's activating/deactivating will be free to do its thing. Might be an interesting way to present the player with risk. One one hand, you could complete the rest of this level with only one dagger. On the other hand, if you bring the second dagger to you, the machine that spits out golems will come to life, or the drawbridge separating you from the palace guard will fall, or the trap that fills this tomb with sand will activate...

Something which worries me about this concept is how much of your brain gets dedicated to tracking flying objects. It's already a little confusing to do a rapid thow-teleport-throw. Imagine how disorienting it gets when there's two daggers you have to be mindful of. Maybe you should only be able to teleport to a dagger if it's been dropped, or if it's stuck in a wall. Mid-air daggers are off-limits.

Anyway, being able to chuck a blue dot behind an enemy, teleport to that dot, then slay the enemy with that blue dot, is the central idea of this mechanic, and (as you can see from these last four lovely pictures) you can do that in Catch and Release. Play it here!

Menu Music by CynicMusic, Game Music by Kerri Coombs, and switch sound effect by Nenad Simic, all used under this license.

Wedding trumps the deadline!

Whoa! I'm really late on this week's game! It's already Monday, and I've got nothing to show! That's very un-like me - what's the deal?

Well, I knew in advance that I would be busy this weekend (and some of the days leading up to it) attending a wedding! So I decided that I won't be making a game for this week, but will deliver on-time for next week. Sorry!

An Experiment in Throwing Magic Darts

(Skip to the game)

So, this week's submission is another prototype... not a proper full game. I can't tell if I'm slowing down, trying to do too-large projects, or not managing my time well enough. Probably all three, to some degree. Anyway, I'm hopeful that, like the last experiment, this week's submission turns into one of the more unique games I make in this blog.

 

This game is building off of an idea I have for a much larger game: In a fantasy setting, the player controls a thief in possession of two magic daggers. The daggers can teleport the thief to their position, and the daggers can also teleport back to the thief's hands. The thief can drop and throw his daggers in addition to using them to fight enemies.

This creates a lot of interesting combat and traversal puzzles. When fighting a heavily armed enemy, I can drop a dagger, circle my foe until the dagger is behind him, then teleport behind the enemy and attack. When scaling a wall, I can throw one dagger so that it embeds itself in a wooden surface, then teleport up to that dagger, cling to it, and throw the second dagger over the wall.

I consider that game a distant fantasy, but maybe I can make a sort of minimized proof of concept here on this blog. Anyway, if you're interested in seeing the prototype, it's right here.

Background music by Kerri Coombs, Switch sound effect by Nenad Simic, both under this license.

Shunt

(Skip to the game)

I did a lot of things I haven't done before (in this blog) for Shunt. I think beginnings and endings are the hardest part of any medium, and I was tired of the same-old infinite game that I've been doing (which is like telling a story with no beginning and no end). To that end, Shunt has both a real tutorial and a finite amount of game to play.

This game pretty clearly is a continuation of last week's experiment, but with a lot of improvements. I changed the movement system completely, gave the ship "arms," and put a little point light at the nose of the vessel so the player can get a better feel for how close they are to objects.

The goal of the game wasn't changing, I already knew I wanted it to be about shooting cubes across space into goal zones. And I already had that, so the only thing left to make was enemies. Shunt has interesting enemies, since they don't kill anything. There's no fail state for Shunt, and because of that I didn't bother putting in a pause screen or a restart button (I probably should have for convenience, but hey). Still, the enemies feel important because their attacks can really mess you up if you let them. Which is part of why it feels so good to blow them up.

If you want to let me know what you think of Shunt, or other games on this blog, you can tweet @JacobDMooney, or leave a comment below! In the meantime, Play Shunt!


Menu music is by p0ss and is used under this license.

Game music is by CynicMusic and is used under this license.

P.S. The web player for this week says "Week 11," even though it's definitely week 12. Ignore that.

An experiment in space golf

So, today's game is less a game and more of an experiment. I tried out a movement system for flying where you control two thrusters on either side of your ship. While I liked what ended up happening, I struggled to really find the time during the week to come up with a real game to build around it.

Over the weekend I sort of settled on this odd golf/soccer objective of shooting these big floaty game objects into a goal. You CAN still play it (here) if you'd like to see how that works out. I tried to put at least a few bells on it before deciding to end for the week.

Who knows though, I might decide to make this into a full game for next week.

Background music is by CynicMusic, licensed under this license

Overrun

(Want to skip to the game? Click right here.)

Overrun started off well enough, I had an idea for a cool movement system, and I wrote the code for that movement in a really short amount of time at a really early point in the week. As I kept with it though, there were a lot of issues that I would have had time to fix if I'd managed my time a bit better. (I'm still getting used to having a real 9-to-5 again.)

Still, though, Overrun ended up okay:

The biggest issue is with enemies. If they spawn in just the right place, they'll twist out of alignment with the level as they turn to face the core circle, making them impossible to hit. Other than that, there's just not enough fun to Overrun. Some of my ideas to improve that include making stationary, remote circles which heal the core when you move to them, or implementing a points system that rewards you for killing enemies farther away from your core.

When I posted Bolt, I mentioned that one sign that a game is good is that the screenshots look very exciting. In any still shot of Overrun you take, it's practically impossible to tell just what exactly is happening. In part that's just the nature of how you move, but it's also because I think the action in Overrun can be sold better, visually. At the very least, though, it makes for some interesting modern art when you zoom in really close:

Anyway, it's still an interesting movement system, and if I could figure out the problems with the enemy AI it would help me out in a lot of future games.

Menu music by: SonarTuning
Game music by: CynicMusic
all under this license

Play Overrun here!