Saturday 4 December 2010

Retro Game Review: Frogger (Draft 1)

      Frogger (1981) is an arcade game created by Konami in which the player must navigate their way through and around various obstacles, which take the form of cars and logs and other sprites which are introduced in the later stages of the game as the difficulty increases. The aim of the game is to make your way across a road and a lake towards five bays in the quickest time possible for maximum points. Frogger and other retro games released around the 1980/90’s make for good case studies when attempting to analyse game mechanics as well as dynamics due to the simplicity of their nature and generally basic controls, which is something that Zegal makes testimony to, stating that “…Classic arcade games are theprimordial soup’ from which many of the future conventions of games design were proposed…” and later going on to describe them as the ‘building blocks’ for contemporary games, which is very much the case with Frogger.
 
    A typical version of Frogger

     Starting with mechanics, Frogger is a simple game using basic controls (left, right, up, down) and a basic point scoring system. This mechanic reinforces the ‘pick up and play’ element of Frogger, which Marcos Venturelli states in his article ‘Space of Possibility and Pacing in Casual Game Design – A PopCap Case Study’ are “…experiences that can be enjoyed in small bursts and interrupted by the player without penalty…” The game’s rules and mechanics are very much understandable within the first play through before the player exhausts their three lives, which are given at the beginning of each wave game. The ‘lives’ that players are given initially allow players to begin establishing patterns in the game and discover tactics with which they can beat each wave before they get a ‘Game Over’. This is a topic that Koster [2005] touches upon, saying “…the natural instinct of a game player is to make the game more predictable…” During the first wave, players can begin to do just this, however on the second wave new obstacles are introduced to prevent the game from becoming solvable too quickly, this is done by increasing the speed at which the cars move across the screen thus increasing the game pace as well as the difficulty. Further waves follow this trend, on wave three snakes that navigate the pavement (which by this stage players would have established as a ‘safe zone’), which will take lives depending on whether they hit the player and some logs which are needed to cross the lake are replaced by crocodiles, which forces players to quickly change their patterns and adapt to these new obstacles. This consequently creates a change in the game's state, keeping players engaged. In Doug Church’s article on ‘Formal Abstract Design Tools’ he mentions, “…The key is that when the plan doesn't succeed, players understand why. The world is so consistent that it's immediately obvious why a plan didn't work.” This is regarding visible feedback and creating game responses that indicate to the player whether what they did was right/wrong. In the case of Frogger, incorrect choices/'deaths' are highlighted using small animation that shows the frog disintegrating and being placed back at the beginning when they accidentally fall in the water or get struck by a car. Also a little sound clip is played every time the player dies which also indicates that whatever they attempted to do was wrong. Right choices, being successful hops across the screen or grabbing a bonus bug are indicated by increases in score and again by a more upbeat sound clip.
    Back-tracking to the introduction of new obstacles in Frogger; what works well with this method of keeping the game fresh is that these obstacles aren’t forewarned, adding elements of surprise to the game. This emphasises on the ‘struggle’ aspect of Frogger and begins to increase the importance of decision-making. In Costikyan’s article ‘I have No Words & I Must Design: Toward a Critical Vocabulary for Games’, he states “…putting other obstacles in a game can increase its richness and emotional appeal...” I think what Costikyan means by ‘richness’ could be interpreted in a few ways, with regards to Frogger; the ‘richness’ is gained in terms of challenge by increasing the speed at which the obstacles move, adjusting the spaces between the obstacles i.e. Decreasing the space between the cars making it harder to reach the lake or decreasing the amount of time the player gets to reach the bay. 
    Whilst I’m around the topic of pacing and tempo, and referring back to Venturelli’s article, he states “…to create relaxation, tension and repetition the designer “paces” the game.” the time limit aspect of Frogger is one of the main means that the game does this. Players are compelled to attempt to reach the bays quickly as possible as score is partially determined by the amount of time it took to do so. If the time limit runs out, players also lose a life. It’s also worth mentioning that when the time limit is running out, fast paced music begins to play which again builds up the tension. Other elements of the game contribute towards the pacing, like the bonus bugs which will randomly appear on passing logs that start to create different dynamics and paths the player can take towards the goal. Do I hop across this path of logs that has conveniently appeared for a quick and easy score? Or should I backtrack across logs and try and grab the bug before it disappears and earn myself some extra points? It’s the frequency of these decisions that keep Frogger entertaining and well paced during the beginning waves. 
    What also works well with Frogger, as well as other retro arcade games like Pacman (1980) or Asteroids (1979), is the scoring system. Generally speaking it is considered bad design when games have no ultimate goal or end to a game. Costikyan states in his article, when talking about goals that “…most games have an explicit win state, a set of victory conditions…some games do not have explicit goals…” The ‘Hi-Score’ system used in Frogger is in it’s own way a primary goal. Players continually attempt to overcome the obstacles each wave presents in order to beat scores set previously either by themselves or others. The small bug bonuses could also be considered microcosmic goals within the game. This turns Frogger into a survival game as opposed to other retro games around the time like Galaga (1981) in which a player typically plays to complete the game. This however is only the case if players who see this as a worthy reason to play Frogger and accept that this is the case. In ‘Challenges For Game Designers’, by Brenda Braithwaite and Ian Schreiber, it is mentioned that, “Goals typically provide rewards that motivate players…” Translated in the case of Frogger, the only real rewards gained by a player from playing Frogger is the satisfaction of knowing that they have beaten a high score, which also the motivation, which for some may not be enough.
    With regards to the game structure, Frogger generally speaking proves to be fairly entertaining, with a slightly increasing difficulty as waves progress and introducing new obstacles, however; these elements new mechanics are all exhausted within the first few rounds. After a few rounds the challenge of attempting to cross the screen becomes slightly repetitive and players are met with the same scenario wave after wave, which unless the player is enjoying trying to achieve the high score; can get dull. As simple as Frogger’s mechanics are, they are mechanics that are given away too early on in the game however adding bonus bugs and harmful sprites slightly as well as a possible urge to beat high scores increase the games longevity.
    In conclusion Frogger is a fairly solid game in places, containing obstacles in the form of harmful sprites and time limits, short and long-term goals as well as a few bonuses thrown in for good measure. The replay value of Frogger is essentially only determined by a players’ desire to beat high scores and nothing else. Players who aren’t concerned by this may probably find Frogger a fairly pointless game. I suppose adding a narrative to Frogger may overcome this however I think that may be desecrating something that is considered somewhat of an arcade classic. I personally find Frogger enjoyable for a while, playing it through two or three times in attempt to find out what the later waves contain however after a few ‘Game Over’ screens, I find it hard to bring myself to start up another game. Perhaps this may be an aesthetic issue? Could Frogger be more exciting with a new skin? Or have I become a victim of contemporary gaming?

