The Anatomy of a Shmup

If I haven't made it clear yet, I'm working on another shmup. This time, since I'm not restricted by a competition deadline, I've been paying close attention to the art behind creating shmups, both commercially and online. The big boys appear to be doing everything right. I only ever have a few nitpicks about them. If I ever feel like I don't like one, it's because of personal preference, not something that I can point out as being done poorly.

As for the indie shmups available for free or for a few bucks, they are hit or miss. Sometimes the design is ingenious, but the presentation is lacking. Sometimes the visuals are spectacular, but the gameplay is uninspired. Sometimes the game is pretty good, but could have been pushed further in various areas. There's a different reason for each game, but the importance here is that I'm taking notes on all of it.

Below I've gathered together a list of what I've observed over the months and years of playing. The ideas are in no particular order and only represent a fraction of my records. I thought I'd share them so you, too, can pinpoint a reason for any given game not being quite what you had hoped.

Keep in mind that not everything I say is required for every shmup. They each have their own place. Most of these notes are for scrolling and arena shooters, while some apply to any game or piece of art.

• Enemy bullets should always be visible. The bullets shot by enemies should be visible on top of explosions, power-ups, other enemies, etc. The point here is that those bullets are your primary reason for not beating the game. Any time not spent being able to see them is time not spent preparing to engage them. If a foreground object is going to obscure the view of play, it's a good idea to make sure no bullets are on-screen. The only exception for hiding bullets is the HUD; for this reason, the HUD should be kept to a visual minimum.


• Off-screen enemies should not be able to shoot. If the enemies aren't visible to the player, then how can a player even have a chance at feeling good about himself when dying from one of these bullets? This causes too much confusion, anger, and force quitting.


• All bullets should have a ricochet/splash effect when hitting something. Without some sort of "splash" or "pop" effect to show contact, it makes it feel like either the bullets have no effect or they're passing under the enemy/obstacle in question.


• Bullet collision should be accurate. This goes for any game where you can shoot and be shot at, but it's just a shame to be shooting something and having your bullets pass right by, or meeting the all-too-familiar death from a bullet that wasn't even in your area code.


• If the player's ship has a small hitbox, make it obvious. I seemed to miss this point with my last shmup. The key here is to let the player quickly know his boundaries of death when in a crunch. Sometimes only a few frames of opportunity are available, during which time it's essential to be able to see where your sweet spot is.


• The contrast between bullets and backgrounds should be high. This is something that's very important for survival, let alone for aesthetically pleasing visuals. An indie game for Dreamcast, Last Hope, had a special edition released that featured a higher bullet contrast. When Cave releases black label editions of their shmups, they oftentimes feature "darker background palettes". Also of note is that Cave has stuck with pink and bright blue colors for the bullets in all of their games. I guess they found the magic palette to make identifying bullets easiest.


