Office

Playing a text

 

 

Anuj Dhande | Ashish Kumar

 Shashank Gargeshwari | Vijith Rajvardhan

Game Jams are awesome. The feeling of competing against dozens of other teams to produce games as the clock ticks is amazing. It is a well-known fact that constraints bring about creativity, and therefore not surprising that some of the most innovative game design elements I've seen were created not by AAA teams made up of hundreds of people working for years, but a small group of hobbyists trying to hack together a game overnight.  Games like SUPERHOT and The Last Night are proof for this phenomenon of creativity under constraints.  I felt something similar when a few friends and I participated in the NASSCOM NGDC Bring Your Own Game Challenge organized in September 2017.

 

4 People banded together to create a game based on one of the topics given to us, "Abusive". Going from not knowing how to even begin to have an actual working demo game in just a couple of days was exhilarating, to say the least. This Game Jam led to Office, a game that experiments with new ways of experiencing text-based stories. 

Game Jams are awesome. The feeling of competing against dozens of other teams to produce games as the clock ticks is amazing. It is a well-known fact that constraints bring about creativity, and therefore not surprising that some of the most innovative game design elements I've seen were created not by AAA teams made up of hundreds of people working for years, but a small group of hobbyists trying to hack together a game overnight.  Games like SUPERHOT and The Last Night are proof for this phenomenon of creativity under constraints.  I felt something similar when a few friends and I participated in the NASSCOM NGDC Bring Your Own Game Challenge organized in September 2017.

 

4 People banded together to create a game based on one of the topics given to us, "Abusive". Going from not knowing how to even begin to have an actual working demo game in just a couple of days was exhilarating, to say the least. This Game Jam led to Office, a game that experiments with new ways of experiencing text-based stories. 

The hamster on the wheel

The hamster on the wheel

Projects, especially creative ones, tend to vary wildly from their initial conception. This one was no different. We decided to focus on workplace harassment, the kind where employees are overworked and underpaid, leading to poor work-life balance and problems that seep into their personal lives as well. The initial idea was to create a brick-breaker / space invader clone mash-up that features the players battling the boss in their Office. Although, if executed well, this would have been a compelling game, we wanted to tread new ground in gameplay and level design. I cannot seem to pinpoint how the idea came about, but we decided to make a game where the players can experience a story by "playing through it". It was to be a mix of reading and platforming, similar to how many of us imagine a "running man" jumping over obstacles when we look out of a moving vehicle.

Running through a book

The story revolves around Rajiv, a corporate mule in a dead end job and a partner getting increasingly frustrated with his inability to keep commitments. It is his anniversary that day, but his boss decides to assign him some last minute work. Rajiv, being Rajiv, doesn't protest. A couple of angry phone calls with his wife about the delay leaves his dejected, making him rethink his life. 

We decided to not reuse assets and code, deciding to make everything from scratch. This was a good and a bad decision, as can be seen later on. Ashish took up the job of animating sprites and making music for the game. Anuj made the background and splash screen. I wrote the story while Vijith helped me with the programming. We took about 3 days to get everything up and running, thanks to what I felt was an ingenious to generate the word-platforms.

Gizmos and where they fail

Gizmos for setting object positions

The transform gizmo provided by Unity allows us to move an object about in the game scene. There is also an option to set the numerical value to set the position. Although these tools are adequate under most circumstances, they would prove to be prohibitive in our case as we had to set positions of around 300 word platforms and iterate upon their placements dozens of times. Moving even one word-platform would mean changing the positions of all platforms that follow, which is torturous to say the least. There had to be a better way. 

The trick was to identify that the absolute position (or in Unity terms, position in World Space) of a word-platform only depended on the position of the previous word-platform, and its position relative to the previous word-platform. This would mean that, given a fixed position for the first word-platform, the positions of the rest can be defined using the position of the first word-platform and x & y deltas between 2 consecutive word-platforms.

That is 

if there a n word-platforms, 1,2,3,...,n

if position(i) = x,y position of the ith word platform,

if position(1)= a (fixed position of 1st word-platform)

and

delta(j-1,j) = x,y position offset of word-platform j from the previous word-platform j-1

then position(1) = a (given)

position(2) = a + delta(1,2)

position(3) = position(2) + delta(2,3)

... 

position(n) = position(n-1) + delta(n-1,n)

These deltas could be embedded in the word file that contains the story itself, and the word-platforms generated dynamically whenever the level has to be created. This asked for the specification of a custom grammar that defined these offsets. 

A custom "spacing" grammar

For embedding the spacing information in the text file containing the story itself, the following custom grammar was created. 

Custom Grammar :

>xy : delta of +x units and +y units

<xy : delta of +x units and -y units

[Note: in our game, the each platform has to be to the "right" of the previous platform. So delta-x for any platform is always positive. However, the platform can be above or below the previous platform, so

delta-y can be positive or negative]

 -xy : create a moving hyphen platform that moves in a gap that is the 2 digit number xy units wide

punctuation symbols : attach a special "spring" script to them so that the character can launch off of them

* : insert a telephone (save point) over the previous letter

 

Let's see these rules in more detail.

>23 on the left translates to the gap (delta) on the right

