DIGC302 Critique of Get Game
Over the course of this semester, I have been following the project of Angus Baillie and Olivia Harris, which they have coined ‘Get Game’.
In an attempt to make digital games and gaming culture more relatable for the typical, non-gamer student, Angus and I workshopped a couple of ideas at the beginning of the session. We accidentally stumbled across the idea of creating an application that would work like Tinder but with regards to digital games; matching individuals to a game that would suit them.
While creating a Smartphone app seemed a little difficult, the idea of crafting a project that could pair different individuals with a particular game seemed ingenious. It tackled the notion of making gaming culture more inviting by offering non-gamers the chance to find a game they might enjoy without getting overwhelmed in the excess of digital games that are available.
Angus explained the basis of the idea: “Get Game is just a way of getting people connected with games, where those people aren’t necessarily assumed to be well versed in the gaming language.”
The concept seemed to be workable, and as a non-gamer, I was enthused to follow the progress of Get Game as an objective, third party outsider. To help manifest the idea, Olivia jumped on board. The two then refined their aim: To create a platform that will connect different individuals to a game that suits their personality.
In their Beta presentation, Angus touched on the concept of ‘The Attention Economy’, suggesting that there is no lack of games available, rather there lacks a channel to get these games to the right players. While there is an abundance of niche games, they all seem to struggle to gain traction and coverage and so they don’t reach their intended target audience. Angus and Olivia wanted to use this as a basis for their aims. Angus explained, “If this one project can get a lot of attention, then it can direct the attention towards those smaller, niche games.”
Angus and Olivia decided to use Twine to create Get Game. This seemed justifiable, as it is simple game-development software that requires very little programming experience and offers the ability to create paths of information, with different elements branching off of each other.
Viewing what Twine looked like in action made me reminiscent of the flowchart quizzes that often featured in the lame teen-magazines I used to muse over.
It followed suit with the structuring, as it would have a consistent set of options to begin with, that then led to a number of other options, ultimately leading to one end game. I was a little sceptical as I felt that a large database of games would become very confusing and overwhelming in the form of a story map, but Twine did sound promising.
Initially, Angus and Olivia had committed to only including indie games, however as time progressed they became more lenient with the content, adding in well-known games such as The Total War games. For a team that were so passionate about unveiling unchartered games, it was a little disappointing to see them fall back on the mainstream ones.
1. Develop a rough database of games to include in the system.
Most of the game data was gained through Angus’ previous interaction with digital game culture, including his work on The Tertangala’s gaming section, his press account for an online game store called itch.io, game podcasts he’d listened to, social justice game developers he followed on Twitter, and a website called Offworld, a new game site run solely by women.
2. Develop categories to sort the games into.
Angus and Olivia started sorting the games out based on characters, contextual settings, story, and the broad elements that defined the games. They then honed in on more specific features such as complexity of controls, how much time the game would demand, what other experiences the game fosters, and purchase price.
3. Add games into the Twine.
The pair then began to fill the Twine with content, building individual paths for each new game. At this point, Angus and Olivia were simultaneously developing different pathways in the Twine, while gaining more ideas of games to include. There are currently 57 games in the Twine, which proves a solid amount of effort went into creating content.
4. Add ‘placeholders’ into the Twine.
Angus added empty links into the Twine so that they would be reminded to fill those gaps with corresponding games.
5. Create a blog and host the HTML.
This proved to be a challenge for Angus and Olivia, who claimed to have tried everything to get the HTML package embedded within their website. To temporarily solve this issue, they uploaded the HTML to Dropbox, and linked to the Dropbox file from WordPress.
Constructive Feedback & Suggestions for Improvement
Angus and Olivia had already produced a rough beta version of their project for their seminar in week 8. It appeared to be a good foundation; the Twine infrastructure worked on the front end, and after I personally completed the Twine I was led to a game that I actually wouldn’t mind trying out. Of course, there were some improvements to be made, but for the most part, the Twine was being developed quickly and it was successfully matching games with people.
Unfortunately, there were still a number of empty links too. In some cases, the user was left with only one option for each question, forcing them down a single path with no alternatives.
While I understand that the back end of the Twine is more complex than it appears for the user, it would’ve been great to see each link active, with a game appearing at the end of every prospective path of branches. I know that Angus and Olivia needed to conduct an extensive amount of brainstorming and research to get their idea off the ground, so it’s unfortunate that their hard work is hard to see. However, I think if they used database software, like Microsoft Access but more advanced, there would’ve been less work required when filling the Twine paths. Angus and Olivia had to create a new set of branches for every game that they included, which is highly time consuming. Creating a database, with preset categories, drop down options, and consistent paths would’ve saved a lot of energy, as all of the questions/categories would’ve been pre-emptively sitting there.
For the most part, I felt that there was little progress made between the week 8 seminar and the beta demonstration. Despite this, I was impressed when they presented a WordPress site, which featured a survey that users could fill out to submit a game they’d like to see in the Twine. This was a good idea as it decreased their workload with regards to data collection. The remainder of the website was simple, and featured a brief description of Get Game, Twitter integration, and a link to the Twine’s HTML.
This was the major deal breaker. The Twine’s HTML package was available on Dropbox, and so a link to the Dropbox file was what featured on the webpage. This didn’t seem very intuitive. Not only is the Twine essentially hidden from the public, but it feels as though you have to go through a number of loopholes before actually reaching the Twine. It would’ve been beneficial to host the Twine somewhere else, or attempt to embed it into WordPress rather than offer a separate HTML package. I suggested that Angus and Olivia purchase a domain name and host their site on WordPress.org (not WordPress.com). This way, they can embed the HTML package in their Public HTML file, or can install a custom HTML plug-in that will allow them to embed their HTML in a blog post without WordPress altering its structure.
I loved the Get Game concept, and if the Twine had been closer to completion for the Beta, I would’ve been far more impressed. If Angus and Olivia can make those vital changes before they submit it, Get Game will be one solid final project.