• Enemies should show some sign of being hit. If an enemy doesn't flicker or shake or shoot sparks when being shot, I can only assume that it is invulnerable to attack. The whole thing doesn't need to flash white (it really hurts the eyes with bosses), but there needs to be some indication of it taking damage. On that note, if an enemy is invulnerable (shields are up, boss hasn't settled yet, etc.), don't change a thing about it. Some games let your bullets pass through during these times, which is also fine.


• Everything that is destroyed should explode. I'm almost completely serious when I say explode. As in fire and smoke. It doesn't seem to matter what the enemy is made out of; humans by nature love to see explosions and there's nothing more satisfying than watching something dangerous go up in flames. The Mushihimesama series gets around its insect/prehistoric theme by coloring its explosions blue, which in turn makes it look like a release of natural gas... or something. The point is, if you spend all that time pumping an enemy full of bullets, all of Newton's Laws say that it should explode into a fiery ball of satisfying pixelated splendor. And as far as boss explosions go, they better be a spectacular light show of gaseous fulfillment, including a screen-flooding flash of brightness that slows down gameplay.


• There should be a sense of flow to each level. If you fast-forward through superplays of various commercial shmups, it becomes very clear that the design of each level is structured to force you to want to zig and zag all over the place. It not only keeps your wrists happy, but it never leaves you waiting in boredom. Radiant Silvergun and Ikaruga both reward quick killers with additional enemies to shoot while waiting for the next section to arrive. It's okay to have nothing to do while being warned about a boss. For one, this gives your eyes a chance to focus on the text. Second, it allows you to build up whatever fear/confidence that its presence concocts in your body. Even arena shmups like Geometry Wars and Echoes provide a flow in where the enemies spawn.


• The visual style should be consistent through all levels, enemies, effects, menus, etc. The fact that this is something that every artist ever in history should be considering, it's sad to see it ignored so often. It's as if every 14-year-old with a wicked idea and limited freetime has used the same animated GIF of an explosion in his game. I was one of them. It's great as a placeholder, but if the rest of your game is composed of clean vector gradient fills, your explosion will not only look out of place; it will break gameplay. This happens a lot with uninspired menus as well, where a generic font is used without proper formatting. The end result can only make a player frown, no matter how spectacular the rest of the game looks.


• There should be "popcorn" enemies in every level. These are enemies that blow up (with an explosion) after being hit once (or very seldom). The key here is quantity. Popcorn enemies not only fill in empty holes of time between waves of more viable forces, but they also make the player feel like he's the coolest kid on his block (and if he's playing a shmup, he automatically is).


• There should be a way to save yourself in times of need. The most obvious method of saving one's life is the bomb. DoDonPachi also has a super/hyper beam. Ikaruga has homing lasers. Radiant Silvergun has a sword that slices everything in its path. The key here is that the player should be able to get out of a sticky situation. Most of these moves make the player invincible for a short amount of time, which in turn allows him to get out of physical obstacles as well as enemy fire.


• If an enemy appears out of thin air on-screen, allow time for the player to ready himself. Never have an enemy appear in the middle of the screen and fly off at full speed shooting everything its mother taught it. It's okay for it to accelerate to its destined speed, or wait a second before firing. There can even be an indication of its arrival before it even appears. Geometry Wars does this with particle splashes. Works wonders. Believe me.


• Enemy health should be either shown or predictable. Ikaruga shows the health of every enemy you start shooting at via a thin bar on the HUD. For games that show you nothing, you should be able to tell how long you need to be firing at an enemy before it's destroyed. Things like relative size or the presence of armor are usually good indications. If an enemy takes way too long to die, or if it explodes rather quickly, it will feel off, break gameplay, and your bewilderment over the developer's choosing of its health will put you into a stumper just long enough to be swallowed by an oncoming sea of bullets.


• The coming of a boss should be made clear. This can be done through a large warning sign, the sound of a siren, the sound of nothing at all, or simply a lull in enemies, signifying the coming of something large. If you don't know that you're fighting a boss, then you won't try as hard, and you also won't be as enraged when you come close to defeating it and ultimately die. Think of it this way: If you told Mr. Magoo that he just walked through a construction zone that failed its last safety and security inspections, he probably wouldn't be as emotionally struck as Lando Calrissian would feel if you told him that he just blew up the second Death Star and narrowly avoided being engulfed by its own flames (see? everything explodes). If you think that's a silly argument to make because Lando would have already known what just happened, you're right. That's the point. He knew the whole time that he was escaping certain death. The stakes were high and his adrenaline was pumping in return. The whole experience was a ride. And that's what a player needs to feel before the boss even shows its ugly mug.


• An unwanted sound should be heard when the player is hit/destroyed. The thought of losing a life and having to insert another quarter is enough to make a player avoid death, but the more that enforces that feeling of dread, the better. I think Squares 2 does this the best. The sound of that buzzer is the last thing I'd want to resonate in my ears, especially after having heard a looping sample from Daft Punk. Daft Punk!


• There should always be a way out of every situation. Here, I'm talking about designing the enemies and bullet formations such that there is definitely a way to get through, at least by the developer. I know players can lose focus and corner themselves into a tight circle of pain, but that's going to happen in any game. If you dodge the wrong way, you're only setting yourself up for failure. Half the "fun" of bullet hell games is learning how to manipulate the enemies into shooting such that you will have a measely crevice through which to escape failure. This is sometimes called bullet herding, which is kind of awesome. Even Space Invaders had this in the form of being able to hide behind your bases. That counts, right?


