The Final Crawl

So, my game Starlight is pretty close to being done. Here’s what I have left to do:

1. Lower the file size
2. Fix the game-breaking saving glitch
3. That’s it!

Adventures in File Size

So, I’ll be submitting Starlight to the XBox Indie games marketplace. That means a lot of things, but in this context it means that my game can’t be any larger than 150 megabytes. This was an especially harsh realization considering that my game was about 270 megs. Whoops! There were two big areas I could improve on: The intro, and backgrounds. The intro to the game is a 89 frame long animation. The animation is comprised of 1200 X 700 .png images. All together, the images added up to about 62 megs. It looked gorgeous, but was absurdly large. The answer to my woes, I hoped, would be converting my flip-book-style animation into a video. After downloading some freeware that could convert images into a video file, I discovered that an .avi version of the intro was about 300 megabytes. Awesome. I did make an interesting discovery, however. After creating a .wmv (windows movie file), the file was only 2 megabytes. Awesome! Also, .wmvs are the preferred file type for XNA game studio projects, which is what I’m using to create Starlight. XNA 3.1 supports video format, which is surprisingly easy to use. You can load up a video in a very similar way that you would load a texture, and the video player has it’s own set of easy to use methods. In short, it works very well to cut down the file size, and the only downside is the reduced quality.

There are 88 more just like this one

I’m also going to be lowering the size of many of the background textures and other large images. The smaller quality should be more than enough to get me bellow 150 megs. The estimate so far is about 80 megabytes, but it might end up being slightly larger.

I hope you don’t plan on saving that game

Because you can’t. Currently, there is a glitch in Starlight that erases every game save file as soon as you quit. It’s a problem. Originally, I had an issue with the save files, where the game would crash every time you tried to do a qicksave. After a series of headaches, I was able to figure out that the problem stemmed from trying to serialize booleans, of all things. The problem was resolved when I simply changed all booleans to integers, and read the variables as 0 and 1 instead of true and false. Simple solution. However, after adding some more arrays of integers to the save data structure, the problem reemerged in full force. I have yet to figure out what is causing it this time, but to get around the issue temporarily, I added try & catch blocks, which simply put “catch” the error and erase all the data to prevent a crash. Seeing as how people may want to save their games, I’ll get to work debugging this issue.

Whew!

There are still a few roadblocks, but the game is very near completion. I’ll keep working on it, and try to release more information about the game (trailers, website, etc.) when I’m able. Thanks!

Weekend Update: T-Minus 4 Weeks

This is a quick weekend update following the progress of my upcoming XBox Indie game, Starlight.

Menus

Well, the largest amount of development time this past week has been dedicated to the menu system. Building it wasn’t the easiest task, but this far into the project I’m not as worried about efficiency. Ideally, I would have created a better system for creating the menus early on, but I’ll just have to save that for next time. I still need to create the content for the menus, but the shell is completed.

XBox 360

One pretty significant step I made this week was porting the game from my PC to the XBox. Before now, it’s been a PC game using an XBox controller, but because it’s a release for the Indie game service, I had to bring it over. Here’s how it looks so far:

Ta-Da!

Only the very basics are done, and there are still a lot of display issues to solve. The menus, for instance, take a pretty big hit:

whoops

As you can see, the entire bottom is cut off. I’ll need to take a pretty in-depth look at how the sizes and proportions are initialized to fix this issue. Once that’s done, I can start thinking about working on other XBox specific functions, such as memory unit/hard drive access and saving.

Weekend Update: T-Minus 5 Weeks

So, I thought I would keep everybody up to speed on exactly what it is I’ve been, and will be, doing up until the release of the game. I’ll go ahead and sum everything up at the end of the week. So, here’s the first update.

Ditched Some Stuff

I got rid of fans and one of the levels. I elaborate quite a bit here.

Walls, Walls and more Walls

All of the walls in the game were causing some pretty annoying glitches regarding the enemies. These glitches caused the enemies to walk straight through locked doors, and walk through brick walls if they were stacked on top of each other. My locked door collision code was just pretty shoddy, so I tightened it up enormously. The other glitch was also caused by my collision code, but in a less obvious method; the way I programmed the collisions, I made sure that if the enemy was walking on the top of a wall, it was impossible for him to be stopped by the right or left side of the wall. As it turns out, this was a pretty stupid thing to do. I programmed it in because I knew that as long as the enemy was on top of the wall, they couldn’t possibly walk into the base of it. Well, when I stacked walls on top of each other, the engine was letting enemies walk on top of one wall, while passing directly through another wall stacked on top. I simply deleted this code, as it was completely and utterly unnecessary in the first place. Lesson learned.

