One thing that I think I am starting to realize about my programming process is how important it is to me to be able to complete a task in a single session.
Each evening when I sit down to work on my game project, I don’t usually have a specific idea about exactly what I want to work on or accomplish. I do have a lot of general ideas. I have a list of things, a backlog of features that I have brainstormed but have yet to implement, or have yet to implement to my complete satisfaction, and a rough idea of the priority I’d like to give on each item in that list. When I sit down to being my development session, I review the list and pick something. As I continue to develop, I continually update the list, usually removing things from it that I’ve completed (it makes me happy/inspired to see the list shrink), but sometimes adding new things if an idea comes to me or I realize a new problem has come up as a result of something I’ve been working on.
I am not strict about working on items in priority order. To some extent I am taking things in order of importance, but mostly I try to work on the most important thing that is also easy to accomplish quickly — the so-called low-hanging fruit type stuff that is easy to do and provides a high value to the project. To a larger extent, I work on things in the order that I can work on them — some things are dependent upon other things and I have to do those things first in order to be able to do the next thing. Or sometimes I need to learn more about something in order to do it, and doing something else first will give me the opportunity to start to get into that topic in a more lightweight and manageable fashion.
Sometimes I just work on something that I happen to be interested in at the moment — it is important to recognize the power that having an interest in something has. If you’re interested in something, engaging with it is easy and natural. If you’re not interested in something, it’s hard. If you’re actually interested in something else, it can be all but impossible.
Having a sense of progress and momentum is extremely important to maintaining my morale and motivation.
I like to work in long, mostly uninterrupted sessions. I’ll start around 6-7pm and stop around midnight-1am. I don’t just work on the project during this session, though — I read my usual websites, do email, make dinner, chat with friends over IM. I find that this does not interfere or impede my progress or ability to focus, and any of these “distractions” makes for a good punctuation mark that allows me to take a breather and come back to the project with renewed energy.
I don’t even spend most of my project time developing and coding. The coding part of the work just doesn’t take that much time. I spend more time building and playing, then going back and tweaking something, building, adding a tiny little bit, and replaying, again and again, until I get what I wanted, or, often, figure out what I wanted. A lot of times, an idea I had at first is not really as good as I thought once I have built it, but something else that is close to that is better. By carefully testing each little change iteratively as I build, I ensure that I move in a steady direction toward a successful design. This is much better than trying to design everything out on paper before I put any time into building it, by far.
When I first sit down to work for the evening, I have in mind a goal to improve some aspect of it, and by the time I am ready to put the project down again, leave the game in a state where it is both playable and improved from the last iteration. I sit down and look at my list, mull things over for a bit, do a little bit of planning and thinking, and then start building. As I build, I document what I’m doing.
The first thing I do with each session is to create a new version of my project. I don’t stop working until I’m satisfied that what I built works the way I wanted it to, and results in a better game than what I started with.
I’m not sure how sustainable this is, this approach of having tiny tasks and completing them in one session, but as much as possible, I want it to be. I find that I am far more productive in my project as I am working if I can complete* some aspect in one sitting, as it were. If I don’t make it, I run the risk of losing my thought process and not being able to pick up where I left off. I think of it like writing a book — you don’t want to just cut off in mid sentence. And ideally, you’d like to be able to complete a chapter, or at least a thought.
*When I say “complete”, I don’t mean “final”. I will likely go back again and make further refinements when the time is right. For example, when I started implementing my enemy objects, at first I just placed them into the game as immobile objects. I next focused on interactions with the player object. In a later session I added very basic movement, and spent a lot of time tweaking that. In upcoming sessions I plan to further refine enemy movement, adding different modes and coming up with some AI routines that determine how the enemy “decides” what mode to be in depending on what’s going on in the game.
My guess is that if you architect your program the right way, you should always, or nearly always be able to use this approach of tiny steps over many iterations. To extend the architecture metaphor a bit, if you’re laying bricks, to build a bigger building you just use more bricks — you don’t suddenly have to switch to bigger bricks that become unmanageable for one person to wrangle. That may not always hold true, but my feeling is that it should most of the time.
I ran into a bit of strangeness with my game project today. While testing a feature, I noticed something inconsistent in the way the program behaved. Upon investigation I discovered that the cause of the inconsistent behavior was that I used two different functions to do a comparison of a certain value in two different calculations, and these functions are not equivalent.
In GameMaker 8, there’s an Action called Test Expression, as well as an Action called Test Variable. It turns out that Test Variable isn’t so good when it comes to testing for equality, due to the way GameMaker handles typing of variables. For the most part, there are only two types of variables: strings and real (floating point) numbers. But in GameMaker 8 they also introduced a few new functions that return integer values. It turns out, if you use Test Variable to compare the value of a real number to the value of an integer to see if the two values are equal, Test Variable will never return true. However, if you use the Test Expression action to do the comparison, it will return true.
In most programming languages, it is impossible to directly compare an integer to a floating point number; you have to use type casting to convert one of the values and then do the comparison. Working with floating point math is tricky with computers, because of rounding errrors, where values are often +/-0.00…01 (whatever the precision is) off due to the way floating point math works. Yet, GameMaker does not display the full precision of the floating point number that is stored in a variable — it only shows the first two decimal places, and hides the rest. Thus, to GameMaker’s Test Variable action, the number 3, which might be returned by the irandom(n) function, is not equal to the real value 3.00.
Test Expression does get this right, though, and automatically accounts for the rounding error, and will consider int 3 to be equal to real 3.00(00…01).
Hopefully they’ll fix Test Variable in a future release. I have reported the issue to GameMaker’s bug tracking system.
One of the first things I did with my gmk project is figure out how to do file I/O so I can write out to an event log so I can see what’s going on in the game. This is highly useful, since it allows me to track every action that happens, every value of every variable if I want to.
Once I figured out how to write a file I/O routine in gamemaker language, I put logging on a bunch of things in the game that I wanted to track so I could see it working and make sure that it was working the way I wanted it to. Mostly this was a check to verify that the way I understood the environment to work was correct.
After I’d written a logging routine on just about everything I’d built so far, I discovered that you can call scripts. So I got excited by the prospect of being able to write a reusable script that would save me from having to write out the same code again and again, like I’d just did. So I built my script, proved it worked, then went and ripped out all that redundant work that I’d just put in. I didn’t mind at all because it meant moving forward that I’ll have a lot easier time with building up code, and I’d discovered it way early in the project.
(I probably could have learned it even earlier had I read the manual cover to cover before starting, but I find it easier to engage with something if I play with it as I learn and read as I play with it whenever I get stuck.)
###
The next interesting thing I did was a feature I wanted to implement early. Trying to do the early stuff the right way is important, but you can’t second-guess yourself so much that you don’t make progress at all because you can’t decide what approach is truly best.
The feature in question has to do with the graphics. I wanted a way to graphically show the relative strength of the enemies to the player. Basically, we have a “strength” variable, and if you compare it to the player’s current strength, an enemy is either weaker, equal, or stronger than the player. I want to make this apparent to the player visually.
On my first development iteration, I simply implemented a separate object for weaker, equal, and stronger enemies, which all inherited from a base enemy class.
On my second development iteration, I figured out that I could have a single enemy class, and for the initial value of the strength variable, I can just assign a random number, and then based on this random number, compare it to the strength value of the player, and assign the appropriate graphic to the enemy. I got this to work pretty easily, and it eliminated the need for having separate objects to represent the weaker, equal, and stronger variant enemies. This might be a mistake, as it might make things more complicated to have a single object doing all three things. But I think it is the right way for now.
On my third development iteration, I needed to make the enemies update their graphics. The player’s strength increases during play, so as the player’s strength changes, the enemy’s relative strength might change from stronger to equal, and finally to weaker. I wanted to figure out a way to do this efficiently, and figured that having an event that fires whenever the player’s strength changes would be a good solution, and the “right way” to do it. I haven’t been able to figure out how to do this in GameMaker yet, however. It’s not an easy thing to do, and probably requires a bit more understanding of GML than I have at present. GameMaker handles instances of objects in a kindof kludgy way, and this quirk in the way the language works makes it harder for me to do what I want to do.
After trying to figure it out for about 4-5 hours, and not getting anywhere, I opted to go for something cruder but simpler, and found that it works just fine, at least for now. Rather than trying to fire an event that checks the relative strength of every existing enemy in the current room whenever the player’s strength changes, I simply created an event for the enemy class which checks its strength relative to the player each and every step of the game engine, and updates the enemy’s graphic. Obviously, this would not scale as well (I’m basically “polling” the objects 30 times/second, instead of simply calling a method as needed, which would be a much more efficient way of doing it.) So this approach may not work out so well if the game gets larger. But at the scale I’m currently working at, it performs just fine. I’ll have to revisit at some point if I have too many objects in play, but I’m not going to worry about that for now.
So I’m working on my first serious attempt at a GameMaker project.
The thing with working personal projects is balancing how much you talk about your project with how much you work on your project. You can’t be all talk and no action, obviously, and you probably shouldn’t simply spring a new project on an unsuspecting world, either.
I’m not yet sure how to do this right. I don’t want to spend a bunch of time describing something that doesn’t exist yet, especially if I may change my mind about particulars a bunch of times before I decide to release it. On the other hand, not talking about it just drives me crazy. I’m into my project, and it’s interesting and exciting to me, and I just have to talk about it.
The other thing that’s hard about talking about working on personal projects is talking about it with a proper level of authority and confidence. I’m doing things that are new to me, for the first time in many cases. But most of what I’m doing is technically not all that difficult or sophisticated. As much as I want to be excited about figuring out something, I don’t want to make myself look dumb by blogging things that are the equivalent of what “Hey, guess what I just figured out? When you have a plus sign between two quantities, that means they’re added together!” would be to a math blog.
What I do like about this project so far:
The fact that I’m doing something that I’ve wanted to do my whole life.
The fact that I can do it.
The fact that I am doing it.
That the progress thus far has been fairly steady.
My process: planning, building experimentally, testing, documenting. I feel like I’m going about this in just the right way.
In fact, I really like my process. Here’s what I do:
Sit down and think about what I want to do. Brainstorming. Create a list, prioritize it. This becomes my backlog.
Work an item on the list until it’s done to where I’m satisfied with it for now. This involves building and running it to test it, over and over. I try to conceive of my solution first, then build it, starting small and simple, and building off of what I just did. I’m more tentative with things I haven’t mastered yet, but that’s the natural way of things.
Write up what I did in my version history. Update the backlog, to either remove the item from the list, or more likely, update it to reflect the next level of refinement that I want to get to with that item.
So far, so good. I have a ways to go yet before I have something that’s worthy of an alpha release. I might have it out in a few weeks, we’ll see. What I have right now is playable, but not interesting as I’ve yet to implement any enemy behavior. I expect that the enemy behavior will be very interesting to work on, and probably one of the trickier aspects of the game and thus may take me longer than what I’ve done so far.
Today I attended a Cleveland Game Developers Meetup where we did a workshop on rapid prototyping and playtesting. It was very successful and fun.
We workshopped the card game War. Standard War normally is not a terribly interesting card game, with rules that are deterministic, and therefore involve no skill or strategy, but it turned out to be a good starting point for the workshop. We broke up into two groups, each led by one of the organizers, and brainstormed ways to improve the basic game, then ran the game through several rounds of playtesting, tweaking rules and refining. In little under an hour, what we came up with was actually fun enough to share with the world.
There were five of us in our group: facilitator Sam Marcus, me, Steve, Nadja, and Melissa. Sam set up the exercise and we worked together to come up with the rules. Sam and I seemed to come up with most of the ideas, but everyone contributed to running playtest iterations and helped to make the game.
Here’s what we came up with:
War: Battle Lines
For two players.
War: Battle Lines starts from the concept of the card game War and makes it more interesting by introducing elements of choice and strategy.
Initial setup:
Deal the entire deck between the two players.
Variant:Symmetric Start. Rather than dealing out the cards randomly, player one gets all the red suits while player two gets all the black suits.
Play:
To start a hand, each player deals themselves the first four cards from the top of the deck, called Skirmishers, and lays them out on the table in front of them in a horizontal line, like they were dealing Three Card Monte. Two of the cards must be face up, while other two must be face down. Each player may look at their own down cards prior to the round starting, or at any time throughout play, but may only see the other player’s down cards once they become involved in a skirmish.
A fifth card, called The Initiative, is played face up. The two Initiative cards are contested, and the player winning the Initiative round gets to make the first play.
The player who wins Initiative picks any one of their cards and may choose to “attack” any of the other player’s cards. The cards involved in the skirmish are compared face up, and the higher of the two cards is the winner of the skirmish. The winner of the skirmish adds both cards to their victory pile.
If the result of a skirmish is a tie, a “battle” breaks out. Both players immediately “call up reinforcements” from their deck of un-dealt cards, and these cards are compared to each other to determine who wins. The winner of the battle takes all the cards and adds them to their victory pile.
Players alternate turns until all four skirmishes have been resolved to complete the hand.
The game continues, with additional hands of four cards plus one initiative card dealt, and the process is repeated until the deck is exhausted.
Once the deck has been exhausted, the game is over. The winner is the player who has the larger victory pile.
In a 52-card deck, each player will have 26 cards to start out, and therefore would play through 5 rounds with their four skirmishers plus initiative card, leaving one lone card at the end of the game. In the event that a Skirmish turns into a Battle at some point during the War, there may be other endgames possible, with 1-4 cards left over at the end.
How we handle the last card at the end of the game is open for variation. In the “standard” game the last card is simply played at the end as a normal skirmish or initiative round. If there are 2-4 cards left over, they may be played out as a regular five card hand, merely short-handed. This is an area of the game that merits further play-testing and experimentation.
Variants:
Deuces over Aces. We felt this made the game more interesting as it gave the 2s some value, and made the Ace less of a super-weapon. 2s still lose to everything else, and Aces still beat everything else.
Low card wins Initiative. We experimented with this rule to see if it made the game more interesting by providing some advantage to holding low cards. It was inconclusive whether it made a meaningful difference to the game. I kindof liked the idea, but since the player has no control over what card they are playing for the Initiative, it seems not to make much difference. It might make some difference in a game where the deck is recycled rather than played through once.
What’s up? Initially I had suggested that the players could determine how many, or whether to play any, of their battle line cards face up. My thinking was that this might lend some element of strategy to the play, and that players might want to show strength or hide it, or show weakness or hide it. We ended up opting for a more simplified mechanic of “even cards down, odd cards up” in the battle line. But I think there is still some potential for this to be tweaked into an interesting mechanic. Further study is warranted.
Recycle the deck. In this longer-playing variant, rather than play through the deck one time, the players would recycle their victory pile back into play. Play would continue indefinitely until some victory condition is reached. The obvious victory condition would be one player holding all 52 cards. But that would take a long time to play out. There could be other victory conditions for this variant, such as holding all cards of a certain rank, such as Kings.
Ace in the Hole. In this variant, each player retains one of their Aces as the last card in their deck. They may opt to play the ace at any time in the game to “turn the tide” of a Skirmish or Battle that they otherwise would have lost. If the other player still has their Ace in the Hole, they may counter and play it, creating a “tie the tide” situation which then results in the usual Battle resolution. In practice, this seemed to offer no additional depth to the game’s strategy.
Jacks are Spies. We talked about, but did not play-test, giving a certain card rank the ability to “spy” by looking at an opposing player’s down-card without engaging it in a skirmish. How this would be worked out in practice remains to be workshopped.
Flanking. To make play with low value cards more interesting, we talked about but did not play test giving players the option to combine two low-value cards in an attack against one of their opponent’s cards. The exact conditions to allow this and how to resolve outcomes were not determined. Further study is warranted.
Strategies
A few interesting/notable strategies were observed during playtesting:
If you have a low-value card and have initiative, it may be worth attacking a high value card of your opponent, to “waste” their high value card by sacrificing the low value card. This is especially true if your low-value card is showing, since your opponent knows it is a sure victory and will likely send one of their low-value cards against it to defeat it.
The Takeaway:
Here’s some of the things I got out of this exercise:
There’s still a lot of life left in a deck of cards. It surprised me that playing cards are so adaptable that we can come up with novel and interesting game ideas without a huge amount of effort. Perhaps this shouldn’t surprise me so much, a deck of cards is simply a mathematical system, which can be manipulated in so many interesting ways. Still, if you think that the only games there are to play with a deck of cards have all been discovered already, think again.
War isn’t such a bad game. It might not have a great deal of depth to it like Poker, Spades, or Gin. But with just a few minor tweaks we turned War into a game that was pretty fun to play. If it’s not that far off from being strategically interesting, it’s doing something right. War is also a great game for teaching very young card players how to play games with cards, and the value of this is not to be under-estimated; it’s OK for introductory games to be trivial or even deterministic.
Rapid prototyping and workshopping is a lot of fun. The best thing to do is to play ideas out and see how they work, not to argue merits for doing something one way vs. another. Our group didn’t argue at all, we just threw out ideas and tried them out and then it was pretty evident to all whether they worked or not. We kept what worked, and kept tossing out ideas until we felt satisfied that the game was fun. Working with the group this way made things very fun and we progressed very quickly. I’ve been in groups where endlessly arguing just results in ego clashes and slows things down and makes the whole project not just lose its fun, but often lose its chances of being successful.
Sam Marcus is a sharp, likable guy who’s good at talking and listening, has good ideas and a good sense of judgment, and is therefor extremely easy to work with. I really hope I get to work with him again on future projects.
I’m particularly strong when it comes to game mechanics. I have an intuitive grasp of what will work and what won’t, and how a rule modification will affect the overall system. While it always is necessary to test ideas out, most of my ideas turned out to test well, and worked much as I expected they would.
What I’ve been up to lately: The Computer Game and Simulation Design class wrapped up this week, and I both did extremely well in it and enjoyed the class very much. I ended up carrying a 101.5% average in the course.
My grade for CGSD 120
Since I now have some spare time with the class out of the way, I’ve started my first independent project. I’m not really ready to talk about it in depth just yet, but in the next few weeks or so I hope to get it to a playable alpha state, and then it will be made available over on the releases page.
In my game and simulation design class, we were having a discussion on why players quit playing games early. We read this article on gamasutra, and then today this IGN article happened to get posted on slashdot.
I could go on at length on the topic and the issues it touches on, but in the interest of brevity I’ll just post the following quick points:
This “quitting is bad” thing is something of a problem of perception. Until recently, game consoles weren’t online, and there was no feedback to tell game developers whether players were finishing games, or how many were quitting before they completed a game. It’s a big presumption to assume that quitting is a problem. How many “quit” playing before publishers had the intrusive capability to know?
There’s quitting, and then there’s quitting. Videogames are, to most people, disposable distractions. For a few, like me, they may be an lifelong pursuit. But even so, specific titles rarely achieve the sort of status that games like Chess, Checkers, Go, Poker, Bridge, and so on have achieved. People may “quit” after they “beat” a videogame, but it’s still quitting. Chess is going on strong for milennia. Even so, there’s probably many more people who’ve played Chess and quit, than who never quit playing chess. What’s that got to do with whether chess is a successful game?
Is this only a problem for games that have endings? Not all games have endings! There’s no end to Pac Man or Defender or Asteroids. Well, Pac Man has a killscreen, but it’s a bug not a designed feature, and it exists because no one ever thought a player would ever be good enough to reach it. Is everyone who never reached the 256th level of pac man a quitter? I hardly think so. But yet, games have their life in the market, and most of them have nowhere near the success of pac man. Whether they have an ending or not, people stop playing them, at least enough for them to no longer be worth the retail shelf space they take up, or the floor space in an arcade.
On the other hand, this is what keeps game designers employed. People get tired of the old games and quit playing them, but they want new games to play, and they pay us to make them. If we created the ultimate game somehow, the only game anyone would ever need to play, we’d be done. So, quitting is in some sense essential. We just don’t want it to be too early, and we definitely don’t want to turn people off so that they won’t buy again. We want to make our money, and we want to create demand for more. And ideally that demand should be for something new, so we can keep working and make more money.
Whether players quit and buy something new, or if they keep playing and spending their money on what is already out there, the industry doesn’t care, as long as they’re making money. The industry is interested in quitting only insofar as they want to analyze the phenomenon in order to maximize profit by having the optimal player-quit strategy. Depending on your revenue model, you may think of quitting very differently. Are you selling a game for a quarter a play? A CD-ROM for $60? A monthly subscription? It matters.
Defining what constitutes “completion” is also a problem. I noted an extremely low level of completion for Guitar Hero III. What is completion? Is it playing every song? Beating the final boss? Beating the final boss on Expert difficulty? Unlocking all of the unlockable stuff? What about what the player wants? I’m never going to be good enough at Guitar Hero to play much past Hard. I’m satisfied with this. I am never going to play some song that I dislike, just because happens to be packaged with the game. I don’t really care about unlockable stuff — usually the rewards to unlockables isn’t worth the endless repetition and perfection required to gain the achievements. By that time the fun has long since worn off. I’m not obsessive-compulsive, and I have a life, so most likely I’m not going to “complete” everything. Maybe I am not interested in the single-player mode for an FPS, and only want to play deathmatch. Did I quit? Or did I get the game I wanted and played it the way I wanted? *I* decide when I’m finished with a game. The designer may hope that I’ll play every last thing that they put into the game, but it’s stupid to expect that I will, or that I would even want to.
If I walk away and leave something “on the table”, it doesn’t mean that the game designers failed, it just means that there was something in the game that I didn’t care for — but perhaps many others who played the game did. I worry that industry analysts will stupidly look at completion statistics and say “Only 20% bothered to beat the game, so cut the final boss budget by 80%”. Or, “Players spend 90% of their time in FPS playing multiplayer, so let’s skip the single-player entirely. No more immersive stories.”
If I quit because I was incapable of winning, to me that’s not a problem either. Having things in the game that few people accomplish is as much a mark of a game’s challenge as it is whether they designed a game that people want to play. I don’t believe that every person should be able to beat every game they play. I want a game to challenge me, and I want it occasionally to find my limits. If I can always beat everything, it just tells me that they’re not challenging me enough.
There are games that I have beat that I still play. There are games that I didn’t beat, but played a ton. There are games that I still play to this day. Each of these categories includes great games. I’ve played Mega Man 2 and Metroid countless times, and I still enjoy it because of the great music and awesome gameplay. I played Mike Tyson’s Punch-Out!! and 1943 endlessly, trying to beat the final boss, and never managed to do it. They’re insanely hard, and I swore and cried at times. I loved every minute of it. There are games like Tetris, Ms. Pac Man, Asteroids, Robotron: 2084, and others, that I don’t think I’ll ever tire of playing. I may not play them frequently, but they’re perfectly-balanced, timeless classics that I don’t think will ever die.
I’ve heard players complain about games not being worth $60 because they only get a few hours of enjoyment out of them — many of them first person shooters with short single-player mode stories. Here’s a game that people DID beat, and they’re complaining that it was too short. Completing the game, they still quit (didn’t re-play), feeling unsatisfied. That’s just as big a problem as the game that people didn’t complete.
If you’ve never played a Pitfall game before, it’s best to go back to the beginning to the original Pitfall! on the Atari 2600. One of Activision’s finest games, and one of the best on the console, or on home consoles of its day, period. Pitfall!’s adventuring theme was in style thanks to the popularity of the new blockbuster movie with Indiana Jones, but wasn’t based on the movie. Although it lacked actual “platforms” the game might be thought of as a prototypical platformer — the gameplay is all about running and jumping. Pitfall was followed by a sequel, Pitfall II: The Lost Caverns, which featured a more expansive map, engaging background music, and a real ending, but suffered a bit from repetitive gameplay. Overall it was still a highly regarded game and one of the most technically advanced titles released for the Atari 2600.
In 1985, Nintendo released the NES in North America, and put an end to glut period in the market that had plagued the industry from 1983-4. The consoles of the Atari generation were long in the tooth, but had been so popular in previous years that anyone who could was releasing anything they could burn to an EEPROM cartridge and slap a label on, regardless of quality. This resulted in a huge glut of terrible games, sales plummeted, and some analysts were saying that videogaming was just a fad that had seen its day come and go. Fortunately, Nintendo reversed that thinking, largely on the merits of Super Mario Bros., itself a sequel of sorts to their popular Donkey Kong, Donkey Kong, Jr., and Mario Bros. arcade titles from the previous generation. SMB was an innovative next-generation platformer, which advanced the state of the art over former running and jumping king Pitfall Harry, and introduced many, many innovations and superb level design and a forgiving, yet challenging difficulty curve.
A full two years after the launch of the NES, Activision released Super Pitfall. Only this time, they didn’t develop the game in-house, instead opting to farm it out to a company called Micronics for Pony Inc., I assume due to lack of familiarity with programming for the NES hardware. The game was a failure on so many levels, it’s difficult to enumerate them all, and unbelievable that the game got released at all given the quality of the competition at the time. It’s interesting to contrast Super Pitfall against Super Mario Bros. because fundamentally they have so many things in common, yet one game does everything so well, and the other does everything so poorly.
As a 12 year old, I was excited to play what seemed like a promising title — the Activision games for Atari were top notch and pushed the hardware past the limits of what many thought possible, and the Pitfall games were the creme de la creme.
I can’t promise an exhaustive list of all the ways that this game fails, but here’s my best attempt. Keep in mind I haven’t played this game since I was 12 or 13, so going on 22 years — THAT is how indellibly the “suck” was burned into my cerebral cortex.
Plot:
Plotwise, Super Pitfall is basically just a rehash of Pitfall II: The Lost Caverns. You’re supposed to rescue your niece Rhonda, her pet cat Quick Claw, and find treasures. Apparently, no one at Activision had bothered to put any time into coming up with any new ideas since the release of Pitfall II in 1984. Did they think not enough people had played Pitfall II, and so the plot was still fresh? Did they think that plot didn’t matter for adventure games in the NES era? I can’t say; I can say that the game feels stale from the minute you start reading the instruction booklet. Come on, anyone who liked video games played Pitfall II in 1984; it’s been three years, couldn’t they have taken 15 minutes somewhere and wrote up a new plot?
Graphics:
It’s tough to appreciate how poor the graphics performance is in Super Pitfall without seeing a video. Still screenshots do not convey the problem adequately. There is so much flicker that it becomes easy to lose track of something on the screen because it’s been invisible for that long. Not only do the sprites flicker like a strobe light on low, but they are poorly animated as well. Pitfall Harry looks like Mario dressed up in an coal miner costume — nothing at all like he looked on the Atari. On the Atari, Pitfall is thin, and looks like he might be a tall, wiry guy. In Super Pitfall, he looks tubby, with a big nose and mustache, like Super Mario. This is at once both a sacrilege to the real Pitfall Harry, and a pale, pathetic imitation to Mario. Scrolling is very jerky. Rather than smoothly draw in the new background tiles as the screen moves, it seems to wait until there is space to draw the entire row or column of tiles, and then draws it in all at once. This creates a clunky, lurching effect that looks and feels horrible.
Hit Detection:
Hit detection is imprecise, to put it kindly. Often you die for no apparent reason. Stuff that looks like you’re clear by a good distance can still hit you. Worse, it appears to be inconsistent. Sometimes you die, sometimes you live, with little visually apparent distinction between the life and death. It’s as though the hit detection mask is a variable sized, invisibile object that orbits around the visible graphical sprite that is Pitfall. It is probably also a rectangle, rather than a precisely fit shape.
Controls:
You move slowly, the controls respond slowly to player input, have barely any control over your jump once it’s initiated. It’s just about impossible to get out of the way of anything unless you see it coming well in advance, and it moves in a predictable way. The aforementioned flicker and hit detection problems make this far from simple. The poor jumping control is probably the most inexcusable flaw in the game, after the graphical glitches and performance problems. In a platforming game, jumping is crucial to get right. Super Pitfall blunders by conceding to realism the fact that in real life you can’t alter your trajectory once your feet leave the ground. In Super Mario Bros., you can control much more finely how far and how high you jump, and it makes jumping fun. Mario gets jumping right.
Also, Super Pitfall has a pistol available as a power-up item. The original Pitfall games were essentially non-violent. Pitfall could die from scorpion stings or eaten by alligators, but he himself never committed any violent acts. I’m not against new features, but again, the implementation was shoddy. And I did think that having guns in the game changed the spirit of the original Pitfall, to the detriment of the franchise. What I’m not sure about was the design decision to make the original games non-violent.
Pitfall Harry takes a lot of his cues from Indiana Jones, who only ever used a pistol once in all his movie adventures. So that’s one good reason for Pitfall Harry not to need a gun. As well, in the early 80’s there was a lot of concern about violence in video games affecting young minds, just as there is today. It’s hard to believe, given how cartoonish and low-res the sprite based graphics of the day were back then, but in the early 80’s there were crazy people who were worried that shooting in a video game would result in an increase of shooting in real life. I’m not sure if Pitfall was originally nonviolent due to pressure from these organizations, or due to the idealism of the designers, who maybe wanted to show that non-violent games could be fun, or due to technical limitations for how much you can cram into 4k of 6502 Assembly, or possibly a combination of all three. Partly, I think it was simply because there was only one button on the joystick, and it was for jumping. But the main, and best, reason is that the original games didn’t need a gun. It made for more exciting gameplay if you had to run, evade, and jump past obstacles rather than blast your way through them. Besides, many of the obstacles in the game (I call them obstacles and not enemies, because most of them are indifferent to your presence in the game, and only kill you if you blunder into them) are rare, exotic animals. It just doesn’t seem right that Harry would be willing to gun down some endangered species just so he can get through unimpeded.
Maybe they needed to give you something to do with that second button on the NES game pad. But it’s implemented terribly compared to games where shooting is the main point of playing. In a shooting platformer game, like Contra, you can shoot in any direction, have unlimited ammo, can have as many bullets on the screen as you want. In Super Pitfall, ammo is a resource that you have to collect, you can only fire one bullet at a time, and it sometimes takes several shots to kill an enemy, although I could never tell if this was due to bad hit detection or because there was a variable amount of damage done with the bullets and it sometimes took multiple shots to kill certain enemies. Regardless, killing an enemy feels like a cop-out to avoid having to jump over obstacles. But given how much the hit detection sucks, it’s worth it when you can. But the ammo is so scarse that you dare use the gun only when you’re faced with a situation that you couldn’t possibly jump through unassisted. The idea seems to be that they didn’t want to turn the game into a shooter, and so each bullet you pick up is almost a surrogate for an extra life, and you spend them whenever you see a situation where it looks likely that you’d die if you didn’t use them. It would have been better if they had allowed Pitfall to shoot himself and end the misery.
Hidden stuff, yet no clues as to where they are or what they are for:
Hidden secrets were a big part of Super Mario Bros. popularity. Finding all the hidden coins, bonus rooms, and warp zones was a smart design choice that gave the game a lot of replay value. Super Pitfall has many secrets, too. But again, it’s all spoiled by terrible implementation. Most secrets are discovered by jumping in specific locations on the map. This causes some secret item to appear close by. There’s never any apparent visual cue to tell you that you should try jumping in a specific location; the game sortof expects you to “mine sweep” through the entire map, tile by tile, jumping every step of the way, until you find a secret. Once you do, you’d better memorize it or mark it on a map, or you’ll never find it again. Many of these secrets are essential to making forward progress in the game — keys that unlock other levels, or even the actual gateway to another level. This means if you can’t find the secret, you can’t complete the game. You end up frustrated and give up. There’s no replay incentive to go back again and find secrets, since in order to beat the game once you will end up finding them all, or at least all of the critical items. The non-critical items (bullets, extra lives, bonus points) don’t aren’t necessary if you make it through without getting them, you’re just that much better at the game if you don’t end up needing them, and discovering them is so counter-intuitive and tedious that the less of them you need to find, the happier you are.
Game Map is next to impossible to navigate:
One thing I’ll say about the Lost Caverns that Super Pitfall takes place in: the designers sure gave a convincing feeling that you were lost. So many areas of the game look identical to other areas that it’s very difficult to determine if you’re in a new place or if you’ve somehow looped back to where you had been before. The different areas in the game are linked together through “warps” that take away your sense of geography and you lose your spatial orientation. I couldn’t even tell if I’d left “world 1” and proceeded to “world 2” and then to “world 3” when I warped, or if the entire game was open to me and I was simply warping from Point A to Point B back to Point A. In several places the connection points from one warp area to another are stuck in dead-end passages that you would have no reason to walk down. They look like they’re merely “filler” space on the map and have no purpose.
Conclusions:
I was fortunate in that I discovered the game at a video rental store, so I didn’t waste my money actually buying it. A better title for this game would have been Super PitFAIL. This game was so bad it basically trashed the franchise. I never bothered even looking at any Pitfall title that came afterward. Activision’s execution here is abominable and inexcusable, a travesty to fans of the greatness that was the Atari-era Pitfall. This game has a lot of similarities to Super Mario Bros. when you look at a list of its features and the elements of play, but when you look further, the only real similarity these two games share is the word “Super” in the title.
To properly appreciate how badly designed AND badly constructed this game really is, you should watch a video of it on youtube. There are many, but one of the better one’s is by game reviewer Aqualung. (Warning, may contain objectionable language.)
I think that you need to understand that we are all taking a Computer Games and Simulation Class. You are required to make games. If you are told that what you are making is not a game and you stop listening to them then you obviously have not read the first lessons of this class. Be an advocate for the player, if you do want to listen to the player and continue doing what you are going to do anyways then that does not make you a team player or a very good video game designer. You maybe making something wonderful but in this class we are making “games” no matter what you want to call it this class calls it a game. That is why we are here to make games.
I get what you’re saying here, and it is a good point to make. Of course we want to be able to function in teams effectively. Of course we want our players to have great experiences with the things we build.
I’ll clarify what I said earlier by saying that I said that I don’t really find the question “what is a game” interesting. This is because I already know what a game is, and I don’t find a whole lot of mystery or controversy to draw my interest in the question as a philosopher. To me, it’s just not one of those fundamental, unanswerable questions like “determinism vs. free will” or “what is good” that will always be interesting to debate.
I think it’s fine to draw up lists of formal elements that we have found in games, and think about how these elements may be combined and modified to create novel games. That’s a good thing to do, in this class or otherwise. That said, I do think that it’s important to recognize that we need not constrain ourselves by the terms and definitions that we come up with. Language is a tool that humans develop in order to do useful things. But often we are too clever for ourselves, and trap ourselves with language and the things that we construct out of language.
Having a Theory of Games is useful, and it is especially interesting if you’ve never really thought about the nature of games before. If you’re trapped in language and don’t realize it, asking these questions can help you see beyond your horizons and grow as a person. Me, personally? Not so much, but to someone who might be taking this class, it quite possibly is.
My advice, then, should be seen as a caution: once you’ve come up with a Theory of Games that you think is very good, don’t get too attached to it. Philosophers often talk about different “camps” and talk about who they are in terms of who’s philosophy they’ve read and who they agree with, and so on. Humans seem to want to do this, but I think it just gets in the way of getting anywhere or resolving conflicts that separate us into different “camps”.
Imagine for a moment that we had this Theory of Game, which contained a mistake. To make a concrete example that we can all see clearly, let’s say that the error is that according to our broken theory, all games must have a scoring system. Now we’re forced to consider whether Super Mario Bros. 2 is a game or not. Clearly, nearly everyone would call SMB2 a game, without hesitation. And it’s often on many people’s lists of favorite games of all time. But SMB2 does not have a scorekeeping feature. If we’re trapped in the point of view that our flawed theory of games provides us, we will waste a lot of time arguing about why SMB2 isn’t “really” a game, because after all we all agree that all games must have scorekeeping.
To give another example: You can get into similar debates over whether hang gliding, cheerleading, auto racing, figure skating and other similar activities are “really” sports or whether they’re something else. If I told you “My favorite sports were baseball and sky diving” and you replied, “Hang on, sky diving isn’t a sport!” it wouldn’t take away from the fact that sky diving exists, that I enjoy sky diving, and that sky diving is a legitimate… “activity” of some kind.
To better illustrate the absurdity of arguing about theory, I might get further away from sports in talking about other things I like to do, and start saying nonsense like “painting is a sport” or “singing is a sport” and we can all see that they’re clearly not “sports” as we commonly understand and use the term. Now, it might be useful to have a well-considered Theory of Sports which we can use to precisely understand WHY painting isn’t a sport… but I don’t see much point in it, because in reality, there’s about 0% chance of me ever having to debate the matter seriously with anyone — we all know that painting and singing aren’t sports.
The fact that it’s undisputed that singing isn’t a sport doesn’t stop people from having karaoke contests, but we still don’t think of them as a type of sport. But if we did for some reason consider a karaoke contest to be a sport, it wouldn’t be of much consequence, either.
And there’s possibly a chance that some day someone might invent a new sport that incorporates painting in some way. I don’t want to stifle that guy.
To put it another way, does it bother any comic book fans that most comic books aren’t about comedy? Why get hung up on the term? Some people wanted to take comic books more seriously as an art form, so they started calling them “Graphic Novels”. But a lot of comics *aren’t* novels! Most of them are serials. Who cares what you call them or what the labels mean, just read them and enjoy them if you want to.
What you can take away from all this is: Beware the False Theory. If you’re taking a theory seriously and *using* it, always be suspicious or skeptical that it might have some flaw that you haven’t considered. Or, another way to put it, don’t worry too much about theories, and just do. Let the philosophers argue about what games are, or whether what you’re building is a game or not. Don’t let that deter you from exploring your ideas and doing what you want to do and what you enjoy.
In conclusion, I say that the term “video game” is merely an accident of history. It’s a good term, and I like it, but I’m not a slave to it. The first video game was called a video game, and the term stuck. But it might well have been called a “video toy” or a “video sport” or “video interactive” or something else. For that matter, the term “video” is accidental, as well. We could have computer games that do not incorporate video — text adventures are a notable example of this. These are worthy computer games, and if you substitute the monitor on which the text is displayed with a text-to-speech engine, the game is fully without a video component. We should not ignore or discount text adventures simply because they are not “video” games. And we should not ignore or discount “video somethings” that aren’t strictly according to definition “games”.
(Another good post I made in the class discussion board today)
When I was a kid, there were arcade machines everywhere. They had a few at the grocery store, or at the mini-mart, or at the gas station. Pretty much anywhere you could stick one, you’d find one. This was a wonderful period in the history of video games.
When I was a kid, I didn’t have a whole lot of money. I didn’t have a job, and I didn’t get much of an allowance. I rarely had quarters on hand. If I did they got spent on candy bars.
But I didn’t let that stop me! I’d walk up to the game and “play” its attract mode. Attract mode is the replay of recorded gameplay demo footage. I’d walk up, grab the controls, and pound the buttons. I’d get to “play” for maybe 15 seconds or so and then the Hi Score screen would display.
I bet millions of kids without quarters did this back in the day. It was a way of life for those of us not old enough to have a job, or too young to see over the controller deck.
It was a lot of fun, pretending to play a game. It was free, and I could play all day long. It didn’t seem to get boring. It didn’t matter that there was no actual interactivity. It didn’t matter that I didn’t develop any skill. It didn’t matter that the demo footage was always the same, looping over and over. It didn’t matter that the game made the same stupid mistake and kept dying over and over. To my 5-year-old self, it didn’t matter. I was playing the game. Pretend-playing, but it didn’t matter. Just like it doesn’t matter that I’m not *really* flying a *real* spaceship when I got old enough to put the quarter in.
As soon as I got older, of course, I lost the ability to enjoy pretend-playing a videogame. I might watch an attract mode and be amused by it, but I no longer attempted to pretend to interact with the demo. Fortunately, I had gained the ability to really-play a videogame.
