The Perfect Cast

(New build is up here!)

Hi! I didn't have much time to code this week, but I did have enough time to unravel one of the last mysteries to smoothing out how this game plays.

See, having solved (for the most part) the issue of getting caught in the middle of long warp-wall loops, I thought I'd move on to the next most annoying thing that happens when you play: not warping when charging at a warp wall.

See, the secret to this issue is what happens when you hit a warp wall. In old builds, a ray is cast backwards from the player in the opposite direction of movement. I liked this because it felt exact and predictable. If you're just hairs away from hitting the opposite warp wall with your raycast though, it can look like you ought to have warped:

But, as you see, that raycast is nowhere near the warp wall we want to warp to. This results in frustrating moments where you feel like you ought to have warped but you don't.

The solution is to use a different method of warping. I've thought of two options, both of which work to varying degrees:

• Use a spherecast. Spherecasts work like "fat" raycasts, so they can be configured to be more or less forgiving as I deem fit.
• Still cast a ray, but use the orientation of the warp wall for the direction of our ray. In other words, always cast a ray which is perpendicular to the face we hit. This results in a lot of horizontal movement at times, but in exchange you will literally never hit a warp wall and not warp to another warp wall (assuming there is a second warp wall directly across from the first...)

This build uses the second method. See how you like it.

Charging-up noise is a sound by Javier Zumer, modified by me. Used under this license.

A behind the scenes improvement to charging, and a new visual aid for aiming.

(New build is up here!)

So, I decided to follow-up a relatively productive week with a relatively unproductive week. So it goes. And yet! This blog is absolutely doing its job when I'm motivated to at least accomplish something in lieu of just saying "Eh, one week without progress is okay."

I set out to do two things: a) Look into implementing a system which would predict where your charge would take you and project a trail showing you that path exactly and b) Change the charge code so that you automatically quit charging if you're up against a wall, instead of getting stuck there for a few incredibly annoying seconds.

The results?

A) That system would be very difficult to implement. At least for me, and for how this game is set up. I'll need to think more about how I can get that to happen. In the meantime, I'll project a line forward which grows as you charge your attack. It serves the same purpose (namely, to give the player a greater idea of where they're going) while perhaps not spelling everything out too much.

B) I can probably make the charge end if the player drops below a certain velocity, but that seemed... inelegant. I think the problem isn't that you sometimes get stuck against a wall - it's that you're stuck against a wall for far too long. Getting stuck after a full charge straight into an obstacle feels like a good consequence for poorly executing an attack. The real issue is that you charge for an amount of time equal to however long you hold down the charge button. This was capped at an upper limit of 3 seconds. After playing around, I found that you never actually needed to charge for longer than 1 second, so I brought it down to that number. The result should be far less frustrating.

Charge-up noise is by Javier Zumer under this license. It has been edited to fit the new charge time!

Control refinements!

(New build is up here)

Only two real changes this week, but I am excited about both of them. First, you can now click to begin your charge in addition to using the space bar and the right trigger (yes right trigger, not right bumper. I finally got around to doing that, too!). In addition to being able to charge with the mouse, the arrow will only follow the mouse if you are holding down the left-click. This makes aiming with the mouse feel a lot more purposeful and useful than before, where it was sort of haphazard and clumsy.

The other big change is that I've gotten to the bottom (sort of) of the issue which kept causing you to get stuck when charging through two nearby warp walls. It still happens occasionally (especially on level 6, which is always the main culprit) but it's a lot rarer now.

Charge-up noise is courtesy of Javier Zumer, under this license.

Turkey Day has come and gone

(New build up here)

Not a lot to add this week, since I didn't have a lot of time to spend on the game, what with there being turkey to eat, planes to catch, old friends to visit. It was a good week.

Game-wise, the only things I've changed is I've tightened trail renderers a bit. Now when objects with trail renderers wrap, their renderer will refresh itself as it moves, so you don't get sharp lines being drawn where things are being repositioned. I did the same thing for a lot of objects in an old game on this blog, Particle Rain.

As always, charge-up noise is courtesy of Jaview Zumer under this license.

Fiddling with player control refinements, a new final level, and a to-do list

(New build up here!)

The jury is still out on whether I like these timed walls over the walls which appear when you charge... But I'm far more happy with the new level 10 that's in this build. But what I focused on more for this week was player controls.