No Turning Back Now

This problem related more to the design than the programming. My problem was that while designing the levels, I never really considered the fact that players might want to turn around and backtrack. So, in my designs, it was impossible in some places for the player to go too far backwards, usually because of a wall that was too high to pass. I thought about deleting obstacles as you tread far enough away from them, but ruled out that plan for two reasons:

1. If the player wanted to go backwards immediately after passing a high wall, they would first have to walk forwards a bit to erase the obstacle. This is blatantly terrible design.
2. It would seem off to the player if, all of the sudden, solid objects just started vanishing off-screen. It would create an environment of uncertainty that I wanted to steer far away from.

So, my next thought was to put a warp at the end of the level, so you could continue from the start if you missed anything. The problem with this was obvious: If the player only wanted to backtrack behind an impassible obstacle that was close by, they would have to continue all the way to the end of the level just to move back a few yards. Yuck. My answer was more of a brute-force solution. I simply went back into the designs, and added platforms and springs to help go past the high walls. What can I say, it worked out alright.

Spawn Timer

The next thing I wanted to do wasn’t necessarily solving a huge issue, but adding a small element to the enemy’s spawn points. The spawn points of the enemies are these small teleporters placed around the levels. The warped in enemies after a short time, and only if the player wasn’t standing on it (because nobody wants an enemy spawned directly into their face). My only concern was that players would be standing close to spawn points, but not on them, so that when enemies warped in, it would catch the player by surprise and kill them.

So, what I did was add a small red rectangle to the base of all the teleporters. The rectangle started out invisible, but heated up red as the enemy was about to appear. It wasn’t something stupidly obvious, like a number timer, but got the point across. No red bar = safety. Glowing red bar = MOVE IT!

Background and Floor Editing

I made some adjustments to the floors in the game, which took a lot longer than it probably should have. My first problem is that the floors didn’t scroll across the screen, so I had to go in and completely gut-out the old floor code and redo it, which was a pain. After that was finished, I changed the texture for the second and third worlds to be more fitting (sidewalks for the city, etc). I also enlarged some of the backdrops so that they would cover the entire level.

Starting to Flesh-Out the Menu

This is most likely my biggest obstacle ahead of me, but I’m beginning to chip away at it. Essentially, I have three main menu options: Story, Extras, and Options. This week, I finished the menu for “Story”. There isn’t a ton to say about it, but it was certainly my biggest task. In place of some explanatory text, I offer a screenshot.

Whew!

Alright, that’s about all of the major changes for this past week. I may have done some other changes, but I think this covers the basic features of the new build. Thanks for keeping up, and stay in touch for next week’s edits.

Learning Curve

Okay, so today I thought I might talk a bit about learning curves. First of all, what is a learning curve? Well, essentially, it is a generalization of the skill progression of the player through the game. The quicker the graph rises, the quicker player skill increases. What developers are going for typically, is a perfectly straight, even line. In practice, it doesn’t usually work out like that, but for many games (not all) it is a good baseline. Here is an example of three curves and what they mean.

So, you can see in the graph above how quickly player skill rises. Near the beginning of the game, their skill increases very rapidly, and as they near the peak, learning slows. This kind of curve means that the game is probably very easy, and as a result the player gets very bored. This is because they have stopped learning, and when a player stops learning, they are no longer stimulated. This progression is usually associated with very simple games, or kids games. Also, those numbers aren’t really any kind of unit of measurement. You don’t really measure skill on a 1-100 point scale; the numbers are just figurative. Here’s another graph type:

Alright, so this graph is a counter-point to the first one. It’s a very slow skill progression. Check out how slowly the player gets better at the game. Now, this can be a good thing, sometimes. As long as the player is being challenged (very greatly in this case), they will be interested, right? Well, there is a very nasty side-effect: frustration. This doesn’t mean that hard games are bad; quite the opposite! Hard games are stimulating, but if the challenge is too great, they become frustrating. If a player is frustrated too much by a game, they quit. What it comes down to is this: Is the gain from progressing worth the effort the player is exerting. If the answer is yes, they keep playing and slowly get better. If the answer is no, they throw the controller at the TV and stop forever, IE: Me playing most FPSs. This is why most non-gamers (and unskilled-me) can’t play many modern multiplayer shooters. The other players can be far better, making the skill curve look like the one above, and causing frustration. And if the player feels like it isn’t worth the trouble of getting better, I quit. Err, I mean, they quit. I’m not a quitter.

