Outcome

Proposal

The idea behind our project was to create a simple game, because what more embodies the essence of a playground than games? Specifically, in this project, we wanted to capture the aspect of 'selfish' play on a playground, represented through game mechanics that mirror the 'Prisoner's Dilemma'. Play on a playground or even in a videogame is not all sunshine and cotton candy. Some people will prioritize their own enjoyment, even at the expense of others. A bully may destroy someone else's sandcastle, or a videogame player may 'grief' and harass others within the game. However, this is not without cost. We wanted to try and recreate this through fast-paced gameplay based around the 'Prisoner's Dilemma'. The Prisoner's Dilemma is as follows:

  Two members of a criminal gang are arrested and imprisoned. Each prisoner is in solitary confinement with no means of communicating with the other. The prosecutors lack sufficient evidence to convict the pair on the principal charge. They hope to get both sentenced to a year in prison on a lesser charge. Simultaneously, the prosecutors offer each prisoner a bargain. Each prisoner is given the opportunity either to: betray the other by testifying that the other committed the crime, or to cooperate with the other by remaining silent. The offer is:

• If A and B each betray the other, each of them serves 2 years in prison
• If A betrays B but B remains silent, A will be set free and B will serve 3 years in prison (and vice versa)
• If A and B both remain silent, both of them will only serve 1 year in prison (on the lesser charge)

Gameplay will have two players on a split screen, jumping over a series of blocks coming towards them. The goal of the game is for one person to either make it to the end, or outlast the other. Each player has a button, which makes their avatar jump. However, there is a third, shared, button that when combined with a player's button, disrupts the other player's gameplay. The other player then has a set time in which if they press their own button, then both players will have their gameplay disrupted, possibly fatally. 

Curatorial Statement

Game of Boxes explores the idea of competition vs collaboration.  Two players jump over obstacles in a battle of endurance. Each has two buttons, one which jumps, and another that speeds up his adversary and the player down. The aim is to survive until your opponent dies. It plays upon the idea that when people play games they will, rather than play to win, play to ensure the other person loses. We wanted the players to experience the thrill of winning and the anguish of defeat in this low stakes game. We also wanted people to discover just how willing they were to try and mess with the friends in order to win. Just remember when you play the game of boxes you either win, or you die. 

Product 

We created an "Endless Runner" type game, wherein a player runs forward along an infinite plane, while jumping over obstacles. However, this game in particular introduces competitive elements, in that there are two players, and they can actively try to disrupt one another. Each player is given a button that slows himself and speeds up the other player, affecting their respective difficulty in jumping over the obstacles. Initially, it was intended that the game mechanics reflected elements of the Prisoner's Dilemma, by causing both players to speed up if they both pressed their alternative button within a set time period, however, due to technical and knowledge constraints, this was not to be.

Intention 

Brandon: The intention in making this game, was to recreate the feeling of one playing video games with their friends, in the same, room, on the same screen, unlike today where much of gaming is done online, without face-to-face contact. In particular, I wanted to capture the tendency for players who were friends, to throw one another under the bus in-game. Thus, came the idea of using the Prisoner's Dilemma as a basis for the game's mechanics.

Because it is playground, we wanted to make something we can play with friends. Together with friends, we further thought that ideas of collaboration and competition should be involved. We tried to make the collaboration and competition special, so we came up with the idea of Prisoner's Dilemma. (though we didn't really achieve Prisoner's Dilemma in the end because of code difficulty)

Also, since we want to make the playground simple and fun, Brandon came up with the idea to use simple buttons to control a box to jump. The amazing part is a really simple game can make people really enjoy it, because competition is involved.

Context 

The original idea came from The Impossible Game. There is only one box jumping over spikes and blocks. In order to create an interactive game, we made it a two-player game. Also, we want to make it fun (break the rule), the spikes and blocks are generated randomly. Sometimes when you are higher than certain speed or lower than certain speed you will not be able to pass certain obstacles, but you don't know when will those difficult obstacles come. When you just aim at increasing your opponent's speed, you may find out you cannot jump over a single spike because your box is so slow. Those are the changes we made to the game mechanics.

Instead of letting people press keyboard, we use buttons. People will feel that they are using a machine from arcade (at least I felt that way), which brings more fun.

Process 