• Separate simultaneous bullet patterns should have different-looking bullets. The human brain is a beautiful thing, capable of recognizing complex patterns faster than any super computer today could ever hope to match (note: computers do not yet have hope). However, given the added sensations of stress, danger, and really fast bullets in large numbers, it would be such a great help if separate patterns had varied bullets. This can be achieved through color, shape, animation, and even rotation. The Touhou games are especially known for having hundreds of bullets on screen, each pattern distintively careening towards you at varying paces of fear induction.


• Camera-shake is a privelage, not a right. The effect always looks cool. Let's get that out of the way. The problem is when camera-shake is used when every enemy is destroyed, every piece of gold is collected, and every bullet is fired. Not only does this make for too much visual noise for the player's eyes (Cloverfield was under an hour for a reason), but it also dampens the effect. The less it appears, the more it'll mean for the player when it does happen. Trust me - less is more.

As I've said before, all of these suggestions are optional and in my opinion. They're all things that I've seen implemented beautifully in console/arcade releases and miserably emulated in free online Flash games. Since I'm making a free online Flash game, I'm going to do my best to maintain a level of polish and attention to detail that allows the game to stay together as a whole. Even a single out-of-place sound effect can ruin the entire experience.

To kind of drive these points home, I'd like to use the same identifying features from the screenshot of Ikaruga above and apply them to Space Invaders. Ya know, for fun.

It would be mean to point out the games that I feel could have been more successful, even by just following my suggestions above, so I'll just talk about the free shmups that did a lot of things right.

- Arcanacra: Excellent flow of gameplay, superb use of sound (The enemies/attacks are synchronized with the music), enemy bullets stay visible, enemies show signs of taking damage, there are popcorn enemies, and the boss explosion is worth the trouble. This is the best free shmup that I've seen do so many things so well.

- Cube Colossus: Excellent visual style (nice explosions), unique and useful control mechanic, bullet contrast against backgrounds, engaging sound design (especially when buying upgrades), ample warning before bosses and spawning enemies, and enemies have visible health and show signs of taking damage.

- Death vs. Monstars: visually and audibly unique explosions, a simple control mechanic that allows for quick and accurate aiming, popcorn enemies, a spectacular boss explosion, and enemy bullets that stay visible.

- Heavy Weapons: Great use of sound (especially of enemies spawning nearby), effects and menus match visual style of the game, and of course there are many popcorn enemies.

[cross-posted on Gamasutra] [continue]...

Lag, Control, and You

Talking about control isn't something that should be new to you. It's not some aspect of game design that slipped by your critical radar all these years and suddenly has been given new light. I'm sure you can still remember your thoughts when the Wii's controller was first unveiled; how impressed you were (and still are) at the SNES controller's simple, yet refined curves; how weird it was to see the Virtual Boy's double D-pad; how happy-yet-disappointed it was to see the Playstation controller evolve only under the hood - rather than on the outside - as each successive console was revealed. This is something that doesn't need to be said at all, as you should already know all of this. All of it. Still, though, I have things to say about control in relation to shmups. I'll try my best to stay on target.

First off, let's define something here: "control". Control is comprised of any and all aspects in games that allow you, the player, to interact with the game. The most prominent factors are some sort of input apparatus (e.g. a controller) and a monitor/television/Tiger Electronics LCD screen for viewing the status of a game. The factor I'm most concerned about is lag, which is no stranger to almost all other genres of games, especially fighters, racers, and FPSs.

Lag in itself means different things. We have:

• 1. Lag from human response time - This is how long it takes you to see something, calculate what you want to do, convert that to controller inputs, and make your body carry out those actions. This takes longer for more complex inputs (such as the infamous "The Mohawk").
• 2. Lag from controller-to-console-to-monitor - This is easily the shortest lag of all, yet it tends to gain the most hatred for ever existing. This also includes the online gaming route of controller-to-console-to-server-to-console-to-monitor.
  