Okay, here’s the ideal graph. The player is constantly getting better, but facing a fair challenge as they go along. Games like Portal stick quite closely to the curve, always teaching the player about new game elements (momentum, blocks and buttons, turrets) that will challenge them, but they have the tool set to conquer the game. This is why Portal, and other games that stick around the curve are so great; they have mastered player progression. This might not be ideal for every game (casual games like peggle, or challenge-based games like mega-man), but games that stick to the curve are nearly guaranteed to keep the player interested. So when people (myself included) talk about Portal as being near-perfection, this could very well be why.

So, that’s my schpeel, I hope the graphs didn’t make you fall asleep. Next time you play a game and are getting bored, or frustrated, think about the difficulty progression! It’s interesting to think about the advantages and disadvantages to an easy game, or a hard one. Because while the straight-curve is often the best, different games might use different methods, and there aint’ nothin’ wrong with that.

Video: Starlight Preview

Here’s a quick look at my XBOX Indie game, Starlight.

GUI Thoughts

I’ve been thinking a lot about the GUI (Graphical User Interface) lately, which is a lot less complicated than it sounds. It basically means the menu. Most people just kind of dismiss this, thinking that the main gameplay design is far more important. Well, it is far more important. That’s as true as it gets. But that doesn’t mean that the GUI should be ignored. Many people who play games (myself included) don’t ever think about the GUI at all, unless it becomes an obstacle between them and the game. Most PSN, Wiiware, or XBOX Arcade games have a very simple menu system, because they usually don’t have as many parts as a retail game (with many exceptions). The menus don’t add much to the game, or take much away. When the GUI is poorly designed, or unintuitive, it makes itself known. Ever had an experience of wrestling with a menu? Perfect Dark Zero comes to mind, but there are many games with bad interfaces. Non-RPG players may have been lost in the Oblivion or Borderlands menus, for example. Maybe not everybody, but the main issue here is when the GUI stops the player from being able to play the game.

Most XBOX Arcade and PSN games have very simple interfaces. You never really have to think about them.

Braid manages to bypass this problem entirely by starting the player smack dab in the middle of the game. This is a great approach, because again, the menu shouldn’t come between the player and the experience, but it doesn’t work for every game. Halo, for example, has more than one main mode (multiplayer and singleplayer), so this approach would not be ideal. Tons of games fall into that category, and I’m sure you can think of ten right here on the spot. I mean, essentially anything with multiplayer or more than one main mode will require the user to make some kind of choice before they start playing the game. The difference between a good GUI and a poor one is the usability, intuitiveness,  and speed at which the user can access whatever feature they want. If the player needs to press the A button 17 times to get from the boot-up screen to the game, you have an issue. Is it possible to get rid of the GUI all together? Sure. Atari games, for one, but there are many times when it might be appropriate.

Uh.... what?

So, this was only brought to my attention because I’m working on the GUI for my game, Starlight, and I thought I might explore it. It’s difficult to really dive in deep with the topic, considering it really is just a menu. Is there a way to make GUIs more interesting, both visually and design wise? It’s a cool idea to explore. My goals for the Starlight interface is to provide a way for users to get into the game very quickly if they wish, to find any options very easily, to have the menu be visually unique, and to match the style of the game.

So there you have it. Menus. Pretty exciting stuff, right? It’s not very hard to make sure that a menu works well and preserves flow, but because it isn’t as importaint as gameplay or something, it’s easy to brush it off and end up with something that confuses the user terribly. Just like any other aspect of game design, you should probably put some thought into it.

It’s Hard to Say Goodbye

Sometimes, you just have to let it go. What am I talking about? Well, I’ve had an interesting experience working with Starlight today, and I thought I’d share. Often in game development, certain features planned in early versions of the game fail to make it into the final version, due sometimes to time constraints, or maybe because the concept just didn’t pan out like the developer had hoped. I was “lucky” enough to experience this with my game, Starlight. Twice, actually.

