Tag Archive: programming

Ludum Dare 32 is over and I survived lol There’s something demented about voluntarily participating in what’s basically “crunch mode” for no reason other than to make something cool but I’m glad I did it. Here’s my post-mortem on how things went and my general design process. First up this is the final result of my 72 hours of slaving away in GameMaker: Studio and Spine:

You can check it out and give it a play here.


LDJAM’s topic is announced once the event begins and this jam’s topic was “An Unconventional Weapon”. I decided the 72 hour jam was more my speed over the 48 hour competition because I don’t really care about winning or anything, this is more for me to get my creative mojo kickstarted and possibly come up with a prototype I could turn into a full game down the road so that extra 24 hours to throw in some decent art was too hard to resist. The time limit in general adds a huge doom clock hanging over your head but I know a solid concept is half the battle…there’s no point spending all weekend working on something that wasn’t a good idea to begin with and it’s hard to force creativity so I decided to give myself 2 hours with no pressure to concept ideas up. Even if I came up with a decent idea right off the bat I would keep roughing ideas out till the time was up, so if I couldn’t think of something right away I didn’t freak out since I had a full 2 hours to kill.

I had 3 main goals for Ludum Dare:

1) I wanted one good core mechanic. I’m thinking in iPhone game terms instead of making an epic RPG or something. I wanted an idea that I could theoretically clean up and ship as a simple casual game.

2) I wanted something flashy with a lot of Spine animation because I wanted to really put my GameMaker + Spine workflow to the test since I’ll be using that combo for basically anything I make.

3) I wanted to avoid menus and text because I find doing that stuff in GameMaker is a whole project in itself. It means writing scripts that display and activate buttons and draw and transition menus and lay out text areas, and there’s nothing that easily sets up scrolling menu lists etc. If I made a text/menu heavy game I would spend at least half the 72 hours just trying to get those looking good and working nice. So I wanted as little GUI coding as possible.


Here’s the size of my final FreeMind mind-map of ideas:

These always seem so much smaller when you're working on them

Let’s break it down stage by stage. I started by throwing down any words or ideas vaguely related to the topic:

It's like a word-assosciation improv class for nerds.

Looking back on this list I can actually think of a few cool ideas based off it, so as far as I’m concerned just doing this exercise alone was beneficial. Who knows, some of these concepts might make it into games I make down the road.

I started out with a pretty safe idea…I was going to try some clever meaningful artsy deep outside-the-box take on it. I watched some Let’s Plays of Life is Strange recently so I think I was just in that slow-paced mindset:

Most of these are half-thoughts that made sense in the moment but now I have no idea what they mean lol

It was actually a solid game idea. It would be similar to a Diner Dash game where you micromanage a group which is already a proven mechanic. You’re a villian working as a teacher to distract a class from passing their exams to prevent anyone from being smart enough to thwart your plans down the road. It wouldn’t be too art-heavy either, I would just need to draw a classroom for a background and I could set up a sweet camera angle and hand-draw the characters so it looks like a shot out of an anime:

No idea what anime this is from

It was something I knew I could pull off in 72 hours and fit the theme but it was boring lol And it would either be text/menu heavy or I would have to come up with some icon system that made sense and it would just be a lot of GUI coding. My buddy Derek was like “what? no defending your hot dog stand from ninjas by throwing hot dogs at them?” and I realized that my idea wasn’t really something I would have fun making. A big part of why I’m making my own games is to make whatever I want and I’m a simple guy: I like flashy action and explosions lol


So I scrapped that idea, threw on a bunch of Sakuga anime compilations (basically the most fast-paced over-the-top action scenes from anime), blasted some high-energy Megaman music and wrote out a bunch of words related to the theme but more action oriented:

ahhhh, this is more like it!

I liked the ideas of “killing enemies gives you a new thing to use”, “merging body parts from enemies to self”, and “stacking effects”. The most natural idea that ame to me would be killing enemies and taking their body parts to attach to yourself, stacking the effects of whatever it is you’re taking from them. Robots/mechs made the most sense because it’s logical that you could replace a robots body parts with other body parts so the concept would be clear from the start. I’m terrible at drawing/designing mechs (I’m more into medieval stuff) so I went with a robot chick as a main character, plus I loved the whole idea of Astroboy as a kid. So I started fleshing that out:

Approximately 3 weapons off this list actually made it into the game lol

I had no idea how much I could do in 72 hours so I put down anything I could think of to help me visualize how things would work. When I got enough down to have a solid idea in my mind I revised it again into something more final to follow:

In theory you could mind-map an entire game out down to every function/script and variable needed.

