Archives for posts with tag: game

In an effort to appear less secretive and more identifiable, we’ve recorded interviews with each of the members of The Rotting Cartridge, so that the public can put faces to the magic. The first interview focuses (by his request) on J, the founder of TRC and really the creative genius behind the whole thing:

Stay tuned for a final trailer and release date on our first game/port, Kale In Dinoland, coming in February.

I bought and played Bastion the night it came out, having followed Supergiant Games ever since January, when I found a link to a game that – upon first glance – looked similar to an isometric RPG game I was set on creating. But Bastion was its own thing, which I soon found out during the developer videos at Giantbomb.

The reason I was so interested? Sure, the art was amazing – at that point I wasn’t aware the sound was as well – but the narrator. Here was a developer set on doing something new, set on bringing a baby into this world.

I guess with every new sequel to a sequel, I get queasy. There just aren’t that many original designs floating around right now – seems like everyone is dead-set on repackaging the same bullshit we’ve already seen with a different colored ribbon. People have compared Bastion to an old SNES game. I don’t see it. But what I do see is this freshness, and perhaps that’s what people really mean now when they call it an SNES game: an original game. For god’s sake, an original game!

Everyone I told about Bastion during this time wasn’t thrilled. They didn’t see the potential the game had, being caught up with the nth installment of whatever RPG series and reluctant to try an XBLA title. But this isn’t about how I was right and they were wrong. This is about why I, fundamentally, can’t look past Bastion’s ending.

(SPOILER ALERT)

When you get to the end of Bastion, the game freezes and you are offered – in a menu screen – two options, either to try and save Zulf or leave him behind. The reason I am so opposed to this is before the menu pops up, the game design is spot-on. Near perfect. Every part of the game felt enjoyable to me. But this – MENU – pops up, I’m thinking, “What is this? No “good-or-evil” menus popped up in the entire game!” All of a sudden I was shocked.

It may have been Supergiant’s tight development schedule. But I view the menu as a blunder, a smear on the perfect canvas.

Bastion is a game devoted to dynamically engaging the player through gameplay. The narration represents the epitome of this fact: he reacts to you, he talks to you, and you trust him. The entire game leading up to the ending moment was filled with direct engagement. You were told your decisions in the game, on the playing field, had meaning. And I was foolish enough to believe they would follow through on this design theme. I was wrong.

What should have happened? There should have been no pop-up. The player should have been able to either realize there was a choice, and choose, or not realize there was a choice. And that potential: for people to not realize there was a choice, and blindly trudge forward leaving Zulf behind only to later find out they could have saved him – is a moment I wished occurred in Bastion, one that I can’t look past.

We’re still working on Kale in Dinoland! There’s a part of me that doesn’t believe it will ever be complete but… that’s nonsense. Here’s a more recent screenshot of a later area in the game:

Kale in Dinoland Screenshot

Kale’s sprite might still change at this point. Also if you noticed this game is a port of an old GameBoy game called “Kale in Dinoland”, but now that I’m looking at it I should explain that it does not perfectly emulate that experience because that would be boring. Nevertheless, I’ve tried to limit the design. Like some platformers of the day, Kale in Dinoland has doors that lead to single screen sub-levels containing a power-up or item.

Despite efforts to limit resources and pixel precision, there is undoubtedly a difference in screen real estate with the iPhone that heavily influences level design. For instance, a non-scrolling sub-level in the original is more square. In the iPhone version, I have from the top of the d-pad to the bottom of the health bar: in other words, super widescreen. So a lot of the levels focus on diagonal climbing (since looking for an enemy is the most optimal), almost none on downward progression, and the sub-levels reflect this extreme widescreen. I’ve had to cut some of the falling levels from the game.

The second difference, which I’ve tried to correct for the most part, is speed. In the screen above Kale is riding what I call a “Dog,” which can move horizontally pretty quickly. In GameBoy games, the character’s horizontal speed was capped much lower, so the limited level space could be maximized with enemies and obstacles. But I think the speed improvement will be welcomed by those that play it.

The last comparison is the save feature. Saving in the original Kale in Dinoland? Nonexistent. No save feature today? Almost nonexistent. So yes, Kale will have a save feature. But only as much as I believe GameBoy games would have saved — There are 6 areas in Kale in Dinoland, and after you finish one, your character returns to the world map and you are allowed to save. Meaning, manual saving. I’m still not sure (maybe it’ll be automatic?), but it will definitely only be after you beat an area.

In order to progress through Dinoland, you must beat an entire Area before you can save. Don’t worry, they aren’t that long. But they aren’t that short either. This also means individual levels aren’t selectable, because fitting multiple level select screens and a save feature for 50+ levels on top of a 6-area world map is not realistic to the GameBoy’s capacity.

At any rate, don’t take the ‘original GameBoy platformer’ out of proportion – it is heavily influenced by the original game, but I cannot deny that there are differences.

We finished the main five bosses! ^__^ Now there’s just some tweaking and playtesting to do, and then I have to go back to designing levels and enemies for the Arctic, Grassland, Volcano and Mansion worlds.


The jungle levels are completed! Right now I’m just working on adding the background and other details. After this I have to finish the Grassland world levels, start the Arctic world and possibly cut the Volcano world? Then there’s a bunch of playtesting on the Grassland and Jungle worlds to nail down the difficulty.