• 3. Lag from game-related issues - Intentional slowdown, intense calculations, etc. This technically takes place during lag #2, but it deserves its own recognition.
  
• 4. Lag from Light - The time it takes for light to reflect off the monitor, travel through space, and into your retinas. I think I'll ignore this one.

And since we're all so visual nowadays, here are those same 4 kinds of lag, presented in one cohesive diagram:

Human Response Time Lag
In regards to response time, I don't have too much to say. This is the easiest lag to alleviate, though it takes the longest to achieve. The only way to make this lag go away is to keep on practicing until pressing buttons becomes second-nature. Luckily, practice in one game usually rolls over to other games, and even to other consoles. It varies from person to person. Some people are super quick at reacting, but aren't too accurate. Other people may take a few extra milliseconds to realize what's going on, but usually pull through. And of course there are people who are unfamiliar with their input device and have to look down at their hands more often than they look at the monitor.

Electronic Limitations Lag
Lag from the controller to the monitor is some kind of new-found beast in this generation. Back when we all had wired controllers and CRTs, no one even mentioned this. Now we've got Street Fighter IV vets who talk down upon wireless controllers' inferior speeds for sending input signals. There are forums dedicated to finding the right HDTV so as to minimalize the time it takes to process a composite signal into a digital format. Many HDTVs come with an option to switch to "Game Mode", which sacrifices cleaner visuals for less processing time.