In this stage I try to group things together and think about what I can re-use code-wise. So I’ll jot down a list of weapons and then break them down into “projectile” and think about what attributes projectiles are going to need to do all of the behaviors I’ve listed. A pistol bullet, machine gun and shotgun blast are all just variations of firing rate, ammo per shot and spread angle. This is actually the part about game design that I enjoy the most, I like breaking big ideas down into smaller efficient chunks. This helps me visualize how a lot of the code will work too. I’m still an amateur programmer and can get lost in my code easily without a good clear overview of what I’ll need.

I really wanted to have her legs switch out for legs that can jump, jump really high, and float/hover in the air, but I knew I should start with her arms and save the legs for if there’s time.


First up was making a rough Spine file to see 1) if I could get Spine files loading/animating in Game Maker properly and 2) if I could get Bone coordinates off a Spine Skeleton and attach new Skeletons to them that would follow their motion. This was the major tech hurdle for this game idea so I knew if I tackled it first the rest would be smooth sailing and if I couldn’t figure it out I’d have time to switch to a new idea.

First rough idea for a character. Short hair like this would've been way easier to animate but I like a challenge

Fortunately that went silky smooth and I got it working without many problems. So I revamped the character with plans to do her hair and skirt with FFD-animation in Spine. One of the nice things about using Spine is that I can lay out a character and animate her and get her in-game, then go back later and rig up her features for more detailed animation (hair, skirt, facial expressions, adding shading to the art, etc.) and know it’s not going to break anything:

I tend to use 0-length bones so I can attach different angles for bodyparts to them but I regret that on this character, using longer bones would've made animating a lot easier.

In the end I only had time to do her bangs and I used really rough FFD placement so you can see her hair bend with sharp corners in places but the gameplay would be fast-paced enough for no one to notice…or care, because I only had 72 hours lol I had to keep reminding myself that things were “good enough for 72 hours”, no one is expecting to see some AAA product in 72 hours the fact that I had a character animating at ALL was great:

I animated some basic motion and threw her into the game to make sure everything was working and to learn how to do collison. I messed around with Bone compensation (so in Spine I could move her backwards as she dashes back and control the distance/momentum in Spine with her x/y info updating to match in code…this is something I’d want for doing a huge boss that stomps his feet as he walks and pauses with each stomp VS moving at a constant rate of speed), and I managed to pull off a while back when I was doing tests but had way too many problems getting it to work now so I gave up and stuck to animating in code. I’m using TweenGMS to set up tweening and I was able to get a good enough result that way, but I’ll definitely revisit Bone compensation in the future.

The next test was making sure I could turn off the Image Slots and spawn new Skeletons (gibs, weapons flying out of hands, etc.) at specific Bone positions, and, well:

In retrospect this probably makes me look pretty demented lol

No probs there lol The head is a separate bone. I also set it up so that “gibs” could be guns, bones, etc. and spring out at various speeds/angles etc. I’m pretty new to parent/child heirarchy stuff in code but it worked out just like I hoped. The code for this game in general is some of my best, I wish I could rewrite my main project from scratch to make it more like this but I guess you just have to accept that no project will be flawless all the way through. Definitely looking forward to starting my next game after my main project so I can write a bunch of fresh new clean organized code from scratch.

Next up was replacing her arm with a gun and figuring out how to do a nice chain of command up the guns. Each gun has a child gun that attaches to it’s attachment slot and receives commands from its parent. There’s a LOT of potential in this setup, I can have each type of gun animate in a different way and have different attachment slot positions and different length/speed animations for shooting. Originally I was just going to have one gun with a few attachment slots for other guns, but I wanted to test out optimizing my Spine code. On my main project I’m working on I tried implementing Spine but I didn’t really know what I was doing and I was getting a lot of lag with just a few Skeletons. So for this project I wanted to try optimizing things since I had a nice clean empty project to start from where nothing would break.

I did a bunch of digging through the tutorials and trying different things out and the end result was fantastic. I was stacking guns on top of eachother because that was the easiest way to test and at first the game would lag by 30 Skeletons, which really isn’t very much. When I originally tried Spine out I envisioned doing all the art for my games in it, like down to menu animations and bullet effects but no way that’s possible with 30 Skeletons so in my main project I was already planning to use Spine as little as possible.

But after optimizing I had *700* guns attached to eachother with no lag lol:

It's like a giant french-fry of death.


The sight of it made me laugh and I decided to leave the huge stack of guns while I tried to get them to shoot and once I got the entire stack shooting (with a delay too so you can see it flow up the stack one by one) I decided it would be cool to let the Player actually stack like this instead of what I was originally planning. I set up some different guns and timings and the whole thing felt absurd but made me smile so I just kept going with it. But the guns quickly go off the top of the screen so I looked for tutorials on doing zooming cameras that can zoom out to keep two objects in the view at all times and found a great one. I set it up to use the player and the top of their gun stack as the zoom targets so the higher you stack the guns the further out the camera zooms. As far as I know there’s no maximum limit, you can stack till the game crashes lol

Spaghetti missiles, explosions, robots and anime chicks...if there's more to life I can't imagine what it is.