For the most part, the game functions as I want it to (The actual control scheme will be changed at least one or two more times before I'm happy, but that's another issue) but there are several small issues around charging that ruin the flow of the game. The biggest issue is when the player seems to wrap around at an inconsistent speed when interacting with wrap walls. I didn't succeed in solving that, but I did uncover some hidden issues that could have been contributing to the problem. I also narrowed down that the root cause of this may be. I think it has something to do with the length of the charge.

Some things I want to do in future weeks (in no particular order):

• Change mouse controls so you can also charge with mouse-click and you will only face the mouse when holding down mouse 0
• Change gamepad controls so that right trigger is the charge button
• Add a trail renderer to enemy projectiles
• Add a color change and particle effect for when goals revert back to zero after you fail to clear them. This would especially make the linked goals easier to understand upon first encountering them, since all linked goals would fail at once.
• Implement moving walls, enemies, and goals for future levels.

Eventually, this is going to start looking like an actual game. Then I'll have to get a sound guy (or gal) to do some sound! Ditto for art.

Speaking of sound, charging-up noise is courtesy of Javier Zumer under this license.

Trail renderers, timed walls, updated instructions, and a level select

(Looking for the latest build? Check it out here)

This post is going to be very short! I've just come back after a weekend away from home and I'm barely awake right now. That said, I did get just enough work done during the week that I can post a new build and feel pretty good about it. Let's talk about what's in it!

Trail render on the player is a minor cosmetic upgrade. I love trail renderers because they make movement just a little more clear to read, and they make screenshots a LOT clearer to read. I still need to treat them so that they don't draw while being repositioned, but that's for next week.

Updated instructions were necessary, now that controller support is here. Ditto a level select option since I'm pushing ten levels. Both felt pretty scrunched in, so I had to revise until I still had enough content but sized and positioned in a nice way.

Timed walls feel good! Maybe not as good as I wanted them to feel? I'm actually happier with level 9 than 10. I'll try to make better timed-wall levels next week and see if I like them better than the walls which are only walls while you're charging. And the week after that I'll likely combine them to see if levels feel too busy with both elements.

Charge noise is courtesy of Javier Zumer under this license.

SUNDAY is the deadline!

Wow! So I knew this past weekend I wouldn't have the time to work on the game, and thus, wouldn't be able to make a post about my progress. What I DIDN'T know was that I would also space out and not make a post of any kind whatsoever. Apologies! These next few weeks leading up to Thanksgiving are going to be a bit hectic. I hope to make an update every weekend regardless, but that may not always be the case (this next weekend especially, so we'll see how good I am at keeping promises in a few days).

Thanks for your patience.

Scheme control

(The build is up right here! Use the mouse or the right analog stick to change your rotation.)

So I didn't end up taking out the appearing/disappearing walls as I said I would... I decided to give it another week and see how I liked it. The verdict? They're a bit more interesting than I originally thought, but they still need help. I redid the last two levels, and one (level 9) actually came out well, I think.

What I spent most of my time on this week was considering alternate control schemes for the game. You can now play the game with an attached controller, which is something I've really been meaning to do. I also experimented with the player being able to manipulate their facing independent of their movement. My first sketch is over here, but I wasn't really impressed with it. You use your mouse or analog stick to move around a game object which starts out fast and then slows down as you charge. This game object is only created when you begin building your charge, so you can only change your facing while holding the space bar down.

The control scheme I settled on for now allows you to always change your facing using the analog stick/mouse. It's a bit clumsy in the case of the mouse since I prioritize mouse facing only when you are moving the mouse. It results in a feeling that WASD input is fighting the mouse input.

As far as the analog goes, well, analog is so accurate and feels so good in general that the right stick is hardly necessary... So, I may just reverse all my changes in the end.

Charging up noise is by Javier Zumer under this license

Disappearing walls: Not so exciting