As an avid fan and tournament-goer for Super Smash Bros. Melee, I can confirm for those out of the loop that pros will only play serious matches on CRTs. This is a fact across the United States and in international countries (I know you're there, Sweden, France, and Japan). Any HDTVs at a tourny are often used as the "just messin' around" TVs, the ones that are ignored during serious gameplay. Almost all players choose not to use the wireless Wavebird, despite its high review marks, to avoid any channel-switching shenanigans / battery-related tragedies. Does all of this attention to the saving of milliseconds make that much of a difference?

Yes. This is why MadCatz's billion-selling fight sticks have wires. They don't want any potential customer to doubt for a second that he or she will witness electric lag before purchasing one of these bad boys... especially when he or she will be dropping 150 big ones (i.e. dollars). Using HD cables on an HD console with a newer HDTV has become less of a problem. It's still there, but I feel technology is closing this short-lived chapter soon enough.

Intentionally Programmed / Intense Calculations Lag
When we press a button, we expect to see a result on the screen immediately (or rather, in such a quick manner that it feels instantaneous. Can't ignore physics after all.) If we press a button, wait, and then see the result appear on the screen, there had better be a good reason for it. Going back to Melee: if you try to jump, your character will first duck down and prepare for jumping, a Principle of Animation known as "anticipation". It makes the jump more believable, and only takes a few frames to accomplish. The game runs at 60 frames/second, so we're talking about a very short amount of time it takes to finally see your character leap into the air. This kind of lag is short enough to be ignored (...well maybe that's a poor example, as pros love to exploit this moment to wavedash all up and down their opponents' grills. It's hardly ignored at all and many players love to count frames to calculate how to achieve an added boost in--

Oh... right, shmups.

Intentional Lag in Shmups
The kind of input lag without immediate result that can really mess up gameplay can be found in many shmups. Let's look at Irukandji by Charlies Games. I hate to use this as an example, as I just love Charlie's other shmups to death, including the so-well-done (and 100% nsfw) Space Phallus, but I have a point to make here. The game takes place underwater. When you try to move, your ship takes a few frames to get up to speed, to simulate the water friction that would be found in such an environment. When you let go of movement inputs, the ship takes a few frames to slow down. This means if you want to move in a completely opposite direction than you currently are moving, then it takes about twice as long as usual to come to a stop, then start from rest and build that momentum back up to go the other way. The bullet patterns never get too complex to require intense weaving, and I totally understand that it's underwater and should feel like we're under water. But come on... this is a shmup.

I guess it makes little sense for a ship to be able to stop on a dime in any direction, but sometimes it's just needed. In shmups, it's almost always needed. And they're still tough as nails without any momentum lag. Plus, ya know, we have far more important things to complain about...

Here's a quick and dirty graph of the time it takes to reach full speed as compared with how much we should be tolerating it. I picked these games off the top of my head, so I can't exactly say they're accurately placed (especially since there are no numerical values for the axes). This graph is based simply off of my personal experience with them. Also note that the red bar exponentially reaches intolerability very rapidly.

Faster than Fast
It makes even less sense that most shmups allow your ship to move at full horizontal and vertical speeds when moving diagonally. The X and Y-axis movements are separate forces, so if you move diagonally, you actually end up combining their forces. Following Pythagoras, this means you'd technically be moving at ~1.414 times your normal movement speed. Ever wonder why speedrunners in FPSs move diagonally through worlds? Ever wonder why bunny hopping works so gosh darn well? Now you know.


That's all fine and dandy, but why don't more shmups force you to only move at your maximum speed? Many arena shmups impose this limitation, such as in Geometry Wars, but it's unheard of in vert and hori shmups. Why? Well, just think about it: As you wiggle through a swarm of pink death candy, you continuously hold [up] and sometimes press [right] to sneak through when an opening arises. If you could only move at maximum speed when moving in both directions, your vertical speed would slow down momentarily until you let go of [right]. This can very quickly become annoying and ultimately spell both your doom and a non-braggable NO RANK status at the leaderboard. It's cool with me to find this in arena shmups, especially when using analog sticks, since both your ship and the input device move in similar circular fashions.

Compensating for Something Small
It's possible to get used to sudden bursts and halts in speed as you weave in and out of certain death. It's possible to compensate for your ship's inability to change direction faster than in 0.2 seconds. It's possible for the mind to calculate everything happening on screen, tacking on an additional 0.2 seconds of leeway knowing that this one game was designed to feel more believable.

Back in the 56k modem days (33.3 for moi), we had to know when to let go of our sniper rifles' triggers in TFC, assuming the intended target would continue his trajectory and land under that big red spot just as the lag caught up and registered a hit. That was unnecessary skill, but we compensated. My point is, we shouldn't have to make that compensation, especially if the reasoning is because the developer(s) decided to make things not as responsive as they could have been.

True, there are plenty of instances where a little bit of intentional lag is passable, but when input-results become too delayed, the game isn't even worth getting good at. An exceptional exception is found in Mushihimesama Futari 1.5 (gazuntite) for Xbox360. The game intentionally creates gamespeed lag when too many bullets/killer insects are on screen (so as to emulate the arcade version). Your beetle-ship still responds faster than Lassie at an unsupervised well, but the whole game is slowed momentarily, allowing you to make even Neo a bit jealous.

Shameless Plug
And for those of you who were patiently waiting this whole time to make a comment about my own shmup's ship taking a little too long to move back and forth, I know. Trust me, I know. I obviously had my reasons, but I don't think they really make a difference at this point (especially after having rambled for much longer than was needed for something you already knew). If I ever make another shmup, rest assured you'll be stopping on dimes and moving at ~1.414 times your maximum speed all day.

[cross-posted on Gamasutra] [continue]...

How My Grandfather Won The War: Designing for One

Movies =/= Games
You can spend your whole life enjoying something made by others, but it's not until you try to make one yourself that you realize how much effort needs to go into it. This goes for any craft, job, or project. My main focus here will be on games, though all forms of entertainment are within acceptable bounds for my thoughts. I mean, it would be so cool to only have movie directors write reviews of their peers' works, but then they'd be talking about aspects that we, as an audience, wouldn't really appreciate/understand. That's why I will accept Rotten Tomatoes and my local newspaper for what they have to say, since they represent the common movie-goer. Though as with anyone's opinion, it's just an opinion.

There are a lot of factors that go into enjoying a movie or not. The experience of movie-watching has enough to do with the surrounding environment, people, and events leading up to that 2-hour moment as the movie itself. Personally, I thoroughly enjoy the Super Mario Bros. movie each and every time I see it, despite the horrible reviews from critics and Bob Hoskins himself. I was a kid and anything magical that had to do with my Nintendo was a winner in my book.

But that's movies. One needs only a comfy seat and attentiveness to let the magic happen. At the very least, every person that watches a given movie is (more or less) watching the exact same thing (there are matters of screen size and audio fidelity, though insignificant at best). Such is not the case for games. Games are designed to follow a certain guideline of events and plots and adrenaline moments, but no two players are going to have identical experiences (or rather see the same series of events). That is precisely why a review of a game is more like one account of an experience out of many. I suppose you could count the different experiences that individuals would get out of a single movie, but at least they all watched the same thing. A novice to racing sims who constantly crashes into walls will dislike the game for entirely different reasons than a veteran who looks down upon the lack of tune-up features and varying strengths of snow tires.

The Competition
Thus we have finally arrived at what you came here to read: a brief peek into my mind when creating my recent entry for JayIsGames.com's CGDC6, How My Grandfather Won The War. I had been meaning to enter the prior competitions but had too much schoolwork on my lap to convince me I could complete whatever I designed. This time, school was summed up into a diploma on my wall, and my 9-5 job had yet to show its menacing cubicle-shaped face. The time was now (i.e. then).

The steps toward creating the game out of thin air were a matter of balancing two factors: the theme of the competition and what I could actually make. The theme was "explore" and I was in the mood to make a shmup (shocker, I know). I figured that the idea for scrolling across a plane wouldn't cut it for exploration, and an arena shooter would firmly leave the player in one area, so I decided to create a mechanic that would reveal an alternate vision of the world through which the player would travel. To simplify that thought: The player shoots something that opens up paths to survive. In essence, the player would both be exploring how to get past each obstacle, and would be uncovering some visual piece of information to make sense of the world.

I wanted this mechanic to not only be in the spotlight, but to also be one of the few things to even worry about. That's why I chose to not have the player be able to move horizontally, so that more brain power could be used to focus on shooting. I also removed many of the standard conventions of shmups, including bombs, scores, and upgrades. The only HUD in the game is a single bar that decreases as the player rapidly shoots. Otherwise, the gameplay itself is the star of the show. In essence, this shmup was more of a dodge-em-up, in that you cannot destroy obstacles directly with your shots. You can only evade.

This made for some very fun brainstorming. Each of the obstacles in the game were specifically designed to cater to a different type of necessity of avoidance: the spikes are static and only appear at the edges, the flames create a vertical wall, the swinging tentacles create sudden and immediate danger to their left and right, etc.


Stream of Consciousness
The story itself was loosely based after the emotions I felt as a kid when hearing stories from my grandfather. They were outlandish, unpredictable, and quite enjoyable. The build-up of the story was so fun that it oftentimes made the ending lackluster in comparison, perhaps because I knew it was over at that point. This retelling of my childhood emotions through stream-of-consciousness is why nothing in the game really belongs together: orange spiky bursts followed by ambiguous tentacles, followed by a wave of shurikens. It's also why I chose to go with a cardboard theme, to solidify the child-like feeling of the game, and to hopefully endorse an exploration. That, and I tried the style before and really enjoyed it.

There was just one problem: the game was really hard. And even worse, I had designed it exactly as I had envisioned, leaving me at those dreaded crossroads of changing the gameplay to find something of equal merit that would satisfy a more acceptable difficulty. Now, this type of dilemma is no stranger to me, as I spent 18 months revising my Computer Animation thesis at Ringling until enough people were satisfied with it (basically, just the faculty, as friends always "loved" it and my partner and I were concerned enough with meeting deadlines while making changes and maintaining our original pitch as much as possible). The point is, change is good, and it's especially good when you have more and more people test out your game before it gets sent out to the masses for rapid-fire rating and [dis]approval. My game most certainly succumbed to a lack of playtesting before submission, resulting in me taking the easier, less effective route: build around the difficulty and cater to the skilled.

I realized that eventually, the player would run out of "juice" for shooting and inevitably be forced to dodge the oncoming obstacles manually until the meter refilled enough. Since I had no way of knowing where this would occur for each player, I made sure to design the entire game so that it could be flown through without shooting once. That's where I got the idea to reward the player for beating the entire game without shooting (a feat that, one month after submission, has been achieved publicly by less than a dozen people).

The majority of players were getting stuck in the first few seconds of the game. The reason? A life system that starts at 3, cannot be replenished, and forces the player to start at the beginning of the game after 3 deaths. Couple this with a foreign shooting mechanic (new to me, too) and it was a recipe for limited progress. I at first found this "within acceptable bounds" since the game takes less than 6 minutes to play from start to finish. The community at JIG was overwhelmingly verbal about this issue, so I submitted an update that would only set players back to the latest checkpoint upon game over. On top of that, the first two deaths became freebies, as the player would continue from the point immediately after the obstacle that caused his or her death (sans the boss battles).

My Personal Bruce Willis
I immediately saw improved results from players who persistently attempted to get through it, and I appreciated their efforts that much more. I knew from the beginning that this game would not be enjoyable by all, playable by even less, beatable by less than that, and only "truly" beaten by a select few. For some reason, I liked it this way. It reminded me a bit of Mr. Glass from Unbreakable, a villain who would ceaselessly create national tragedies to find the one man who was his opposite, a man that could not be broken (oh, right... spoiler alert back there). Though I really shouldn't gloat about feeling like an antagonist, especially in a medium where people come to get away from the stresses of life. I did get hooked on the feeling. I even designed the music and sound effects to promote simple, enjoyable gameplay in order to lure in the masses until I would find my Bruce Willis.

I did eventually find my Bruce Willis, though he exists in any player who completed the game without shooting once. One JIG member even went so far as to make an entire walkthrough of the game, explaining the tricks to getting around every obstacle, by both shooting and by purely dodging. This intentional difficulty was a risky move by me, especially for a competition where you want to receive the best judgment possible, by both the community and the judges. I did end up winning 3rd place though, and almost every person was impressed with my visuals (thank you, BFA ♥), but very few could say kind words about the gameplay, which is the most important aspect of any game.

The good news is that I agree with them. One member pointed me to a fantastic post at RetroRemakes that basically says, "There is no such thing as too easy." Some games are intentionally designed to be as difficult as possible(nsfw). Others do it unwittingly. And then some games want it to be difficult, but not immediately apparent. I do know that there is a small niche of players who crave masochistic gameplay, but I probably had no business trying to find them at a casual games website.

Oh, and the bad news? It's actually good news for me, but bad for "fans" of my game (you do exist, you do exist...). I'm not going to make the necessary changes to this game, not going to make it more for the masses and ultimately enjoyable by many. It was a competition entry, it served its purpose, I finished it, and I have other games I'd like to create. The good news is that I've learned my lesson on catering to varied skill levels, and am more than happy to (and looking forward to) allow the casual player to jump in and enjoy my work as much as those few dedicated individuals who would not stop at "Try Again".

Feedback Is Everything
The positive, constructive feedback from the JIG community (and partially from ArmorGames, many of whom were from JIG anyway) has been a wonderful help in pushing me in the right direction for my future work. I've had some people applaud my efforts, many more explain why it needed much improvement, and some who are absolutely convinced that it does not follow the theme of "explore" one bit. They all have valid points, and I thank them all for voicing their meaningful opinions, but no comments have as deep an impact on my future work as the collective bunch of 13-17 year olds (I checked; a few are older) that have such helpful words to share as:

• "3 words, I... hate it"
• "terrible game. one of the worst I have encountered on this site"
• "Did your grandfather program this too? 0,5/10"
• "Sometimes 'original' doesn't mean much. Take this game for instance, sure, it's unique. A beautiful unique turd. 2/10"
  
• "-99999999999999999999999999/10"
  

Seriously, if I can win over people like this, then I've gotten everyone else as well. Besides, If I can't look back and laugh at stuff like this, then no one will end up having enjoyed the game. ;]

Also, here's a review from JIG. Now, to work on something new.

[cross-posted on Gamasutra] [continue]...