I got cocky and decided to try spaghetti missiles that would home in on targets and leave particle smoke trails…really it would’ve been a more complete game if I had focused on the gameplay at this point instead. I had a lot of ideas for stuff like enhancements you could get that would add fire/electricity/etc. effects to your weapons, which would add a little strategy to the collecting aspect. Or even better, have it detect when you have X number of guns of the same type stacked in a row, so if you stack 3 pistols they glow and fire larger deadlier shot. That would create a mini-game within the game where you would be picking and choosing which guns you wanted to catch, having to make snap judgements as the guns fly up kind of like Tetris. Another idea was to have negative guns that you can accidentally collect, which would be in your stack and fire with the rest of the guns but would do stuff like fire a missile that homes in on you so each time you shoot you also have to dodge a missile from your own gun as a penalty for grabbing that negative gun. I planned to have a huge boss that the camera would have to zoom way out for, like you’d need a big stack of guns to defeat him etc. but ran out of time. Because of all those ideas I think there’s something here that could be expanded on into an interesting game, but I don’t know if I see enough depth in the game to keep going with it.

Anyway so from here I had to grab some music from incompetech.com and whip up sound effects in Bxfr. I threw in some random pitch changing so most of the sound effects will sound slightly different each time you hear them to avoid being too monotonous. The background I left till the last minute and whipped up some quick terrible buildings in Blender and had tons of problems trying to get a scrolling background working right so you’ll see lots of glitches in that but I got it working literally at 8:59pm one minute before the deadline lol It’s glitchy but hey, 72 hours cut me some slack.


Also a bit earlier I spent some time balancing things for the Player. I’m big on not wanting to bog the player down with tutorials, I like when games naturally teach the Player to play. So there are little nuances for ease of playability since most people won’t do more than play for a couple minutes. If you have no weapons you won’t be able to get a missile launcher as your first weapon because the delay on it makes it too difficult to use as a first weapon, you’ll get overpowered too easily unless you really know what you’re doing and even then it’s almost impossible to make a comeback, so I didn’t want the Player to deal with that frustration. You won’t see the robot guys until you have 3 guns attached so you have more of a chance to beat them, and they won’t start attacking you back or changing what height they fly in on until you have a solid stack of like 10 guns. So the game should have a nice easing curve for people to play without a lot of frustration. I love adding these little details to help guide the player into being able to handle the full experience.

I was also originally going to have the Player’s stack build a lot slower, like they just get one gun per enemy but because of a bug the robot enemies were able to get stuck in a “being hit” loop where they would keep spawning out a weapon every time they got hit but as you got more weapons you would hit them more times spawning more weapons which made you hit them more etc. and it became a huge bonanza of guns being tossed in the air like Oprah handing out schools and hump-backed whales. When I fixed the bug I decided to leave the insane gun bonanza in because it added to the absurdity and I figured people would only ever play the game a few times for a couple minutes and then move on so I wanted them to have a memorable little experience in that short window of time.


I’m proud of the end result. I accomplished my goals going into this and with the energy I have these days now that I’ve got my Vitamin D levels handled I was able to power through the whole weekend working non-stop except for sleep and food. The time pressure was fun, it forced me to make fast decisions and throw out things that weren’t working while also plowing forward on ideas that I suspected would work…no time for waffling or second-guessing which can be a big hurdle for gameDevs on longer projects, feature creep and rewriting stuff that doesn’t need to be rewritten etc.


GameMaker and Spine were AMAZING together. The workflow is so efficient that I was smiling ear to ear as I worked. It takes like 5 clicks to go from animating in Spine to seeing that animation running in-game exactly like I saw it in Spine. For people just getting into gameDev now where this kind of workflow is more common, this might not seem like that big a deal but man, in the old days I would have to do individual frames by hand and then write up text files with a list of coordinates and timings and image names to try to describe to a programmer how the animation should look and then just cross my fingers that they would come up with something that looked in some way sort of like the vision I had for it, which of course it rarely did. It was like dropping your child off at school and picking him up later and he’s all disfigured lol With proper optimization and memory management for Spine files in GameMaker I feel like I can literally make ANYTHING 2d. If I had the time and artistic skill I could practically duplicate Rayman Origins and Ori and the Blind Forest with this combo. If anything doing Ludum Dare and working under a time limit gave me even more of an appreciation for the tools I have access to. I WISH I had these kinds of tools and workflow back when I was a teenager. So if you’re in your teens or early 20s and you’re getting into gameDev consider yourself extremely lucky, you’ve got a huge head start compared to when I was that age.