At first we only considered what kind of game would be fun to play. We tried to get rid of code complexity (not making it a cs project),  but there were no good ideas. After asking Daragh and having more discussion about the basic idea of playground, we generated our intention for this game, as written before.

Then we tried to think of some games using Prisoner's Dilemma. Mingquan had an idea that two players climb ladders. When they press left button they climb by one stage; when they press right button they climb by one stage, and the other fall by one stage. But if both of them press right buttons, they will fall by two stages together. If a player falls behind certain stages (say -5, if 0 is the beginning), then both of them lose the game. i.e. a player can only win when the other player does not lose the game. But we thought the mechanics of this game is kind of simple, and players may fall into stalemate really easily, so we didn't use it.

Then Brandon said his idea about the box game. The original game mechanics was that when you press the right button to mess up your opponent, the effect would be let him jump. We discussed about that but thought players might die really easily, since the opponent can choose the time to make you jump onto spikes. That was why we changed 'let your opponent jump' into 'increase your opponent's speed'. In order to make a balance in this game, later we changed 'increase your opponent's speed' into 'increase your opponent speed as well as lower your speed', or players would never be able to lower their speeds.'

Since none of us is familiar with C#, the function of pressing buttons together was not implemented. But the other game mechanics create some new strategy to the game. For example, if you are really harsh to your opponent and increase his speed really much, you will not be able to jump over a single spike, since you are so slow. Also, you cannot increase your speed yourself, so you just place yourself into death by treating others so bad. People can find more when they play this game.

At first we wanted to created pixel characters for the game, just like Super Mario.  googled some tutorial on"how to create pixel characters" and found out it is way more complicated than we thought. so we decided to go with stick figures instead.

(Tutorial link: http://makegames.tumblr.com/post/42648699708/pixel-art-tutorial )

But later we thought maybe using a box as the character can make the game special, since this game is a simple game based on geometric shapes.

When creating the background music Kaalen used a software called famiTracker. It simplifies the process of making chip tunes by giving the user access to the different sounds that were available to the 8-bit video games from where chip tunes originated. He followed a tutorial online which gave him a basic idea of how to make a chip tune. You start with a bass line and then make a drum track.  then you build a melody on top of that and voilla. Kaalen used his musical knowledge to make interesting sounding tracks that tried to emulate the feeling of the game. Although only 2 tracks were used Kaalen made 4 tracks total. 

Above is FamiTracker. The letters are notes on a piano and the numbers correspond to their location. When using the software the keyboard essentially becomes a piano so you just type in what notes you want where. 

Reflection

Brandon: I think this project was a very interesting and difficult one, though I learned alot. Initially, we were very hard pressed to find and idea for a project that did not use code, since none of our group were very well versed in coding. However, after deciding on the game concept, I decided that I'd learn to use C# and Unity to create the game. I think much of my difficulties in the creation of the project were in collaboration and communication. We didn't really know how to use collaborative software such as Github, so in the end, the other group members, weren't able to help as much as they wanted. For example, at times I couldn't communicate my needs effectively and I ended up spending time doing artwork instead of coding. This resulted in me losing time in bug-fixing, and in the end I had to pull an allnighter to deliver the final product, which still was not bug-free. If I were to do the project again, I'd make sure to create more avenues of collaboration with my teammates, and in terms of the game, I'd make sure early on to figure out the use of time elements in Unity to properly implement the Prisoner's Dilemma.

We did a good job in general. We learnt how to make things in the process. If we had the second chance, we would definitely make sure the Prisoner's Dilemma could be applied in the game, since it was our original starting point. Discussing what kind of game we should make and what kind of features we should add is really hard, since everyone may have his or her opinion. It was really good we had an agreement. We could also add special effects to the game if we have more time. For example, the explosion animation when player dies, and changing background when players go further. If it is possible to make players play on two machines, we could also make their background music changing with the speed of their player respectively. There are some possible features we can add to make this game artful.

Also, we should have had more meetings. We met sometimes at Hunt Library to discuss ideas, but each person just did individual work. It was almost final so people did not have same time period that were free. If we worked together more and discussed more, better ideas might be 

Attribution

Much of the game mechanics were inspired by the Impossible Game.

Collaboration

For this project, Brandon was responsible for the coding part, Kaalen was responsible for the background music. Mingquan and Jessica were doing the graphics and character stuff. We discussed ideas together first, and did our individual work then. We also discussed on groupme and shared the problems, reported the process.