(This week's build can be found here!)

I was somewhat busy this week, so I didn't work as much as I ought to have on the game. I did implement the disappearing walls, and I did make two levels out of them, but that was maybe 45 minutes of work, tops.

The consensus? Walls that don't do anything but block the player just feel... like normal walls. Even if they're sometimes not there. They're not that interesting, and I can hope that when combined with other elements they become more engaging, but I think I'll probably end up scrapping the appears-only-when-charging walls. Walls that appear and disappear on a timer might make more sense...

Charge-up noise by Javier Zumer under this license.

Just some small improvements

(The new build is up here!)

This week I added a particle and sound for when you collide with a bounce-wall, ditto for when a goal or linked goal resets its numbers back to zero. I also added an 8th level (Which is getting really very easy to do - level 8 is novel enough that it seems worthwhile, but only took about 5 minutes to create).

In thinking about the three features I brainstormed last week (Walls you can push, Walls that teleport you specific places, and either walls which only exist while you are charging or walls which only exist while NOT charging) I think walls existing only while charging make the most sense to develop. First, I already have the code I need to make them work. Second, I like walls existing only while charging over the opposite due to the fact that a) Charging is very strong, and I predict restricting it will lead to more creative puzzle solving and b) It's much easier, visually, to illustrate that something is going to appear than it is to illustrate that something is going to disappear.

Ideally, I would have had a level with that working in it today, but if I'm honest, I got a little lazy this weekend. Let's hear it for lazy weekends!

The charge-up noise is, again, courtesy of Javier Zumer, and is being used under this license.

The Adversaries

(This week's build is up here!)

The pace I've been building this game is, obviously, incredibly slow. I've been working on this for about nine whole weeks! Some of those weeks, I added almost nothing to the game, maybe a few particle effects, some audio, and that's it. Or maybe I added a single level, and that's it. So it feels really good to say that this week I added something a bit more substantial: enemies.

One of the benefits to stretching work out this long is that you can let an idea sit for a week and a half before you implement it, and when you implement it, everything just sort of works the way you thought it might, maybe even a little better. I knew it would be a good idea to have an enemy which shoots out projectiles that interact with warp and bounce walls the same way the player does. It reuses mechanics, which is like reusing a theme or shape in a book or a painting. It's more aesthetically pleasing and makes things feel a little more balanced to the player. It's also practical. I know what these things are going to do because I already have something doing the same thing.

I gave the enemies a bounce wall to spawn as a shield whenever the player charges because a) Again, reusing mechanics and b) An idea I had from the very start was an enemy that had to be struck from behind to be killed. It also had an unpredicted effect of c) Making the enemies seem actually quite clever. If you charge them head on, you'll hit a shield which doesn't just stop you, it bounces you away. The harder you attack them in this way, the harder they rebuff you, like tiny little kung-fu masters.

Feature-wise, I could create a few more levels, (10-15 total) and then polish this up and call it a game, or I could create some other features (walls that teleport you specifically to other walls, walls that can be pushed, Walls that disappear or appear only when you are charging) and keep fiddling with things for a few more weeks... I guess we'll see...

And again, the charging-up noise is by Javier Zumer, and is being used under this license.

P.S. "The Adversaries" would make a great band name

P.P.S. I never noticed that the pluralization of Adversary contains the word "Aries"

Put a little bounce in it

