Sheep Catcher

Sheep Catcher

Nathan Hughes

Sara Hoke

Martin Shuman

Salome Navarrete

Eric Xue

Introduction

Sheep catcher is the exciting flash game in which a farmer tries to save as many of his escaped sheep as possible. Farmer John had gone to bed one night and awoke to find all his sheep had escaped! After grabbing his wheelbarrow farmer John raced off in the direction the sheep tracks took him. On his journey he encounters brick walls he must scale, lazy pigs that trip him up, and what is that? Flying sheep?

Your view is of the field side scrolling by to your left. You control the main character, farmer John, and have the ability to move him left or right with the directional keys. Farmer John can also jump a fairly good height using the up directional key. As you move along be sure to avoid the brick walls, as they will hold you up. The pigs must be avoided as well as farmer John and his unstable wheelbarrow will topple over if they are hit.

Catching sheep in your wheelbarrow by hitting them is the object of the game. Each time you catch a sheep you receive points. Those interesting flying sheep are worth even more points. There are also black sheep that will appear out of nowhere. If farmer John captures these sheep he will lose one point. Ten captured sheep will complete each level. Your points are displayed as you go in the upper part of the screen. Each level is timed, and you will receive bonus points once the level is completed, however, points are deducted as time goes by, so be sure capture the sheep as quickly as possible.

As the levels go by and you achieve higher scores, the levels will progressively get harder, and faster paced. There will be increasingly more walls and pigs. Farmer John will also increase in speed. You will not have the ability to slow down as much as in the beginning levels. Once you complete a certain number of levels there will be boss that tries to stop farmer John. You must defeat this boss to move on. The object of the game is to last as long as possible and get the highest point total, or to complete all five levels.

Design

Sheep catcher is a game of progression. There is a very limited amount of outcomes. A player’s score will simply be different depending on how well they do. The game type is perfect. There are hardly any hidden or revealing systems built into the game. All players have complete knowledge of the rules. Apart from the levels increasing in difficulty, there are no unexpected situations.

In sheep catcher players cannot come across degenerate strategies. The objects that come at the players to challenge them are programmed randomly, so it would be impossible to create a degenerate strategy to win every time. In the game there are also positive feedback loops. An example of one would be to go for the flying sheep instead of one on the ground. This will give players more points, and therefore make them aim for them more often.

The conflict in sheep catcher remains the same throughout the game, single player versus the computer. The challenge of avoiding obstacles starts out easy. This accommodates for all player skill level and gives everyone a chance to score. The levels slowly increase in difficulty until only players of a very high skill level can pass. Players of any skill level can set their own personal goals (i.e. a certain score) to achieve.

The core mechanic of the game is speed management and jumping. The player is allowed to vary the character’s speed from a near stop, to a breakneck speed, but at no point is the player allowed to completely stop, or change direction. This forces the player to be aware of his/her surroundings enough to avoid any obstacles before he/she runs into them. In order to avoid obstacles, or catch the elusive flying sheep, the player must also jump. Jumping allows the player to avoid the pigs and walls that can hinder or injure the character. Jumping can also be a drawback, because if a sheep is hiding directly behind a wall, it is possible that the player will jump over both the wall and the sheep, and since the player cannot change direction, the sheep then impossible to collect, and will count against the player at the end of the level. The union of speed control and jumping is the core mechanic that drives gameplay. The game is not as difficult or entertaining if the player is always moving at the slowest possible speed, but the game is considerably more difficult, and not always possible, at the highest speed. The ability to control the speed dynamically allows for the player to make the game more or less difficult in order to ensure that the player is having the best gameplay experience.

This contributes to the conditioning present in the game. The player quickly learns that the only way to avoid a wall or a pig is to jump over it, and that avoiding this action can quickly cause a negative outcome (i.e. dying because of hitting a pig). The player is also conditioned to be sure to collect every sheep that they can, in order to avoid a high “sheep missed” counter at the end of each level. The first time that a player manages to capture a flying sheep, the player will likely realize that the flying sheep provides a larger score increase than an ordinary, “terrestrial” sheep. This will condition the player to pursue as many flying sheep as he/she can in order to achieve the highest possible score.

