Things people find funny on the internet appear to be arbitrary and contrary in nature. Games as different as Saints Row and Goat Simulator can both be similarly categorised under ‘funny’, and that’s funny.
Saints’ Row is a game about gangland violence, and finds it’s origins in the decidedly unfunny circumstances of gang turf wars, and organised crime syndicates. The writing and dialogue, however, makes fun of itself and employs certain comedic elements in timing.
Goat Simulator is a game about a goat on a mission to headbutt all the things, and to be as disruptive as possible for your own amusement.
The scope of Saints Row is a lot bigger than scope of Goat Simulator, considering the former had been developed with a three arc story structure in mind, and the latter had only a single goal for the player to be as obnoxious as they pleased.
Development:
The design philosophy behind Saints Row’s arcing mission structure was to provide players with more freedom in how they interact with the open world. By developing three story arcs, the development team wanted to provide a nonlinear approach by allowing players to progress through the story at their leisure. Adhering to such a design philosophy created a challenge for the team, as they had to balance the open-ended nature of the mission structure with a story progression that felt natural and player-engaging.
The team wanted to synthesise game mechanics together to make the missions, activities and customization options work in tandem. Saints Row developers felt that previous open world games did not reward players for experimenting with the sandbox enough because story progression was siphoned off from free roam gameplay. From this sentiment, the concept of the activities developed; players in Saints Row were encouraged into off-mission content because progression through activities would unlock more story missions.
Whereas Goat Simulator started as a joke prototype from an internal one-month game jam and footage of it’s alpha state generated high amounts of interest and lead to it’s eventual success. The game was released with many glitches intentionally left in, in order to retain it’s appeal. The developers limited themselves to a short development time of four weeks without significant management oversight as to set an urgent but realistic goal to bring the game to a playable state. Support which would let players modify the game, was also added, as the developers were aware that players would likely create levels and scenarios that would glitch and crash the game for humorous results.
tl;dr version:
similarities: bad violent ragdoll physics is apparently very funny, as is random destruction. absurdity of the situation also brings laughter. self-awareness and pop culture references are also very popular because the player can point at it, nod and laugh along, feeling a sort of kinship in the shared joke.
differences: scope wise, SR was better planned and executed, GS just happened one fine day and the internet liked it so here it is. SR was a lot more considered in it’s development and lead up to execution whereas GS grew in a more chaotic circumstance where large amounts of people found it funny, demanded it be released and were obliged.
SR was planned quite carefully. GS grew in an organic way that did not require much planning.
Lovely write up! I like how you describe both games in such a simpler way and using your own words to explain them in details. It seems both project manager of both games have different agenda I guess and for the case of the Goat Simulator, it was an intentional decision to leave the game ‘incomplete’ so it is up to the players to finish it. This is an interesting unconventional way to approach a project and I am wondering if we can apply it in real life. Haha.
That’s where the next layer of interactivity lies, I suppose? To get the players to participate further and ‘complete’ the project for you. I think most interactive art works already have that element in some capacity.
Hi Faye,
I understand you are comparing projects “Saints Row” and “Goat Simulator” but can you please add links to the original posts on OSS of the two projects?
The idea of user/player feedback as part of the iterative design process is very apt. About the Goat Simulator: I’m intrigued by the idea that “many glitches [were] intentionally left in, in order to retain it’s appeal”. Can you explain more? Why do ‘glitches’ create appeal? What kind of glitches? And how did the developers get to know the ‘correct amount’ of glitches..? Would be great if you can explain a bit more how that worked. here’s another interesting observation that begs further discussion: You said that “and the internet liked it” (the Goat Simulator). How and when can this happen in general (can we MAKE it happen, or is it by fluke?) how did the “GS” developers know which glitches people liked in this specific case?
When you describe the design philosophy of Saints Row, you write “the team wanted to…” something something or “Saints Row developers felt…” so and so. Is this your personal interpretation from the experience of playing? or is it stated by the design team? Can you include a quote and reference (e.g. link to the company webpage where they describe the ideation of the game).
Your comparisons with specific game techniques seem relevant (e.g. “rag doll physics”), but do add a definition or give an example so the reader can follow how it applies to this case.
I think it was really good that you picked out the different nature of the two games and talked about how even though they are both games, the developing process was very different and for GS, the nature of the game required that process of it not being planned as precise as SR.
I don’t play games but it’s good to have this simplified explanation between these two games. It would be good to know the budget of creating both games.
A nice review between two similar projects executed in a quite different way. I like how you separate the projects from each other and line up their differences even from their initial start. But I think that you could have tried to describe how these differences affected the projects output, what divides a big scale project from a small scale when creating the product.