2 comments:

  1. It's at 1475 words...is that enough or should I try and beef it up to 1500?

    ReplyDelete
  2. Hi tom

    This is a good start in need of more work, which you should be able to do.

    1) Every essay needs a structure, this does not have one. Choose an author you have quoted and use the structure of their argument, as you did with Costikyan to organise your review.

    - then feed in the other authors as necessary.

    That will prevent lines like this:-

    Whilst I’m around the topic of pacing and tempo, and referring back to Venturelli’s article, he states “…to create relaxation, tension and repetition the designer “paces” the game.


    2) Only make one major point per paragraph and let the reader know what it is.

    3)You are putting too many different points into single sentences like this, which leads to confusion:-

    Further waves follow this trend, on wave three snakes that navigate the pavement (which by this stage players would have established as a ‘safe zone’), which will take lives depending on whether they hit the player and some logs which are needed to cross the lake are replaced by crocodiles, which forces players to quickly change their patterns and adapt to these new obstacles.

    4) on a point raised

    “…The key is that when the plan doesn't succeed, players understand why. The world is so consistent that it's immediately obvious why a plan didn't work.” This is regarding visible feedback and creating game responses that indicate to the player whether what they did was right/wrong.

    You have spoken here about the mechanisms for letting a player know if a decision they have made is right or wrong, Church is actually talking about how a player gains an understanding of Why something happened, that is rather different.


    5) follow my advice in the lecture on the procedures for a final edit, the more you do and the less i end up doing the better.

    hope this helps

    rob

    ReplyDelete