Rewards are present in the game mainly in the form of Rewards of Glory. The score that a player attains at the end of each level has no impact on the actual gameplay, but allows for the player to gauge his/her improvement, and allows the player to compare scores with a friend (or rival) to determine superiority. A higher score is a more substantial reward.

The game achieves flow partly through the progressively difficult levels. The early levels of the game are easy, and allow players with low skill levels to progress through the game. The ability to slow the character’s speed allows for inexperienced players to decrease the challenge of the game to fit their skill level, allowing them to attain flow. In each level, the difficulty and challenges of the game increase as obstacles become more frequent. This allows players with higher skill level to achieve flow later in the game. In the early levels where a skilled player might get bored early on in the game, the player has the ability to increase the speed of the character, which not only causes the challenge to increase, but also causes the player to progress through the early levels faster, in order to access the levels that are more challenging. The ability to change the speed of the character, as well as the increase in level difficulty allows for players of almost any skill level to achieve a state of flow with the game.

The game primarily uses the in-game art style as the main narrative descriptor. At the main title screen of the game, there is a background story for the game, but most of the feeling for the fictional world comes from the look of the pigs, sheep, farmer, and the landscape. Through the back-story and the art design, the game has a coherent game world. The game is tied closely enough to reality for players to understand how things should work in the larger world that they imagine

Implementation

In Sheepcatcher, multiple components are attributed to the overall experience and implementation of the game. The gameplay and core controls, for example, consist of more than one given command and action. The player controls the farmer and is given the ability to jump, move forward in the screen, and move backwards to slow down. All these characteristics of gameplay are related to the experience and context of the game. Since the structure of the game is complex as opposed to simplistic, all the various components are interrelated and function as an entity. The organization of the components more or less is displayed in a windfall effect and typically one or more component is related with another. The total summation of all the components and their corresponding roles determine the integrity of the game’s functionalities and it’s provided contexts.

The primary mode of interaction and a critical component of the game is the player’s usage of the keyboard and the designated controls. Using the arrow keys in the supplied instructions will move the character on screen. The farmer is assigned as the main character in the game and through the use of the keyboard; the player’s inputs correspond to the farmer’s movements. The game’s goal is, in a generalized notion, to safely move the farmer on screen to the end of the level while collecting as much sheep as possible to increase the total point count. The total amount of points is another component in the game that we use as a measure of the player’s proficiency at the game. The more points the player has means that he or she was able to complete the levels with a low number of lost lives and a high number of sheep collected. More components are implemented into the game’s core structure to determine the ultimate point collection. For example, as the player moves the famer, the position of the character changes as well and so do its collision area. Walls and other barriers are built into the level and the clashing the farmer with such obstructions will impede the process. This is then broken down into more areas of viable collision, such as with pig characters that are opponents and decrease a life on impact.

Colliding with a sheep, on the other hand, raises the total number of sheep caught and coincides with the game’s objective. The player’s physical interaction with the game is another part of the implementation, and a free choice is given to the player. He or she is allowed to make decisions that relate to the game’s components and therefore strategic thinking is feasible. Subsequently, the implementation of a player’s choices and plans are correlated with his or her dexterity with the game’s controls. The game’s components are all organized in such a way that promotes interaction and serves to enhance gameplay and player experience as a whole. The following diagram illustrates the interrelation of the game’s major components from a high level.

Part of the game’s structure is the implementation of various objects that the player must interact with. The farmer himself is an object and is composed of various symbols and animations. As the player is moving along the screen and level, the legs of the farmer have their own “running” animation to depict motion. In relation to the feeling of movement, the backdrop of the level side scrolls in the opposite direction and it itself is a repeating object/symbol. The scrolling terrain utilizes actionscript and has an extra set of variables assigned to make it function. The width, height, and scroll-speed of the terrain are some of the variables used in conjunction with actionscript. When the character jumps, another animation is given to the farmer to show a leap. As previously mentioned, walls and other characters such as pigs and the sheep are also objects in the game. Actionscript and its entailing collision detection wrap the game into one package. Each object has its own name in flash, such as “farmer” and “sheep” that are used in actionscript to differentiate from one another. The farmer and character objects are given their own radius and area of collision and when their collision area intersects with one another, another set of action is given to the objects. For instance, when the farmer comes in contact with a pig, the player loses a life. When the farmer comes in contact with a sheep, the sheep goes into the wheelbarrow and they gain a sheep count. All the objects in the game not only account for the visual interpretation by the player, but also serve as core components that drive game play.