Level 103

No, there are not over a hundred levels in Starlight. There’s twelve. But one unfortunate level was cast aside during play testing. Here’s the story: I created three levels during the first stages of the game. Level 1 was based off of the prototype level that proved the concept, level 2 implemented some of the new features I had thought up during programming the engine, and level 3 was impossibly difficult. One of these things does not belong. Most people who played level 3 couldn’t get past the first puzzle, which was a problem considering how early it was in the game. So, not knowing how many levels I would put into the game at that point, I dubbed it “Level 103” and thought about putting it in a later level, where the difficulty would make sense. Well, the way things worked out (mainly the way the gameplay mechanics changed with each passing world), it didn’t make much sense to include the level in the final game. It’s in the programming, sure, but it wont be accessible in the final build. It hurt watching this level fade away; I put hours and hours into it. Pushed my brain to the very limits to conceive those puzzles. I was very fond of it, actually. But there comes a time when you, as the developer, have to take a step back and ask yourself if it really fits in the final product. As it turns out, it didn’t fit. You will be missed, level 103.

Blowin’ in the Wind

Level 103 wasn’t the only thing to be kicked from Starlight. When I was first programming all of the objects into the game (enemies, razors, platforms, springs, etc.) I thought it would be cool to include a “Fan” object, which, when stood over, blew the character high into the air. I thought it was pretty neat. In fact, I was a pretty big fan of it. You could say that this feature blew me away. Alright, I’m done. I promise. So, like I was saying, I thought up some cool puzzles that used the fan, and began implementing it as early as level 2. The problem was… well there were a couple problems.

1. The way the fan blew you into the air was unpredictable. It often lead to danger because of it’s random nature.
2. I hardly used it. Seriously, I only actually used the thing three times in the whole game.

The Latter reason ended up being the deciding factor in pitching it. It was more trouble than it was worth to try to polish and fine-tune it. Also, I thought that it was pretty useless to teach the player about these new and strange objects, that, after they maybe understood, never had to use again. It was a waste of the players time and effort, and mine as well. Do the spinning blades hurt you? Is there a limit to how hight they blow you? These are questions that would have been a pain to answer through design, so I took out the fans and the game is better for it.

RIP fans, you wont be missed

No More Puns. I’m Serious, guys

All in all, it was a very smart decision to cut these elements from the game. A large developments studio might not have any issues with this, considering they are on a tight schedule, and “higher-upps” make most of these choices in the end. However, for the indie developer, it might be hard to understand that something needs to be cut, especially if they’ve spent so much time into creating these elements. Really, all it takes is a step away from the game, to view it in it’s entirety. Does the element fit, and more importantly, what does it add to the experience. If your answer is “nothing”, then that specific section of the game really has no business being there. It’s hard to do, but can drastically improve the quality of the game, as seen with level 103. it’s kind of weird to do an entire post about taking things away from the game, and not adding anything, but cutting bad features can often open up the door for better ones, so come on, developers; make the right choice.

Violence in Video Games

Do video games cause real-world violence? To many, the answer is an obvious “yes.” Unfortunately, misinformation and ignorance fuels the arguments of the uninformed, and causes them to strike out so harshly against something they hardly understand. Parents are very familiar with movies. They will let their child watch a Disney movie, and stop them from watching SAW V. Parents have a deep understanding of the film industry’s products, and understand that kids aren’t really supposed to watch these R-rated movies meant for adults. They understand that watching somebody wield a gun in a movie won’t necessarily cause the viewer to dart to his nearest gun store. Video games aren’t as familiar of a medium, and so parents can’t really make those connections. This is unfamiliar to them, and probably somewhat scary as well.

The idea that violent video games cause actual violence was brought about largely by the school-shooting at Columbine High School in Colorado, simply dubbed “Columbine.” The actions of the two students who went on the killing spree, Eric Harris and Dylan Klebold, were explained to be caused by the excessive amounts of video games that they played. People believed this for 10 years, mainly because that is what was explained by officials such as Jack Thomson, active video game protester and now-disbanded layer who has yet to win a case. The word of video game caused violence spread like an airborne disease, and many began to support anti video game efforts without a full comprehension of how kids react to them. It wasn’t for 10 years that researchers actually looked deeper into the Columbine case and actually produced accurate results. Peter Langman, author of Why Kids Kill: Inside the Minds of School Shooters, discovered that the two students had deep set psychological issues before video games even became a factor. He tells that “These are not ordinary kids who played too many video games. These are not ordinary kids who just wanted to be famous. These are simply not ordinary kids. These are kids with serious psychological problems.”