(This week's build is up here)

I got that new goal type up and working... I think the disparity between bounce walls and warp walls is still large. Bounce walls... are just a little useless, and it's very hard to bounce off them accurately. I thought about having the player always bounce such that they end perpendicular to the surface they collided with, but I don't like that so much... It could be interesting though...

I've also been kicking around ideas for enemy AI. So far I'm thinking about an enemy that knows when the player begins charging, and puts a bounce wall shield up to block any direct charges. The idea being that the player must find a way to strike this enemy's back by warping or bouncing around the level. Meanwhile, the enemy automatically shoots out projectiles which interact with bounce and warp walls the same way the player does (these "bullets" are essentially always charging). It could work.

Still settling down into my new routine in my new apartment and in my new job... This post has had a lot of ellipses in it...


Just as always, the charge-up noise is by Javier Zumer, and is being used under this license.

Just a little bit added this week

(Check out the new build here)

Not much to say this week other than two events came up this weekend that I didn't anticipate at all! Not bad things, good things, so I'm happy - unfortunately I didn't spend nearly as much on this prototype as I'd have liked. Anyway, I did add two levels which deal with bounce walls, and it's made me realize that I have a problem I need to solve: the imbalance between usefulness of warp walls vs bounce walls.

Warp walls send you places you might not otherwise have been able to go. Bounce walls simply allow you to change direction. This is useful only if you need to hit two goals at the same time, and only if those goals cannot be connected by a single, straight, contiguous line. But goals can be fulfilled piecemeal in this game, which means that in many situations you can forgo bounce walls entirely and just complete one goal and then the other.

What I need, I realize now, are a second type of goals which are linked to one another, which destroy themselves on contact with the player, and which resurrect themselves if their linked objects are not also destroyed within the stated time limit... I'll think about this for next week.

Also, I need to give bounce walls some audio and particle effect love, like I gave to warp walls. And I need to look into an issue where the player can become stuck within bounce walls before the wall appropriately repositions the player.

And again, the charge-up noise is by Javier Zumer, and is being used under this license.

Back to work!

(The new build is up here!)

Hello everyone. This week I return to regular work on this blog - hopefully for the forseeable future, I'll have several hours a week to devote to this blog. I took a week off last week because well... I was moving, and things were quite hectic. Things are still a hectic, but in a different way, and I'm now settling in to my new environs.

I'm still moving forward with the same game right now, so this week's offering is just the same thing with a bit more offered. I made some minor edits, but primarily I did a little bit of work and added two levels. I still need to add a tip or tutorial system, but I'm hoping these first three levels are really easy to understand (after reading the instructions). Next week should bring with it a better tutorial, and more levels.

As last time, the charging noise is courtesy of Javier Zumer under this license.

Delegates, Blue Walls, and Quick Blippy Particles

I'm going to run out of ways to vaguely say "Making slow progress" if I keep naming my posts as I have. To that end, I'm just going to put what's new right in the post title.

In addition to moving in about ten days, it's also my birthday this weekend! And my parents are visiting! And it's labor day, and tons of other things, and et cetera! I did the following in about fifteen to twenty minutes. Now the player script uses an event system so that I can have other things "know" when you're charging. Handy for making wrap and bounce walls change color to advertise interactivity. You also spawn a neat little particle when you enter a wrap-wall. Makes it feel more like you're "diving through" and less like you're just teleporting.

Like the last post, charge-up noise is courtesy of Javier Zumer under this license.

Progress by Degrees

This week I added a bit of polish (like... the kind you put on a linoleum floor or on a prized trophy... not the type of sausage) on what I submitted last week. Just a few hours working on audio and visual tweaks to get the goal-triggering and the charging to look a bit better and give a better feedback to the player. Check it out here!

Charge-up noise is courtesy of Javier Zumer under this license.

Just the tiniest bit of progress

My requirement right now is that I post something, anything, each week. This week I managed to get this going, in between moving shenanigans and spending a lot of time with some great people (at Bit Bash, no less!)

Reviving something old

Play the spare parts here!

I briefly considered entering a hiatus for this blog until I was situated in my new job, but I decided that, whatever small amount of work I get done each week, I want to publish it here.

What I did this week is really something that I did many, many months ago. I had a game I was working on that involved being able to charge into walls which wrapped you around the level and into walls which bounce you against them.

I could tell it was fun, but I couldn't tell what I wanted to do with the idea. Hopefully over the next few weeks I can figure that out.

A fully-assembled Revolver

(Play the game here)

Well, Revolver is done finally - it looks and plays like a one-week game, but it took three due again to how weird my free time is getting this month.

To be honest, I wish Revolver could have turned out better. I still feel like it's really lacking something, and I wasn't able to really find out what that was. For that reason, I wasn't really excited while working on it, and I think it shows. There are some surprising things you can do with the way the shooting is set up, enough to the point where I do think you could make a much larger game out of this.

I didn't try it here, but I wanted to know what it would feel like if you didn't charge your shots, but they naturally got larger and stronger the longer you kept them alive. The size-to-damage-and-speed relationship was also interesting. A game where bullets and enemies could survive contact with whatever they hit, but shrink and lose size/damage but gain speed might be something to look into.

This three-week development cycle is another thing to maybe look into. I did maybe 1-2 hrs of work a week on Revolver, if that... but if I had the normal 5-7 I could try tackling larger projects. Something to think about. I could also take the fourth week off and think of ideas for future games, while actually playing games myself (Outside of Destiny and Hearthstone, I've forgotten what that feels like!)

Anyway, yeah - play Revolver here! Despite my self-criticism, it's still worth the two minutes of play.

Laser charge sound is by Javier Zumer, and is being used under this license

In-game background music is "Buildy" by p0ss, and is being used under this license

Revolver at the Barest of Bones

Hi all! True to my word, here's my post for the week. I'm still really taxed by other things going on right now, in addition to really wanting to spend as much time socializing with all the people I'll be saying goodbye to in just a few short weeks! That being said, I did just manage to get Revolver to a 100% playable state. Go ahead and play it here!

Yup, there's no HUD or sound, but it is all there and playable. Next week will be sound, UI, and polishing the feel of the game (Off the top of my head, enemies could move a lot faster towards you).

As it turns out, the idea of having a shmup revolve around a central planet is pretty cool! (Though I guess Resogun sort of already proves that.) Organizing a shmup into three discrete lanes, however, isn't a very good idea, I think. A lot more interaction was lost than I thought would be. In fact, I might remove the lanes altogether for next week! If I have time...

July into August changes for Sunday is the Deadline

Sorry, there's no game this week! I did work on a game this week though. It looks like this:

It's a shmup called "Revolver" where the ship, the enemies, and the bullets all orbit a central planet. I might have completed it, but things have become quite busy for me lately, what with accepting a new job in a new town, preparing to move, and still keeping up with the surprising amount of events occurring in the next month.

My priorities are on making my transition into my new job as smooth as possible, and giving myself some free time to breathe a little too. And that means downshifting on this blog, at least for the next few weeks or so. I'll continue to post something every Sunday, but I may only be posting with brief updates on what I did with Revolver that week.

Hopefully that's okay with any regular readers - I'm really proud of the dozen or two of you who keep coming to this blog, and I want to keep giving you worthwhile updates each week! Please bear with me in the meantime.




P.S. It's called a shmup because primarily the ship shoots up. It's short for "shoot 'em up." In the case of Revolver I think the more appropriate term might be... shmround?

Rogue Wave

(Play the game right here!)

Rogue Wave is a very weird game indeed. I didn't know what the heck I was making for about 90% of the time I spent on this game. I started with a concept that I knew could work, but I had no idea if it would. Very much an experiment for me.

The game came to me pretty much out of the blue: What if you had turrets, in a sort of tower defense type game, and those turrets had to hit each other to set off a chain reaction? It'd be really powerful to set off a million turrets at once, but you'd have to make sure that they were pointed at the enemy in addition to each other.

Rogue Wave didn't look like it'd be any fun all the way up until I finished it. I'm still not sure if I'd call it really fun, but it's at least interesting (going back to that idea that a designer can make the mistake of accidentally creating an interesting game as opposed to a fun game).

I do think that a much bigger game could get created out of Rogue Wave... I think there's a lot of design space to investigate here. The main parameters you have to tweak are large enough, I think:

• Enemy size
• Enemy speed
• Enemy spawn rate
• Difficulty increase rate
• Enemy size/speed/spawn rate changes over time
• Turret fire rate
• Turret turn rate
• Turret Size
• Turret # of sides (an octagonal turret could spit out 8 bullets) 
• Energy generation rate and requirements
• Bullet Size
• Bullet Speed

My original idea for the game allowed the player to go to each turret and use energy to totally customize the size and #of sides for each turret. If you had a double-large turret, it shot out two bullets per side, and if you had a triple-large octagonal turret, you'd have a huge turret that shot out three bullets for each of its eight sides! I knew before I sat down to begin development that this was out of scope.

Play Rogue Wave here!

The menu music is from SonarTuning and is used under this license. (I've been finding more and more music under the public domain. The in-game music is a track called Observing the Star. It's really kind of lovely and I wish I could remember who made it!)

Pallet Rain

(Play Pallet Rain here)

Pallet Rain is definitely one of the more abstract games that I've made so far. I wanted to use the missiles from missile tow for something else, since I liked the way that they moved. At the same time, I had found some excellent public domain sound effects that I knew I could combine for some interesting, calming background music. I also knew that I would be busy this weekend, and needed something simple to complete during the week.

The result is interesting, but not particularly fun. I did want Pallet Rain to feel relaxing, and I think Drawing Mode definitely accomplishes that, but survival mode does not. It'd have been way more relaxing to have the object of survival mode to be to "catch" the yellow and blue objects, rather than avoid them (which just makes things feel anxious). I guess it'd have to be renamed something other than "survival" mode then.

This was a very simple game to make, but I still managed to make it quite complicated for myself in certain spots. Still, I managed t learn some things, and Pallet Rain does succeed in being visually appealing - in a minimalist sort of way. Play Pallet Rain here.

Since this is a game design blog, I want to close by saying that today Nintendo President Satoru Iwata passed away, and though I only really knew him through the Nintendo Directs, the past Nintendo E3 shows, and the "Iwata Asks" articles, it's really tough to see him go.

America's Birthday!

Hi, sorry for writing this so late - I'm not releasing a game this weekend since I'm celebrating July Fourth! See you next week!

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!

Container

(Want to skip to the game? Be my guest!)

I started making container on Friday, and work basically proceeded as I expected it would through to Sunday. I'm actually sort of proud of how it almost felt easy to put on a reasonable amount of polish in only a short amount of time (though there are still one or two things I ought to have fixed).

You can sort of see how Container is a kind of mash-up between Red Zone and Bolt. It's got hexagonal movement, plus the "push" lasers from Red Zone.

Having the enemy spawner jump into "hard mode" after you kill 8 enemies was an idea I had after I realized that I hadn't built my difficulty scaling system to be able to twist all the knobs I wanted it to (it adjusts spawn interval, but I didn't allow it the ability to set the thrust or acceleration of enemies).

All in all, I liked how "hard mode" came out - you sort of get the feeling that you've made the game mad. It also feels a little better when you lose. "Oh, I got 10 kills, okay," is a lot less exciting than "Well, I was fine up through 8 kills, but then hard mode made things get really crazy." It can be hard to make the player feel like they achieved anything with all of these "endless" games I make, so hard mode helps with that, at least a little. You get to go out with more of a bang!

Menu Music is from Sonartuning and is used under this license
In-game Music is from p0ss and is used under this license

And you can view the game here!

Red Zone

(Want to skip to the game? Be my guest!)

Red Zone was made in a very short amount of time! I want to say that if you totaled everything up it was only done in about 4 hours of actual work. Why such a short amount of time? Well, there was a lot to do this week! Industry events, get-togethers, a trio of birthdays, not to mention starting a new job! Still, I'm reasonably happy with the result. Here's Red Zone:

It's a very very short, very very simple game. I had an idea where a center turret fired out a laser at enemies, which sounded like an elegant enough place to start. Then, speaking with a friend of mine (the same one who runs this awesome blog!) I got the idea that you could actually "herd" enemies with your mouse.

Sometimes I think about whether these game ideas could be prototypes for larger projects. I think Bolt, Shoot the Moons, Convert the Sun, and even Diamondback could occupy a small team for more than a year. This one? I don't know... It's sort of like a shmup, only you can't move. Maybe if you played around with different beam types....

Music this time:
Title Music: ambient_menu By AlexandrZhelanov
Game Music: enchantmentinstumental By Sonartuning
all under this license

Play the game here!

Bolt!

(Want to skip to the game? By my guest!)

Okay, so I'm really excited about Bolt!

I'm also really conscious of where Bolt fails. I've never made a racing game before, and I had this quirky idea for how to organize it so that I didn't have to code any "real cars" or anything:

 If I always had the player "attached" to one of these hexagonal prisms, well then I would be able to attach them to a specific face of that prism. And if every prism knew which prism followed, you could make a linked list of prisms. And when you got to the end of one prism, I could have the player warp to the beginning of the next prism:

 Link a bunch of prisms together and boom! Instant racetrack. It was a pretty simple concept that I immediately succeeded in complicating:

Bolt is an interesting concept, but a pretty shallow racing game, I think you'll agree. I really only scratched the surface with what kinds of races I can make with these building blocks, and I really only scratched the surface of what's actually fun about this kind of racing game. You have no control over acceleration or braking, so it's all about having a rhythm of boosts to hit. That really only clicked partway through development. I'd like to add multiplayer, and an actual tutorial, since the instructions might be difficult to follow the first time around.

But man, if I were to grade my Game-A-Weeks on how cool my screenshots look? A+:

You can find the game right here

Menu Music is by Bart, in-game music is by RevampedPRO, usage under this license.
Main Menu typeface is "Hetilica" by Diego Quintana.