A "parser" was created that reads the word file and generates the level accordingly. As can be seen above, the spacing grammar helps easily specify the gap between two platforms. Although this seems like a minor application, the true power of it is realized when you start iterating over the text. You have to make changes only in the word file to see the changes in the game world. Also, since the positions of word-platforms are defined in terms of the positions of the word-platforms preceding them, changes only have to be made in specific areas without having to worry about how it will affect the rest of the text. The platforms will redefine their absolute positions flawlessly, leading to faster and easier iteration. This system of generating levels based on word files has a lot of potential, especially for games that lend themselves to the kind of linear definition texts have. There are some obvious limitations, like the inability to create "double-decker"  platforms, but for an initial prototype, this was quite useful and demonstrated real-world increase in productivity and usability. Moving on.

-08 creates a moving hyphen platform in an 8 unit gap

The hyphen-moving-platform showcases another important aspect of this system. The movement of the hyphen-platform is not defined in the text but is instead a script that has to be attached to the moving platform game object. The text parser attaches this script by default to all hyphens in the text, and the 2 digit number following the hyphen defines how big the gap should be in which the hyphen-moving-platform will move about. Of course, with a subtle change to the grammar, we can make the parser attach the moving platform to any other element we want to, be it letters, words, or entire sentences. This sort of "hybridized" control of game elements allows us to relegate certain tasks to either the text, the interpreter, or the game engine itself based on convenience. In this case, movement of the hyphen was quite hard to define in text, so it was relegated to game engine scripts, while the gap in which the hyphen moves about was handled by text.  

The * translates to a phone (save point) placed on the letter before, e

Since the script had phone calls in it, we decided to make these phone calls an integral part of the game. Phones were placed at the beginning and end of each phone conversation. Whenever Rajiv reaches the phone at the beginning of the conversation, he would pick up the phone, saving the progress at that point. When he reaches the phone at the end of the conversation, he would keep it down, saving the progress once more. The game was evenly interspersed with the phone calls to ensure progress was saved regularly. 

A little attention to detail can go a long way

A lot of people who tried the game out found the fact the Rajiv actually picks up the phone quite amusing. People seem to not only love but demand attention to detail in games. Subtle things that are non-critical to the working of a game can still massively increase its value in the eye of its players, and the phone animations were one of those things that people really seemed to enjoy in our game.  

Weeeeeeeeeeeeeeeeeeeeeeeeee!

The final thing that spiced the game up a bit were the punctuations. Since punctuations were easily identified by the players and they usually occurred at a "different level" (most would be above or below the letter ),  we decided to make them springboards. The punctuations would launch players into the air, making them progress much faster in the game, but at the risk of falling down because they are not able to see what's below. This added a well-needed sense of thrill that the simple platformer was missing. So, it was a great game, right? Unfortunately, no. 

The final thing that spiced the game up a bit were the punctuations. Since punctuations were easily identified by the players and they usually occurred at a "different level" (most would be above or below the letter ),  we decided to make them springboards. The punctuations would launch players into the air, making them progress much faster in the game, but at the risk of falling down because they are not able to see what's below. This added a well-needed sense of thrill that the simple platformer was missing. So, it was a great game, right? Unfortunately, no. 

so, what gives?

There were three main reasons Office failed to live up to it's expectations. I am going to outline them here so that others might avoid the same mistakes that we made while developing it.

 

 

1) The game was buggy: Remember that I mentioned that everything was built from scratch? The good thing about that was we were bound to come up with unique solutions to the problems we faced. The bad thing was some of these solutions weren't very great. 2D platforming physics is pretty well understood at this point, and there are certain things players have learned to expect from it. In comparison, our implementation of the platforming controls felt "floaty", and in certain scenarios, downright broken. We were using colliders to check grounding of the player character, whereas a better, well known, and widely used solution was to use raycasts. This lead to a lot of bugs, breaking immersion. In fact, Unity has basic tutorials for 2D platformers that we could have at least referred to, but we didn't. I learned from that mistake, and my later 2D platforming games like TwoFold and TimeWench implement better platforming physics that are more in line with what people are used to. 

 

 

2) The game was super hard: You know your game is too hard when half the people who played it couldn't clear the first jump. This came as a surprise to us because we were used to how the game handled and had played it hundreds of times while we were developing it. Since it was a Game Jam, we didn't really bring in other people to playtest the game before we submitted it. Big mistake. Most people couldn't even make it halfway through the game, and none ever finished it. This was particularly devastating because we had kept the best part for the last. If you are reading this, do us a favor and finish the game. It might take you a couple of hours, but it'll (probably) be worth it.

 

3) Didn't serve the purpose: The main goal of the game was to tell a story through the text, but people tended to ignore it because they felt that the important part was to get the jumps right, not to read the text. This is similar to the problem that other games face, where some players might tend to ignore an intricately crafted story because, for them, there is more incentive in hunting down goblins and such. There is a number of ways this can be alleviated, like choosing the right audience, changing the gameplay to accommodate both story and play lovers, or letting them choose. The more important thing is to identify this at an early stage, which ties in with the idea of the importance of playtesting mentioned in the previous point. I'll repeat once again. Let other people, preferably a lot of them, playtest your game!

All said and done, Office was my first introduction to the concept of a game jam, and I found it exhilarating to compete with other groups made up of talented people trying to come up with something unique. I will be participating in more game jams whenever I can, and will hopefully get better over time. If there is one thing that Rajiv can teach us, it is that there is always 

Graduate Student | Digital Game Design 

©2018 by Shashank Nagaraja Gargeshwari.