Violent crime rate. The emergence of violent video games has certainly made a big impact on crime... right?

Whether or not violent video games cause real-world violence has researches and hobbyists alike on a frantic and furious mission to discover the truth and argue their case. John P. Murray, a psychology professor at Kansas State University, says that a group of kids playing games for a short span of time caused “an increase in emotional arousal – and a corresponding decrease of activity in brain areas involved in self-control, inhibition and attention.” When the kids where subjected to short clips from the boxing movie “Rocky IV,” the same feelings and emotions were shown at roughly the same scale. So these games, that arguably cause the youth to commit such nefarious acts, are about as likely to actually cause conflict, as say, Rambo. A researcher at England’s University of Essex, Patrick Kierkegaard, comments “Violent crime, particularly among the young, has decreased dramatically since the early 1990s. With millions of sales of violent games, the world should be seeing an epidemic of violence. Instead, violence has declined.” In fact, juveniles who commit acts of violence often consume far less media than most average citizens, according to a recent study.

Many adults consider video games to just be a mindless release of emotion and anger, but they what they are ignoring is far more important. Many researchers and authors, from Ralph Kosher to Ian Bogost, talk about the positive effects of video games on not only children, but adults as well. Professor Oscar Williams at the University of Illinois, says that “Games are about solving problems, and it should tell us something that kids race home from school where they are often bored to get on games and solve problems. Clearly we need to capture that lightning in a bottle.” He also discusses the ability of games to teach, when saying “How often can someone direct and coordinate a group of eight or 40 real people to accomplish a complex task, as they do in these role-playing games? That’s a real skill.”

Zelda, Gameplay Progression, Recurring Elements in a Series, the Human Brain, and Video Games

One of Many

The Nintendo DS has seen the release of two Legend of Zelda titles: Phantom Hourglass and Spirit Tracks. As always, they are excellent games with great design, but not many would argue that they are better than their predecessors (mainly the critically hailed Ocarina of Time and Majora’s Mask on the Nintendo 64). After getting a chance to play Spirit Tracks, I got to thinking about what made Zelda such a great series, and why we love the “classics” on the Nintendo 64 more than the newer titles. It seems to be a generally accepted assumption that long series such as Zelda will never return to their “glory days.” We remember the golden age of games, which never seems to be a single time period depending on who you ask. Logically, no series is condemned simply for being long-running, and so I became curious why some series reach a peak, even when they use the same tactics and designs as the games that came before them.

In The Legend of Zelda: Spirit Tracks, you go about the world collecting various items to aid you on the long journey ahead. One of the items featured in the game is called the “Spirit Flute”. The player can learn songs to play on the flute which open up new areas of the world, and helps with smaller tasks as well. The Legend of Zelda: Ocarina of Time, a game that was released about a decade earlier, featured nearly the exact same item, but in the form of an ocarina. You used the ocarina to cause special events to happen, and open new paths and trigger changes in the environment. This gameplay piece isn’t exactly fresh, but that much is obvious. Why should using the same idea worsen the game? It worked then, shouldn’t it work now?

Well, the main issue here is a lot more complex than it may seem. The problem isn’t simply that the same idea is being used over again, but rather the complications that arise from reusing ideas. In Ocarina of Time, the Ocarina plays a very vital role in the story and gameplay progression. The story revolves around the progression of time. Without going into too much detail, the Ocarina is used in the game’s story to give the main character, Link, a method of overcoming the obstacles that lie in his path, while tying together multiple characters and plots. But the instrument serves not only as a story device, but as a gameplay device as well. The player can use the Ocarina to open new paths, communicate with other characters and manipulate the world around them. The wonderful  thing about this is how connected the gameplay ideas are to the story, making the player very attached to the Ocarina, and giving it real weight in the plot. Part of the reason that this mechanic felt so embedded in the experience, and the reason the world was so immersive, is because of this integration of the story mechanics into the gameplay.