While implementing our game, a few problems arose during the design process. Early on after we built the game’s engine and the implemented the character’s movement into the side scrolling platform, the farmer’s character wouldn’t collide properly with other objects. For example, the body of the farmer and the wheelbarrow would clip into walls and other objects before detecting them. A similar issue was that sometimes the farmer would be right over a sheep and still not pick it up. The problem was later resolved with some tweaking in the actionscript between the objects and increasing the hit box area of collision. Another problem that arose, which is attributed to the overall context of the game and level design, was the number of sheep that could be held. We wanted to visually show sheep stacking up in the wheelbarrow as they were collected, but there had to be a limit to do so. This was solved by lowering the number of sheep contained in the levels and making separate symbols for incrementing number of sheep stacked in the wheelbarrow. During the later stages of design, another issue that arose was the total summation of sheep would add up incorrectly. After the completion of each level, a tally of sheep collected would be displayed on the screen for the player. This number would be off or sometimes remain at 0 and not count at all. Again, this was an actionscript related problem and debugging the code proved successful. In a broader perspective, another problem we encountered was that we wanted players to be able to play multiple numbers of levels, and not just a select few. We initially planned on placing enemies and barriers manually and designing each level individually, but this would prove tedious. A solution to this was to implement a randomized generation of level-based objects and opponents via actionscript. This not only allowed scalable levels but greater numbers levels with different placement of objects, etc.

Iterative Development

Iterative Process/The Idea and the Structure

We followed a play-based design process, focusing on tossing around ideas, prototyping our simple ideas, and having others playtest the prototypes and evaluating the feedback and refining our prototype until we reached a (mostly) finished product. All this was done to achieve a game that created meaningful play for the user.

The first step in our design process saw us sitting at a table tossing ideas back and forth. One of the first suggestions was…Sheep! Lets do a game with sheep! Everyone likes sheep. We ignored that and tried brainstorming something more serious…snake ripoffs, a series of simple minigames, where the core mechanic would be you could play a certain game or a certain character after answering a series of questions, and we could have a laugh while people tried figuring out how to get to another game by answering the questions when in reality it would be determined by, say, the first letter of your last name…After a lot of feasible, semi-feasible, and completely ridiculous ideas we began to seriously consider the sheep, because honestly, a game involving sheep is tempting and addicting enough just because of the attraction of sheep.

Once an idea was decided upon, we began to prototype the game not by immediately using flash, but by fleshing out a storyline, coming up with possible features to include in the game, and constructing a purpose/how the game would be played. All this was part of the preliminary prototyping design phase of the project.

The next step in our design (still not relying heavily on flash) was the physical art and design of the game. This was a major component of our 1st milestone presentation. We began solidifying our game concept and developing what would become the core mechanic of our game (Sheep catching!). We storyboarded our game, with different points of what in-game play would look like as well as character design and design of the various characters in it. Also during this stage we polished up the concepts of how the storyline and play would happen.

Our third phase in the iterative design was using flash to build a very rough but working game prototype to start our playtesting phase. This was our longest and most time consuming phase. The initial incarnation was simple flash drawings of the sheep, farmer and wheelbarrow characters to test out our first addition, the side-scrolling game engine and see how that all worked together. We tested that among ourselves to work out most of the bugs in the actionscript so that it worked the way it was supposed to. As that worked, we began to add features and remove features, each time a person added a feature we playtested as a team, noting errors, bugs, and whether or not it was fun and trying to determine any replayability or interest it would generate. Once we had a prototype farther along, we began asking random people, friends, and basically whoever was in the general vicinity of us at the time to play it and give us evaluations. We used this feedback to determine what went into the final game.