For the end of this semester we are tasked with creating a Game Project Proposal (GPP) which explains the goals, content and methods that will be involved in the development of our game in second semester. The final GPP can be accessed here.
We'd discussed as a team from the conception of Maive making the GPP into a fairytale book. This felt like an appealing way to connect the reader to the world of the game; from opening the first page they would get an idea of the genre and subject matter of the project.
Sid formatted the document, his research and development is recorded on his blog.
We wrote the bulk of the writing in a Google document I had created based on a document Adam had provided us with outlining the sorts of things we might want to include. I reorganised the sub-headings and grouped them into "chapters" based on subject. We divided up the content of the document based on our areas of expertise and interests, colour co-ordinated to each person and also created a key so we could mark whether work had begun on a given sub-heading.
My areas were predominantly narrative based - as a narrative-heavy project it was imperative that we had everything outlined, and I was working on this anyway. Documentation of my progress for narrative, characters and environment can be found in their relative blog posts.
Overview
As the most proficient writer on the team and also Maive's initial creator, I took on the overview to distill the essence of the game as best I could. Writing the abstract helped me concoct a blurb-like paragraph that sold the narrative heart of the game through character-centric writing.
I tried to lean into the emotional aspect of the game - after all, Maive is an introspective narrative that aims to have a personal effect on players. The target audience ended up being deliberately broad based on my research into audiences and gamer demographics.
Narrative, Characters, Environment
This section not only included all of the written content I'd created (i.e. lore, narrative beats, character profiles, environment descriptions) but also all the art I'd created for this too. We included mood boards to give the readers a sense of the mood and visual style of the game - something I'd created prior to capture the essence of the world in a way that the team could refer to for inspiration. Included in these chapters is also the concept art and turnarounds I've created for all of the game's characters.
For the GPP specifically, I created a storyboard outlining the first minute or so of the game. This was to go alongside the narrative arc to help readers visualise the game alongside the text so they had an immediate idea of the game as a complete package.
Research
My contribution to the research section was a boiled down accumulation of the research that I did in phase one and two at the beginning of the semester. I selected the most important aspects from this research that had contributed to our final design for Maive, which I deemed to be the character dynamics and the moral. Both of these informed the way I designed the narrative for the game.
Agile Methodology
I did some research into the type of working methodology we might want to use for our project.
Agile aims to increase team communication and ease workflow by allowing developers to be flexible and adapt to change.
Manifesto/Key focus of Agile:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile has many sub-sections, such as Scrum and Kanban, which take this manifesto and create more specific work-processes to go alongside it. Each have their own pros and cons, however, choosing one was a difficult thing to pin down.
Scrum operates in "sprints" - short bursts of focused work spanning one to two weeks that aims to complete a branch of a project in a short amount of time. This is in order to provide deliverables to clients and keep a transparent, open communication between clients and developer.
Sprints also mean that work is constantly reviewed by someone other than the developer working on it. I really like this aspect of agile, and it's something the team and I are interested in taking forward.
When using Scrum, there is a Scrum master who supervises workflow and helps to deal with issues that might arise during the development process. This keeps inter-team relations running smoothly.
Kanban, another sub-division of Agile that helps developers visualise their work and be more streamlined in their development. It involves using a board (real or digital) to organise work into sections of development that are broken down based on role or subject. This normally means creating at least three columns on a board, labelled something akin to To Do, In Progress and Done. Items, assignments or tasks will begin in the To Do column, move into the In Progress column when development has started on the task, and then moved into the Done column upon completion. This allows the whole team to visualise all the tasks and their relative progress throughout development.
Trello is a good example of a Kanban software, allowing tasks to be assigned to specific developers and given deadlines which developers receive an alert for a day before. Tasked can be moved easily across "lists" and edited throughout. Previously to my research, however, we were using Trello simply as a place to put links, and not a place to schedule or organise workflow. Since researching this, we have organised and started using the Trello board appropriately.
From my research there are elements of the sub-methodologies of Agile that are helpful to us as a development team, but also things that aren't. After consulting my course leader, he advised that our team was too small to really make Kanban or Scrum work properly. Because of this, we are going to be working under the general principles of Agile methodology, without tying ourselves to a specific sub-section.
We also decided to do daily stand-ups, in which the team would discuss the work they undertook the day before and outline their plans for the day to come. This will help in keeping us all up-to-date and in the loop as to what the other team members are doing, and means that issues will be brought up sooner rather than later so we can solve them more effectively.
Book Design
Whilst Sid was responsible for the design of the book, I contributed flourishes to it that were used as borders for every page. These decorations help to frame the text in a classic story-book fashion and adds to the fairytale feel of the whole document. I designed them simplistically and attempted to make them look natural, with tiny leaves embellishing the "vines" that make up the main shape.
Sid and I also made the book itself. After having it professionally printed, we took it to the printing workshop in the university where a lecturer (Andy) helped us go through the steps to turn a collection of papers into an actual book. This involved putting the papers between two pieces of hard board, and then squeezing this together between two pieces of wood. We scored the edge that we wanted to bind with a sharp knife in a cross-hatch patter, and painted over it with PVA glue which sank into the scores we'd made. Next we had to dry it with a hair dryer, and then glue and dry a further 12 times.
Once this long process was finished, we sawed across the spine at top, bottom and middle. We brushed glue into these new scores, and then twisted some thread and placed it in the crevice. We glued over the top and dried it a couple more times, before leaving it to rest for a while.
When 10 or so minutes had passed, we cut the hard board covers off the rest of the paper, and with a little bit of glue, attached folded front covers that would later be used to attach our papers to the front and back cover. Andy trimmed up the pages for us so everything was nice and neat. We stuck the hard boards initially attached to the papers onto a piece of book cloth (which we wrapped carefully around it), and then attached the front covers to those boards, creating a finished little book.
I spelt the game's title in stick-on lettering, however I thought this looked a little bit childish and wanted the book to have a little bit more finesse. I sprayed on a silver lustre spray over the letters with the intent that when I removed them they would create a void of black that would look more impressive than the raised foam lettering. This went dramatically wrong, however, and resulted in me wiping off the spray and the foam lettering, which I had no replacement for. What remained of the lustre spray had created a glittering effect over the whole cover, however I wanted to signify the project with its name on the front.
I searched for an appropriate font, my requirements being that it was a serif font to look appropriate for the storybook format, but that it had a level of interest and wasn't bulky to the extent that it appeared childish or immature. I came across a free font on dafont.com called Organic Elements, which seemed so fitting I think it might work for future branding of the game.
I sampled the title and copied it by hand onto the cover with a silver ink pen. In my opinion, though it was a somewhat disastrous way to get to this point, it really improved the look of the book.
The book isn't perfect, and some of the pages are a little loose, but it was really rewarding not only to see our GPP come to life as a little storybook, but to make that book ourselves from scratch. I feel like our physical GPP really delivers the heart of the game - made with a lot of care.