Unfortunately, the strengths of Ocarina of Time are the weaknesses of Spirit Tracks. Before I get into Zelda in particular, it’s worth going over what it even means for a game to be in a “series.” A series, as defined by video games at least, is a chain of multiple separate experiences held together by recurring ideas and motifs, such as characters or gameplay elements. However, one very important balance to keep is the amount of new content versus recurring content. Most games in a series stick to a pretty simple format: create a game, and add new characters, areas, weapons or what have you. A sequel also allows the developer to improve areas of the game that need it, and to add new and interesting elements. A sequel cannot simply be the same game in a new light. What I mean by this is that a game cannot simply present different scenarios in place of new ones. A game that is merely different than its predecessor is flawed in concept, because it means that the gameplay elements are interchangeable. Swap out an old character for a different one, or replace one world for another. Without fundamental structural changes, the game will simply not ascend to as high a level of success, or even fail completely. The reason for all of this is really not very complicated. Our brains require stimulation, in some form or another. When we learn something new, our brains are happy; when we sit facing a wall for three hours, our brains are sad. Basic human instinct has us constantly craving new materials and thoughts. This is why words like “repetitive” and “monotonous” are so negative; we don’t like to repeat an action over and over and over without any progression or mental gain (some repetition is very good for us, but only when we are learning from the process).

So, what does any of this have to do with video games? Well, video games are essentially learning devices. They teach us about morals, teamwork, or blowing zombies’ heads off. We play games for many reasons, but the one I’m interested in for the time being is the fact we learn from them. Of course, this is at a very basic level, and games being fun, interesting or imaginative all stem from that idea of learning. This isn’t true for everyone, but most people only pay attention to a game as long as they’re learning. Remember, learning in this context is a very general concept, and can be applied to many different parts of any game. You’ve no doubt (assuming you’ve played a game or two in your time) felt the repercussions of when developers forget (or never knew) this fundamental idea. You know it in the form of boredom. When our brains lack the stimulation provided by learning new concepts, boredom kicks in to tell us we’ve had enough. Summing it up, we like patterns, but not repeated experiences to the point that they just become simplistic and monotonous tasks.

Most games fall into this trap before you even have a chance to play through them, but as far a The Legend of Zelda is concerned, it’s a bit of a different story. The Zelda games manage to stay fresh throughout the experience by giving you new obstacles to tackle, and new tools to overcome these challenges in new ways. However, The Legend of Zelda is no longer a single game; it’s a series. And therefore, anybody who has played through the games will begin to notice this gameplay progression style repeat itself, making the reemerging pattern blatantly obvious. Many elements of the Zelda games carry over into the sequels (such as items, characters and dungeon puzzles). Yes, after playing through three or four Zelda games, and using the same item to accomplish the same task in each one, it does tend to feel like a repeated experience. But this isn’t really the biggest issue. Sure, you might be using the same weapon in three different games, but often the setting, dungeon progression, puzzles and surrounding elements (dungeon themes, such as rising/lowering water levels, or wind) make each scenario seem somewhat different. It doesn’t help that so many areas of the game are recycled, but at the same time, each successive game manages to bring something new to the table, sometimes making this less of an issue, or at least disguising it. Reusing specific elements of the previous game isn’t actually the largest recurring parts of the series. The bigger problem, at least in my opinion, is not the specific gameplay tools that appear time and time again, but the way they are presented, and how it plays into the overall flow and progression of the game.

When one plays a video game, they complete a series of objectives (whether it be complete a level or mission, or just move forward) and progress further into the plot, or just further through the experience. The way the player continues through the game is called the gameplay progression, and varies quite a bit from game to game. When video games first emerged on the home consoles, gameplay progression was generally pretty uniform and simple. On the Atari, usually the player was tasked with getting as far as he could, trying to get a “high score.” An example of this would be Space Invaders or Donkey Kong. On the Nintendo Entertainment System, many games adopted the simple “get to the end of the level” style of gameplay progression. The number of games that had you try to get from one side of the stage to the other is enormous, and many still exist like that today. In recent times, with the emergence of 3D systems especially, the variety of gameplay progression methods have boomed. Some games have you complete multiple missions or quests in any order you choose, some are expanded versions of the “level-to-level” style, some don’t give you any definite or ultimate goal at all, and many more methods exist.