Since the last post I’ve fixed a lot of the bugs that came with going completely underwater, and now the first 3 levels of the Resort World are complete! I’ve got 3 more levels to go, then the boss, and then on to testing to make sure the difficulty isn’t too high. Also, the graphics will need some more oomph, so once all the levels are pretty much set in stone I’ll go back and add the finishing touches.

Today I take a look at Chillingo’s latest game, Storm in a Teacup for the iPhone, which goes for 99 cents on the App Store.

Storm in a Teacup is a physics-based platformer (what a surprise from the creators of Angry Birds) with polished graphics and sound design. In terms of art direction, the game tries its hardest to feel stylistically whole, but the style feels a bit off, like the game was thrown together in Photoshop. Plus, there’s annoying stickers everywhere, presumably desperate attempts at subliminally teasing the player into collecting more trinkets. In addition, if you take a look at the player’s character you’ll see it isn’t very consistent with the rest of the game. Here’s the low-down:

What to Like:

  • Physics puzzles
  • Smooth gameplay
  • Cuteness
  • Simplicity
  • Perfect for perfectionists
  • 99 CENTS MAN!!

What to Dislike:

  • Simple physics puzzles
  • Relies on pixel-perfect jumps a little too much
  • Cuteness
  • Conflicting art style
  • No story

While it was fun while it lasted, physics platformers are getting a little stale as of late. Chillingo seems to be experimenting here, just releasing small games with undeveloped (almost alpha-level) art styles in a search for the next Angry Birds.

The Rotting Cartridge gives Storm in a Teacup a THREE…. out of five.

This is part two of an x-part series summarizing the design of one of the greatest games of all time, SOTC. Part 1 can be found here.

Welcome back to Design Theatre! Today, we’ll take a look at how Shadow of the Colossus (SOTC) was designed in its first major sections of gameplay.

There are sixteen bosses in Shadow of the Colossus, each with a unique twist on the “stab its vitals” formula. The first boss, a giant wandering colossus with a club, is by far the easiest, only requiring the player to climb up its leg and stab its head to defeat it. However, at this early point in the game, the player doesn’t yet know they have to do this, and since the player has likely never faced something this large in a game before, they panic. The battle serves as a tutorial, teaching the player the fundamentals of how to defeat a colossus, without giving them all the answers. For example, it is hard to imagine that the latter bosses of the game require the player to utilize their environment in creative ways to defeat them, yet the goal – climb the colossus and stab it with your sword – remains the same. From this section we learn:

#5. In the beginning of a game, introduce a short-term goal that shouldn’t change for the duration of the game.

Read More

  vs. 

The series was tied at 1-1 going into Game 3 tonight, and I gotta say, I’m just not sure who to root for here. On one hand, you have Derrick Rose and the #1 seeded Chicago Bulls. On the other hand you have the newly put together Big 3 and the #3 seeded Miami Heat. And right there is where the problem lies. It’s  not that I can’t stand some of the players on both teams, there are players like that on every team. It’s that I can’t stand the big names on these teams. Click here to read more about what I have to think about the Chicago Bulls and the Miami Heat, as well as my analysis of the game.

Ever wanted to create a game? Ever wanted to be involved in a team that makes games? It seems like fun, doesn’t it?

In my first year at college, I noticed many people in Computer Science (CS) with a lackadaisical understanding that their CS degree would be their window into making video games. From a teenager just coming out of high-school, a career doing what you sit around playing all day anyway seems like a dream job. So students go into the CS program with an understanding that they will come out suddenly aware of how to make games. But this is far from the truth – most CS programs don’t even get into the specifics of game development, and CS – Computer Science – is not even about three-fourths of the development of a game, which also includes art and music, design, and business. In fact, it’s been argued that people can come out with CS degrees that don’t even know how to program! So where the hell do students get the idea that CS equals game development??

Part of it has to do with the substantial lack of good game development courses at universities. But even more of the blame should go on the students themselves, who don’t realize the amount of work involved in making a game.

I’m currently working on a iPhone game, and despite numerous attempts to establish a team, other students end up quitting after they realize game development is not fun and games, but sweat and tears. There is a precedence for this. At the game development club at my university, apparently a year before I came, the club had a team of around twenty people developing a 3D adventure game for the PC. Needless to say, the team was made up of students who, as I’ve previously mentioned, have unrealistic expectations about game development. Their project never got off the ground, and the survivors don’t like to talk about it, disillusioned about game development in general.

Is this really how it has to be? Do innocent CS students just have to experience game development the hard way?

I think the problem here is the general consensus that “video games aren’t a serious medium” somehow spills over into video game development. Say, for a second, we called it “industrial development.” Suddenly seems boring, like a real job, like it requires serious work because “industry” must be serious? Well, the truth is that “video game development” is closer to “industrial development” than most people realize. Long hours, you have to work on things you don’t want to at times you don’t want to, you have a limited amount of creative control (if any at all), and no guarantee that your product will be a success.

So if you’re a student taking CS to get into game development, start now, and start small. Ease yourself into game development making pong and breakout clones: you’ll learn more than you realize. Learn about the hardships of game development firsthand. You’ll save yourself a rude awakening later on.