I’ll be participating in Ludum Dare again in the future, this was all win/win for me. But for now it’s back to my main project. My Ludum Dare game has actually made me more excited to get cracking on this thing. I’ve been avoiding the art side of it because of the laggy Spine issues I was having in GameMaker but now that I understand the optimization stuff I’m looking forward to dumping a ton of sweet art in there. I’m planning full-screen bosses and can’t wait to get crackin’ on them. The menu system is pretty much done, I just have some last tests and cleanup to do with it but then I should be able to get into the fun art stuff. I’ve got the bosses planned out in my head and rough doodles, I just need to refine them into actual designs and start dropping them in the game.

All in all this has been an excellent start to the year. I’m hoping to keep this pace up the rest of the year and participate in Ludum Dare regularly, but one thing at a time…first I gotta’ finish my main project and ship the damn thing lol

Alright, time for an update. I hooked up with Rocketcat Games, makers of epic hits like Wayward Souls (grab it on the App Store here) and Punch Quest (grab it here), to do some Spine animations for their characters for a new Tactical RPG they’re developing. Lots of work but a fun project, I’m extremely comfortable in Spine now and got to mess with a lot of FFD mesh animation (capes, scarves etc.). I also hooked up with Ravenous Games for some top secret work I can’t talk about. They just launched Devious Dungeon 2 which adds a ton of new stuff to the series (grab it here). So with enough money to pay my bills for a couple months it’s back to my own game.

…but first, a detour lol On a whim I decided to enter Ludum Dare 32 this weekend. For those of you who somehow haven’t heard of it it’s a worldwide marathon weekend where you get 48-72 hours to develop a game based off a theme assigned when the contest starts. I haven’t done a game jam in years but my long-term plan over the next couple years involves actually shipping games (lol) which means I’ll be doing a lot of prototyping (I have a HUGE Evernote doc where I throw down any random ideas I come up with to flesh out later when I’m looking for ideas to prototype). Soon as I’m done my current game I want to roll right into the next one so there’s always a chance that whatever I come up with for Ludum Dare will be my next game. Or maybe I’ll fuck it all up and not even finish my entry in time, who knows lol I actually haven’t looked at the themes list, ’cause I like to live on the edge that way.

So if you want to watch me lose my fucking mind all weekend long, follow my Ludum Dare progress updates, setbacks, victory celebrations, mental breakdowns etc. on Twitter at @BPOutlaws. My Ludum Dare account is BPO_Jeff.

I’ve wanted to participate in Ludum Dare before (my buddy Mike is the guy breaking his back to run the whole thing) but as I mentioned in a previous post I was having a lot of problems with my energy levels for a few years. I was barely able to do more than sleep through the weekends. But now that I’m regularly taking Vitamin D3 I’m clocking in long productive days and want to challenge myself by entering. I’ll be doing the 72-hour Jam instead of the 48-hour competition because whatever I make is probably going to involve hand-drawn art so that gives me an extra day to make it look slick. Some of you may remember me as Tsugumo back in my pixel art days, but while I loved making pixel art the advancements we’ve had in technology that allow games like Rayman and Ori and the Blind Forest to exist, combined with all the slick tools us indies have at our disposal now, I can’t resist working with big HD art. I’ve coded my engine to support up to 4K (3840 x 2160) even though I don’t have a 4K screen myself lol

I wanted to make an alien race of giant goats to avoid just doing standard aliens...these sketches are just practice concepts changing the proportions of the basic goat design to get different characters that still look related.

That said, back on my own game I was having some creative issues so the break to work on other projects was helpful because it gave me time to brainstorm out some ideas on the art side. The major issue was actually kind of a silly one that I completely wasn’t expecting: because of the layout of my game (character on the left, enemies on the right, with as much space between them as possible to allow the Player time to react) I realized I needed all of my enemies to be tall and thin horizontally. If they were wide they would either cover too much of the play area (though one boss does that on purpose) or 90% of the sprite would be off-screen and basically be a waste. I also wanted to give things a sci-fi/mech theme, but you don’t realize how weird thin vertical mechs are until you try drawing some up and then realize they also have to be able to shoot from the three Track heights so if you make a humanoid robot it’s got to be able to shoot from it’s ankles etc. It sounds dumb, but it threw me for a loop for a while.