Zelda has a very signature form of progression. The player travels to a new location, acquires a weapon or item needed to proceed, overcomes a series of challenges and puzzles in a dungeon, defeats a boss, and repeats the process six to eight times before the game is over. If you remember my original point, regarding the repeating elements in the series, this is what I was talking about. Once the player has been trained to follow these patterns, they are able to figure out how to proceed in the game almost instinctively. This overused process is made only more repetitious by repeating puzzles and tools. Simply put, the player needs new experiences to make the game feel fresh, and no matter what the game is filled with, if the mold is identical, it will always feel at least somewhat old, giving the “been there, done that” mentality to the player. Now, keeping the same general formula isn’t always bad; sometimes, it can be very beneficial. It can help keep the player grounded, and guide them through the game without any confusion. However, when the method of gameplay progression is tied to closely to the difficulty and main draw of the game, it becomes hard to overlook the fact that the game seems to just play itself. This is in the most extreme case, and Zelda doesn’t always suffer from these tired patterns, it just simplifies the experience, which isn’t what a lot of people look for in a game where they are expecting challenge and stimulation.

This hasn't changed in a while.

I think that part of the problem here isn’t simply the fact that gameplay elements are being reused, but rather that they are being used for the sake of being used. What I mean is this: certain traits have come to be expected of the Zelda series. For example, most followers of the games come to expect dungeons, specific items (some instrument, or the hookshot), bottles, switches and Princess Zelda. In fact, the only game where you never come into direct contact with the titular princess is also my favorite. A game that seemed to break the mold: Majora’s Mask. It was certainly a breath of fresh air. But as I was saying earlier in the post (if you can remember that far back), many of these elements and patterns played very specific and genuine roles in the gameplay and story. With each new entry in the series, these elements have become diluted with less meaningful mechanics and forgotten purposes. If these areas of the game were still given the level of meaning they were created with, it probably wouldn’t stick out as much. As it stands, many of the things propelling the game forward are somewhat empty. Mechanics become interchangeable, and elements lose weight and significance. Some “staples” of the series are fine left as they are; for example, Zelda games are about adventuring and puzzle solving. There’s no need to change the ideals that the series is known for, just the parts of the game that make it feel stale, such as recurring elements,  and progression patterns. Rather than simply focusing on finding something new to toss into the game, I believe that Nintendo should place more value in creating gameplay that once again contains a true sense of purpose and importance; feeling “fresh” should be a side effect.

It isn’t hard for a long-running sequel to become formulaic. Making a original and fun game is a feat; making significant improvements and changes in a sequel is another feat; but keeping each game in the series meaningful and unique is perhaps the most difficult of all. Yes, the Zelda series is guilty of stagnation, but it isn’t alone. More current series such as Halo, Call of Duty, Guitar Hero, and Tony Hawk are seeing the same issue as well, and no, adding a plastic skateboard doesn’t count as innovation. The series’s creators need to take a step back and look at how their games ask the player to progress through them, and most importantly, which parts of the game hold no significance to the gameplay and themes of their title or series. It seems easy to just stick to a formula and plug in new mechanics and elements for the sequel, but by the third or forth installment, these patterns become almost routine, leaving behind any element of surprise, excitement, or uniqueness. Each game, in a series or not, should feel like a new and interesting experience that brings something fresh to the table. This is what makes a video game significant, and why they matter. Innovation is the key to success, and it can be easy to forget this when you have a popular money-making series: the need to stand out isn’t as obvious, but it’s still important as ever. A series that can make a large number of games, where each experience ties into the themes of the series while still feeling different to not only the series but all video games in general, is a series that is bound to stand out and be remembered. If such a series exists, I bet that people would know about it.

M-aaawwwww!

The Maw

You may or may not be familiar with small development team Twisted Pixel‘s latest hit on the XBox live arcade, ‘Splosion Man, but it was a well-received 2D platformer that won the hearts of many and featured some intensely fun and challenging timing-based gameplay. While this is Twisted Pixel’s most recognized XBox game, it isn’t their only one. Their single other game, The Maw, also got some positive feedback, (winning the Pax Award Show and being a finalist in the Independent Games Festival to name a couple) but wasn’t as big of a project as the infamous ‘Splosion Man, which is made obvious by the improved graphics, polish, and sales of the title. But that doesn’t mean that The Maw should be left to be forgotton, and while it isn’t a perfect title, it certainly deserves some more attention, even so long after it’s release about a year ago.

The Maw is based around pretty simple concepts. Eat enemies to get larger (not unlike Katamari), and steal their special powers as well (Kirby, anyone?). Yes, these ideas aren’t completely new, but The Maw is a game all its own. You play as a small alien boy who leads around his pet, the Maw. The Maw is an ever-growing gelatinous purple blob cyclops monster, which is a lot more adorable than it sounds. The game overflows with charm, which can be traced back to a number of things. Perhaps it’s just the low-res background textures and oddly shaped polygon mountains reminding me of my fond childhood days on the Nintendo 64, but this game feels like an old classic. The game’s setup is fairly simple: Feed the Maw, and get to the end of the level. What the game does well, however, is make the world in which The Maw takes place interesting and enjoyable.

The Maw, using his newly acquired fire breath

Instead of thinking some well worded transition to lead us into the main section of the post, I’m just going to lay it out for you: Now we’re going to go in-depth about the design choices in The Maw. Awesome, let’s get on with it then. One thing I admire The Maw for, is it’s ability to make old concepts feel fresh. The levels are set up in a very simple goal oriented fashion; You are tasked with overcoming one obstacle at a time in a usually pseudo-open world and must use your character’s abilities to progress. We’ve seen this in games like Banjo-Kazooie, DK64 and Mario 64, but the Maw puts it into a smaller scale, and provides some new ideas as well. The Maw’s designers uses a tactic I like to call “The Toolkit”, meaning that the game gives you tools you need to solve puzzles, kill enemies, platform around obstacles, etc, (which in this game is the Maw’s ability to devour his foes and the player’s small set of non-lethal moves), and lets you use those tools to figure out the rest for yourself. Actually, a lot of games use this very common tactic. To put it into simpler context: Imagine somebody giving you a wrench, you discovering a metal nut, and using the wrench on the nut. Obviously you know what a wrench does, but if you didn’t, I’m sure there would be a sense of satisfaction in figuring out how to use it to your advantage. This is the principle gameplay mechanic in The Maw, only used in many different cases and in great variety. Only once did the game lead me astray by not telling me I had a wrench, or in the context of the game, not telling me that I even had the attack necessary to proceed. You can probably see how that would be confusing and problematic, but the game avoided this a majority of the time. One of my favorite moments in the game tasked the player with climbing onto a ledge that was too high to reach. The tool the developers gave the player in this level allowed you to pick up the small creatures in the world. Figuring out how to apply the tool is where the satisfaction lies. Monsters flew around the level, and dove into the dirt in pursuit of the tiny creatures. In this case, you had to examine the properties of the world (dirt is soft, metal is tough), use your tool by picking up a small creature and throwing him onto a metal plateau, and watching as the monsters dive after it, only to smack directly into the metal ground. Using the Maw’s power to eat the monster, you gain the ability to fly, leading you onward to the next area of the map. That’s good design. Old design, but not outdated.

The Maw is most successful (as a game and in design) when it is able to present new and interesting interactions with the game world, whether it be light puzzle solving or exploration. The Maw is weakest when it fails to make the interactions feel like a new discovery. The discovery can be solving a difficult puzzle, finding out what’s over the horizon, or something as simple as what happens when the Maw eats a stag beetle, but when the player (ME) fails to feel a sense of discovery, that’s when boredom settles in. I’m not saying that The Maw is a boring game, I’m just justifying why I wasn’t fond of the game segments that failed to show me something new. Actually, The Maw often feels like new ideas are around every corner. The level variety is one of the game’s strengths. The environments themselves don’t actually have any degree of variation, all being grassy plains, and while I understand that a short game doesn’t necessarily have time to fit in new settings (like a arctic or underground backdrop for instance), it certainly wouldn’t have hurt. Some levels are straightforward bouts of running and jumping, some are puzzle-based, some combat focused areas, and even one that’s centered around exploration. Doing something different in each successive level really helps the design feel fresh, even if some elements recur. Obviously, some elements of gameplay must recur anyways to add some degree of familiarity, but you get the idea.

The Maw takes some very classic design moves and wraps them up in a charming, albeit brief, experience. It doesn’t revolutionize the platformer, but it doesn’t need to. It’s nearly always fun, and I know a few developers who could use some design tips from Twisted Pixel’s staff. Trusted and familiar gameplay mechanics in a unique and charming setting: MAW.