Now I’ve nailed down my theme and designs and while the game still looks the same as it did in my last update, I’ve been slowly plugging away at the code during my minimal free time and I can see the light at the end of the tunnel. Soon I’ll be able to go on a massive art overhaul and just start dumping art in there. At the moment I’m finishing up the menu system and coding support for game pads, iCade, etc. Doing a lot of stuff that’s way outside my experience level like setting up customizable keybindings and achievement lists and save/load encryption etc. Plus I want to release on iOS and PC, so there are a lot of platform-specific nuances to deal with (even simple things like on a touch-screen device you tap menu options but on PC those options need to visually light up as you drag the mouse cursor past them etc.). I’ve basically got 10 FireFox windows open with tutorials all day as I work lol I’ve learned a lot though, I’m looking forward to my next project where I would refine a ton of this right from the beginning to save some of the hassles I’m running into (like right now the menu system and gameplay are COMPLETELY independent from eachother so when you set options/controls in the menus they don’t do anything in the actual game and I have to stitch these two giant sections together…it’s gonna’ get messy [edit: nevermind, I totally fuckin did it my first try just now. I'm awesome lol]).

On the gameplay side I’m really proud of what I’ve come up with. I’ve got all the bosses except the final boss coded and each one requires a different tactic to defeat instead of just bumping up the amount of damage they can take…so the core mechanic the Player has to learn stays pretty simple, but each boss throws their own twist on it that you have to figure out as you’re fighting them and they each have 3 levels of damage where they change their tactics up forcing you to adapt on the fly. When I get to where I can record some new in-game footage I’ll show this off a bit more…right now the bosses are literally giant red rectangles lol I talked about some of my ideas for this in a previous post but now I have them fully implemented and they came out as fun as I pictured in my head…there’s a nice sense of “Yes!! I knew it, I’m awesome!!” satisfaction in that.

On top of all that I’ve started teaching myself how to use Blender whenever I get the chance. I’m hoping to learn enough about the particle system stuff in it to use it for doing cel-shaded effects but I am a complete noob so far. I’ll also be using it for more technical stuff like backgrounds or detailed mechanical objects in perspective where I don’t want to figure that all out by hand. I used 3d for the background in Elusive Ninja:

This was way too simple a game and did terribly, but I was always proud of the art in it lol

Gotta’ work as fast and efficient as possible when you’re working solo. Overall this year is going toward upgrading my skills across the board so I can put out quality games solo. Now to go stock up my energy drink supply to survive Ludum Dare.

Two videos for you today. First up is my game’s progress. The major parts of the engine are functional, but nowhere near polished yet. I’m a self-taught programmer, I’ve never actually taken a programming class or anything so I don’t really know what the best method of approaching a large project is. I’m going by what feels right and I’ve ended up basically applying my workflow for art to programming. For a drawing, an artist will usually start out with rough thumbnail sketches that barely look like anything, then when they find one that works they rough it out in pencils, then they clean it up and ink it, then they add the colors. The concept is taking something rough/vague and going through stages refining it down and adding details until you have the final result. Same thing with animation, you rough out the flow of the animation and then slowly refine it from there. So I’m basically dumping a bunch of duct taped sloppily coded ideas down to get someting that’s doing the jist of what I want, and then going back and refactoring that code 2 or 3 times until I have something decent.

No idea if this is a slower process than other programmers use, but I like it because I get to see some rough progress right away which helps motivate me because it feels like I’m accomplishing something (nothing is worse to me than those days where you stare at code all day hunting down a bug or refactoring or working on structural code that does a bunch of work behind the scenes, and at the end of the day the game looks exactly the same as it did before). And I end up with decent enough code in the end. I think with programming you can always do something better and it’s tempting to want to re-write things a dozen times to make them cleaner and prettier, but at some point you have to say “okay this works, it’s time to move on or I’ll never finish this project”. I’m taking the approach of “is this part of the code something I’m going to have to come back to a bunch? If not, then as long as it works that’s fine.” which has been working so far. I’m sure I’ll have to do some optimization down the road and clean some of those parts up, but I’ll deal with that shit when I get to it lol

Everything is still super temporary art (I think that sky background is from some anime) but the engine is my main focus right now. The music notes were just to test particle emitting though I’m debating making her ear things headphones like she cranks up some beats when she fights alien intruders because she gives no fucks and knows she can handle them. The enemies all have AI and Finite State Machines to react to the Player…they’re able to have different behaviors depending on their health and which state the Player is in. When you’re in the Default State you can’t attack, and when you collect enough of the Power Cubes you enter the Powered State and deflect everything back at the enemies to attack them, so in the Default State they can be more offensive and attack more while in the Powered State they’d do more dodging.

Level transitioning works and I have a lot of the boring outer-framework stuff done (although it’s ugly at best right now), so you transition from the Title Screen to a Main Menu, Stage Select, and the game will unlock levels as you complete them and save your progress for you etc. Also everything has customizable speed to it, in the video above the first level you see has the Tracks all moving at the same speed but the second level it shows has two fast Tracks and one super slow Track. So I can control the speed (and spawning frequency) of the Tracks, the Power Cubes, the saw blade Hazards, bullets, etc. which I talked about in terms of gameplay here. This should let me do a lot of cool shit, like having enemies/bosses that can manipulate the speeds of those things on the fly.

I’ve been fleshing out ideas for enemies and bosses and I’ve got them generally figured out. I decided to record some of my process to show how I use FreeMind to do a lot of my planning (not just for gameDev but for writing projects in general). It’s about 45 minutes long, but give it a look if you’re someone who does creative work and is always looking for new planning and organizational techniques:

There are a lot of Hotkeys built in for moving Nodes around and Expanding/Collapsing them etc. to skip around and edit quickly. I don’t even use all the icons spread around the interface, just the basics to get ideas down as fast as possible. You can also see that I’m using the same workflow I use for art and coding: dump down a rough brain-fart version, then go back and refine it in stages adding detail to get the final result. Give it a go and see what you think.

I fleshed out gameplay ideas for all the enemy/boss designs so from here I’ll be implementing them with temporary art. As an artist it’s REALLY hard to put off focusing on the art, but I know the art stage should come last because the gameplay is what’s going to make the game fun to play…if an idea I have doesn’t work in code, I don’t want to be in a position where I’m trying to shoe-horn in art that I’ve already drawn because I don’t want to waste it, or toss art away and have wasted that development time. So I’ve just come to accept that I’ll be looking at the art you see above for a few solid weeks before I get to finally let loose on the art and put it through a massive overhaul/upgrade. Gotta’ have patience, grasshopper lol

Past few days have been all about fixing bugs and tweaking gameplay, and attempting to add some new features or fix features that weren’t fully working properly. The gameplay is pretty much final, I’ve found a solid balance. The key was in looking at the higher difficulty as “more frequent stuff to dodge” rather than “faster stuff to dodge”. Going with “faster stuff to dodge”, there comes a certain point where the speed just becomes impossible for any human being to be able to keep up with, so the game becomes unfair. But with “more frequent stuff to dodge”, it comes down more to skill…you’re doing the same thing at 1:00 that you were doing at 0:10, but you have to do it a lot more carefully and skillfully to stay alive. It feels great, everyone’s liked the balance/difficulty in this last version.

One of the big things that came out of testing was the need for a tutorial. This was actually a huge surprise to me, the controls were instinctive to me and I just assumed there was only one way to logically play it. A few people complained about the controls being too sensitive or not sensitive enough, etc. I was getting some really random/opposing reports which was weird. So I started asking my testers more and more questions about their issue with the controls to narrow down what was going on.

Turns out one guy was playing it with swipes, one was playing it by tapping with his thumbs on the sides of the device, one guy didn’t realize you could multi-touch to hit the Deflect at the same time as you’re moving, etc. and the intended controls were two separate hands with a dragging motion instead of a swipe! Logically it makes sense that people would play different ways since there’s no standard D-Pad controller like on a console. But the problem is that because people were playing in ways I didn’t intend, to THEM the controls were bad/broken. If the game were released like that, those people would become 1-star reviews saying “The controls are terrible, fix them!”

So because I had a thorough testing period, I was able to narrow down a huge problem that would have blindsided me if the game had launched as-is. As I’ve said before, I can’t recommend playtesting enough! Anyway, so because of this I added tutorials for the movement and how the Deflect Meter works. They’re pretty simple tutorials, but they have drawings of hands holding the devices, so I think this will snuff out the confusion and have everyone playing with the optimal method.

Today I have a huge bug list to get through but all the bugs are super tiny, so hopefully I’ll blow through them. I’m trying to get a Quickplay button in, where there’s a button on the logo screens in the corner that if you hit it, it’ll skip all the logos and menu animations and jump right to loading the in-game gameplay. I think this will help encourage people to pick up and play the game more…if I’m on a short bus ride or killing time while I take a poo, I’m more likely to run the game that takes 5 seconds to start up rather than the game that takes 45 seconds to start up. I don’t know if this will do anything, but I’m going to put a Flurry analytic on it to see how much people use it and if it’s worth working it into the designs of future games.

It’s exciting to be this close to being done! I’m fixing tiny glitches and bugs all day and adding some last-minute ideas, and I’m going to be sending out a final testing build to my testers to play with today just to make sure I haven’t missed anything. I’m hoping to submit tonight (though it might wait till the morning because I haven’t slept in…a long long time, haha so I mght crash for a nap). Should get this thing out right before I take off for E3! :)

- Quickdraw

So I’m in the gameplay balancing stage of things and it’s been a blast so far. I’ve learned a LOT, in terms of game design. I’ve been hacking away at the code adding more and more nuances to it and I thought today it’d be interesting to talk about how the game has gone from it’s initial difficulty curve, up and down to both extremes of the easy/difficult spectrum, and what I’ve learned from the process that’s finally helping the difficulty settle down into a perfect curve. If you’re an iOS developer I highly highly recommend the TestFlight service. It was easy to set up and allows me to publish builds to multiple testers anywhere with an Internet connection, and the feedback, as you’ll read, has been extremely valuable.

Version 1:

This was the default gameplay balancing (from here on called the Hazard AI, or just AI). Basically hazards (all the objects in the game that are thrown at you) had 5 speed levels, and every 15 – 30 seconds the next speed level would be used. At the same time a frequency delay between the throws was reduced over time. The end result was a steady “throw ….. throw ….. throw … throw … throw . throw . throw throw throwthrow” that took about 90 seconds to reach it’s fastest speed. And at Speed1 the throw animations would have a solid 20 frames. By Speed5 they’d only have like 5 frames.

The difficulty ramped too steadily. It was predictable. You got used to the pacing of throw, throw, throw, so you could almost get into a hypnotic trance where you’re just kind of zoned out and not thinking/moving in-between throws because, well, why would you, your brain knows nothing is going to happen so you can chill after each throw. Also when the game got hit it’s faster speeds it became pretty much impossible. You could survive, in theory, but it was complete luck. Basically no one could get past 1:30-ish, and most of the time would be within 10 seconds of that time.

Version 2:

Here I added some staggering to the timing. Now the frequency had a % chance of randomly dropping down dramatically here and there. So instead of a steady rhythm you’d get “throw ….. throw ….. throwthrow throw … throw ….. throw throwthrowthrow ….. throw” I was just messing around but when I actually tried it out I found this helped get rid of that hypnosis feeling, because now you didn’t know exactly when the hazard was coming. You had to be on your toes at all times incase the hazard was immediately followed up by another hazard. This is kind of like that psychology experiment that’s something like a mouse can press a button to get food but the button will zap him…if it zaps him at predictable intervals he’ll adapt to that but if it’s totally random he’ll get paranoid and freak out and be scared of it. I’m probably butchering the explanation of how the experiment actually went, but I think the concept is similar to what’s going on here. Fascinating.

The totally random delay meant that occasionally you’d get “throw (nothing for 5 seconds) throwthrow (nothing for 8 seconds) throw, throwthrow, throw (nothing for 2 seconds) throw (nothing for 10 seconds), throw”. This meant big gaps at times. On the one hand this wasn’t a BAD thing per say, I found the pauses built paranoia. Like you KNOW something is coming, but you don’t know when so you’re on your toes going “c’mon… c’mon… I know you’re comin’, do it, DO it!!” The problem was these breaks happened too frequently and the intensity of actually dodging things died down because of them.

Version 3:

To solve the intensity dying I told it to clump between 10 and 20 objects together at a time before allowing a random-length break in the action. This created an oldschool arcade “waves of enemies” feel, where you have to deal with a handful of objects and then you get a break before the next handful. This was feeling really good, but I still had issues elsewhere in the design.

Common feedback I was getting was “I feel like I can’t do BETTER.” I narrowed this down to everyone hitting a “wall” where they felt their skills were no longer relevant and survival became pure luck. My thinking on this was that the highest speeds had too few frames to react to, so the game basically became unfair on Speeds 4 and 5 (ESPECIALLY 5). I’m tracking Flurry stats and this was reflected in them…I have a stat triggered every time a new Speed is reached and everyone could make it to Speed3, but only a few made it more than a few seconds into Speed4, and no one could reach Speed5. So essentially there was a wall people felt couldn’t be passed…so why keep playing the game, if there’s no way you can do better?

Another problem was that health items were too hard to catch. You COULD catch them if you were going slow, but if you were zipping fast across the screen, there’s only one frame where the Riceball/Sushi detect if you’ve caught them so unless the planets aligned just right for your timing to hit that exact frame, you’d miss. TECHNICALLY, you suck and are in the wrong…but I think the biggest thing I’ve been asking my testers from the start is “When you die, do you feel like “That was BS, no one could do that!” or “This game is broken!” or “I should have gotten that!!”, or do you feel like “Ahh, damn, I shouldn’t have gone for that” or “Oops I shouldn’t have trapped myself in the corner like that!”?”

I learned this from a friend’s game actually. When he released it the controls were very unforgiving, so people complained like crazy that they “should’ve” won. He ended up having to loosen the controls up a bit and let the player win little control battles that realistically they shouldn’t have. Once he did that, everyone loved the controls…they couldn’t tell that the game was helping them out a bit.

Also there’s a Deflection ability in the game that creates a burst of energy that deflects a hazard if it hits you. Essentially this is a panic button move that fills up every time you dodge 10 objects. Unfortunately the feedback I got was that no one really saw a use for this, it was faster/easier to just dodge instead of hoping to time this right. It was kind of like timing a Parry in Street Fighter III or a counter in Dead or Alive…you had to be a little TOO precise for it to be very benefitial.

Version 4:

When I realized the difficulty wall issue was the impossibility, I figured out that I was approaching things wrong with making the game more difficult later on. Instead of speeding up the actual travel motion of the hazards, I could keep them slow by removing the top 2 tiers of travel speed, but speed up the frequency. So now instead of 2 or 3 lightning-fast hazards that are impossible to dodge, you end up with a slower-paced “wave” of 4 or 5 hazards that you have to weave through the openings between them (like moving through a crowd without touching anyone). To fix the health items I set it up so if you’re moving super-fast, your collision box for health items actually widens a bit. On top of that, I removed the health items’ multiple speed levels so they’re ALWAYS at Speed1 no matter what the rest of the game’s hazards are doing. The end result is the game doesn’t just hand you the health items, but when you think you should’ve gotten it, you’ll find that you did. It feels WAY more smooth and less frustrating.

I also increased the length of time the Deflection is alive…instead of just lasting for one hazard that should be just about to hit you, it now lasts for a full 2 seconds, deflecting anything that comes near you, essentially giving you a burst of invincibility. Now it’s WAY more useful!

At this point things were feeling pretty solid all around, until I sat down and actually tried to survive as long as I could. The problem now is that once you get used to the top hazard speed which is fairly slow after removing the top 2 tiers of speed, the game isn’t very difficult. Now instead of everyone hitting a wall at 1:30-ish, there’s NO WALL at all. I was able to play for 5+ min without breaking a sweat and only let myself die because I got bored, and this matched up with my testers’ experience. One tester said “Around the 1:40 mark I start to feel less engaged, I think something needs to happen to make it more challenging without being impossible, or something ot mix up the gameplay?”. Now pile on 5 minutes of gameplay after that 1:40 mark and no way will you ever pick the game up again, it’s boring and unchallenging. Plus now you can catch all the health items pretty easily and the new Deflection lasting forever makes it so you’re never really in danger.

Version 5:

I toyed with a lot of ideas here. I thought about adding stuff…like what if the play area gets thinner over time (the roof on the edges lights on fire or something and it closes in on you) so everything happens in a tighter and tighter area? No, that means adding more art and a lot more code and testing out restricting the playfield it didn’t really feel any more fun. What about making the Deflect meter take longer to fill up as the game goes on so at first it fills up after 10 dodges, but later on it takes 30? No, then you need some indication to the player of what’s going on or he’ll wonder why his Deflect meter is broken and get annoyed when he expects it to be full and it’s not. Also I’m a crappy coder and couldn’t figure out how to do this nicely, haha What about allowing way more objects on-screen? No, that’s going to lag the game because it’s already pushing limits on some devices as it is with all the huge hand-drawn art.

Okay so I want to just work with what I HAVE. So I figure I want to combine a little of the hardness of Version 3 with the “my skill level makes a difference” of Version 4. I decided to re-introduce Speed4 (Speed4 and Speed5 were cut in Version 4). But Version 3 told me that Speed4 made things feel impossible. The solution? Speed4 in smaller doses! Now when Speed4 is reached, there’s a % random chance that it’ll drop to a random speed below it, even Speed1. When I was a kid I played Street Fighter II with a buddy all the time and one of the strategies we figured out was to throw “fast Hadouken, fast Hadouken, fast Hadouken, SLOWWWWWW Hadouken” The fast ones would get the other guy used to the timing and then the slow one snuck in there would trip him up. So that’s essentially what this is duplicating. As a result Speed4 is less unrelenting, and ALSO has become a little trickier psychologically…a double-whammy of goodness!

I also slowed up the health item frequency over time. So at the start there’s like a 10% chance of a health item being thrown. But as time goes on that % goes down.

Very few!! Things feel really tight and I think I’m getting close to the perfect difficulty curve. Beginners should be able to last a minute with no problem, intermediate players should get to around 1:30, good players will probably be able to make it to about 2 minutes, but only really skilled players will be able to make it past 2 minutes. And it feels like your skill level makes a difference now because it’s not so much about “play until it’s too fast for anyone to realistically survive”, it’s about “play until it gets smart enough that it’s trying it’s hardest to trip you up, but if you can stay sharp you could keep going”. This has effectively removed the skill wall that the earlier versions had, but also kept the gameplay around the 1:20 – 2:00 minute mark so it doesn’t drag out into 5 – 10 minute games of boredom.

Version 6:

This is what I’m working on now. I’m adding a few more nuances to it, with regards to predicting common strategies the player will use and giving the AI ways to counter them. It’s pretty amazing to see how huge and nuanced the AI code has gotten compared to the start. I honestly wasn’t expecting this at all, but the end result is that Version 5 has (and Verison 6 will have) a COMPLETELY different feel and level of fun than Versions 1 and 2.

I can’t stress the importance of playtesting enough. Even if all you’re doing is getting a handful of friends to play it and observing their reactions. I’ve noticed that the feedback you get tends to be a variety of things from each tester, but if you jot notes down about each point they bring up, then compare them all in the end, you notice common themes or patterns throughout the testers’ experiences and THOSE are the things you want to take a look at changing because those are what’s giving everyone trouble even if they each describe their actual issue a little differently…you have to read between the lines and break down “okay what exactly is causing this reaction across the board?”

- Quickdraw

Powered by WordPress | Theme: Motion by 85ideas.
©2010 Bulletproof Outlaws[ Back to top ]
Rss Feed Tweeter button Facebook button Reddit button Delicious button Digg button Stumbleupon button Youtube button