Softskill Plans and Improvement

As Studio 1 began, I became focused on the work that presented to me. Throughout Project 1 I focused too heavily on creating art assets and throughout Project 2 I prioritised the completion of group work over personal work.

My problem was that I didn’t have any personal management. Whenever I had time free to work on something, I found that I spent a lot of time just figuring out what I needed to work on. I always knew what group work I had to do, thanks to Hack n Plan, but when it came to write Dev Diaries or report my work, I struggled.

To help remedy this, I created a personal Hack n Plan where I listed all of the work that I had left to do. Anything from Dev Diaries to Audio to Scripting were placed in the Hack n Plan. It was a valuable tool for organising my free time and making me far more effective at completing my work.

It allows me to track my remaining work and monitor my week-to-week work ethic. The time spent updating Hack n Plan is more than made up for by the amount of time I save when finding something I want to work on.

I also attempted to use a work calendar, along side Hack n Plan. I found it useful at the start but, once I had memorised the times that I had set aside to work, I found myself not using it very often. I found that I worked better when I kept Hack n Plan opening, using it as a visual reminder of all of the work I had to do.

I plan on using Hack n Plan as often as possible. As it is now, Hack n Plan has been a valuable tool in helping me finish all the work that I needed to do. Additionally, I believe that, once I am more familiar with Hack n Plan, I can gain the benefits of a work calendar from Hack n Plan as well.

Writing A Film Script (Screenplay): What I Learned

For Project 2, each team was required to come up with their own scenario to a board game. This involved: making a unique set of rules that could be attached to a common set of rules that every scenario had, making crises that players had to solve which were specific to the scenario, and making film scripts to deliver to Film students. The Film students would later set up and record a professional actor to perform the scripts. These recordings would accompany the board game, to be played along side the crises.

In order to write a screenplay that would be presentable, I researched how to properly format and write a professional film script.

Screenplays are notorious for being finicky when it comes to their layout. Descriptive text must have a certain indent, while speech text must have an increased indent beyond that. In terms of layout, each page should follow these specifics:

  • Top Margin: 1 Inch
  • Bottom and Right (outside) Margin: 0.75-1.25 Inches
  • Left (inside) Margin: 1.5 Inches
  • Font: 12 point, Courier
  • Dialog Indent: 1.5 Inches, on both sides

Every page should follow these rules and the reason for this is because it will take one minute for each page to play out on-screen. This allows readers of the screenplay to accurately guess how long it would run for.

Beyond that, there are some specific terms, references and capitalisation that must be used in writing. For example, the first line of a screenplay should read ‘FADE IN:’, without the quotation marks, as this signifies that this page is the beginning of the screenplay. From there, scenes are split up by their location.

After ‘FADE IN:’ but before any other text, you must write a one line description of the location that the next scene is going to take place in. It must specify whether there is an INT. (interior) or EXT. (exterior) camera at the start of the description and, at the end of the description, you can whether the scene is shot during the day, the night or at the same time as the last scene if need be. Finally, the entire description must be capitalised.

Whenever a new character is introduced their entire name must be capitalised and must be accompanied by a description of them. From there you can write normally about what characters are doing, until they speak. When a character speaks, their entire name must be capitalised and indented on the left by an additional inch. If dialog runs over the page, then (MORE) must be added to the bottom of the page that the dialog started on. Then on the page that the dialog runs onto, the characters name is placed at the top of the dialog, all capitalised again, but with (CONT’D) placed next to it.

There are also certain terms that must be next to a characters name at the top of their dialog depending on the characters’ location on-screen. If the character has dialog but is not mean’t to be on-screen when saying it, then you must add (OS) next to the characters’ name at the top of dialog. However, if the character is purely voice, e.g. a narrator, you must add (V.O.) next to the characters’ name at the top of dialog.

Lastly, if a specific transition is required between scenes then it should be noted at the end of the scene. To do this, write the transition in capitals with a colon at the end (e.g. DISSOLVE:), and align the text to the right. Note, however, that is should be done for every scene change.

 

It doesn’t contain everything that has been discussed but below is an image of the screenplay that I wrote for the first crisis of my team’s scenario.

FilmScriptSample.png

Future Uses:

This research obviously helps with writing dialog and planning cutscenes in games. Beyond that, I believe that this provides me with a valuable first step into an aspect of game development, even an entire genre of games, that I am yet to explore. It allows me to begin experimenting with narrative-driven games in a form that is easily understood and is still useful later in the development cycle.

This also gives me a medium in which to express ideas and stories not only in a structured manner, but in a professional manner as well. It allows me to write in a format that is common in the industry (in the film industry at least) and can be easily read by veterans and amateurs alike.

Finally, this research is the first step into opening avenues for me in the film industry should I ever wish to transition to another creative industry.

Project 2 – Post-Mortem

For the past few weeks I have been working on a board game with three other people. As of this week, the major portion of this project has been completed. All that is left for my team and I to do is some minor tweaking to gameplay. Other elements, such as card design, token creation, filming crises, etc, will become the responsibility of the Graphic Design Team and the Film Team. There will, of course, be communication between all teams, but it is closely approaching the date where, after which, no more changes can be made because production would have already started or be near completion.

 

What is this project?

This project involved a class of fifteen students who created a board game that would operate as a common base. These fifteen students were then broken up into four teams, with each team required to make a different scenario that would introduce their own additional rules to the base game.

 

What went right:

Communication:

The team used Discord as their main method of communication. During the planning phase of the project, everyone in the team contributed and shared their ideas. Then, throughout the rest of the project, the team was willing and able to cross-check their work with each other.

The team’s success in this area relied on all members being frequently available and open to discussion. There was never a need for emergency contact because team members promptly replied to messages and were always available for online group meetings.

 

Organisation:

Tasks were created and distributed amongst the team members. The team utilised Hack n Plan after every meeting. On Monday and Wednesday, during our in-person meetings, the team created a list of tasks that must be completed before the next meeting. Each task was broken up into smaller, more manageable tasks that could shifted between members of the team if required.

The reason why the team was successful in this aspect is because of competent task breakdown and distribution. Each team member was in charge of a certain aspect of development and would have all tasks that related to that aspect assigned to them. However, the workload of some aspects varied throughout development so, in order to get the most out of every member, people with little to no work to do had tasks from the other aspects of development delegated to them.

 

What went wrong:

Delivery:

The team rarely had all our prototype cards ready for playtesting on-time. While the team had created all the cards, they were not printed. Therefore the team had to spend time printing and cutting all of the cards before they were capable of playtesting. This means that, instead of being able to run two playtesting sessions, there was only time to run one.

What caused this was the date that the tasks were completed. While the team did well in allocating tasks amongst team members, most tasks were worked on and completed over the weekend. This mean’t that the cards and other items that the team had created were typically printed out the next day. Unfortunately, more often than not, this mean’t that the team’s intention was to print the cards before the meeting and arrive to the meeting with all the prerequisites ready. However, there was always a problem and everyone would arrive with none, or very few, of the prerequisites required for the game.

Setting deadlines for each task and/or having ‘Printing’ as a task, in the Hack n Plan, would of helped to mitigate the problem and would have allowed for a smooth transition between group meeting and playtesting.

Rulebook Layouts: What I Learned and How I Applied It

I was recently tasked with creating a Rulebook for the board game being created for Project 2 of Studio 1. The class was split into four groups and were each tasked with creating a different scenario for the same board game. The Rulebook initially consisted of a base Rulebook that would explain the rules that are common amongst all the scenarios, then an additional 4 Rulebooks that would explain the rules that are specific for each scenario.

I started my research into Rulebook layouts by analysing the Battlestar Galactica: The Board Game Rulebook. I decided to start with this Rulebook because it is a game that I have played and am familiar with, plus the theme of the game is somewhat similar with the theme of the project.

This first thing that I noticed about the Battlestar Rulebook was the Component List and Breakdown. I decided to include those same sections in the Rulebook I was making because I find it to be an excellent way for end users to ensure that they have everything that they need to play the game, as well as a convenient way for me to explain some surface elements of the game.

At this point, the Rulebook was filled with descriptions and explanations, but nothing that actually defines gameplay. After a few playtests, it was apparent that a game manager was needed in order to run the game properly. To help remedy this, the ‘Game Setup’ and ‘Gameplay’ sections were given step-by-step instructions that end users could follow.

However, this wasn’t too helpful because of another problem. That problem was delivery. More often than not, whenever a playtest was coming around, the Rulebook wasn’t very accessible and the explanation of rules was delegated to one of the team members that was operating the playtest.

Another issue that occurred was the re-designing of certain gameplay elements, namely the Hazard Cards. The layout of a Hazard Card changed four times and the gameplay of a Hazard Card changed three times. Keeping up with constant rule changes in order to maintain the validity of the Rulebook was vital. To do this, I attended all playtests and created playtest reports with reminders to adjust the Rulebook.

Perhaps the most complicated part of this process is collaboration. I was working with another student on the Rulebook. This means that a document had to be made that outlined what wording and layout was going to be used. The purpose of said document is to make the process of combining my work with the other students’ work smoother.

 

What I Would Do Next Time

If I were to write another Rulebook, I would follow a more methodic process. There were small things that were overlooked, such as the Spacewalk, that could be implemented much smoother if they were found earlier.

During playtests, I would take notes on how rules were explained as well as where gaps are in the Rulebook. Since there were approximately 5 playtests, that means that there were 5 opportunities to present, and receive feedback for, the Rulebook. When considering how helpful the last playtest was (the only playtest where the Rulebook was used), it would be a great boost in the quality of the Rulebook.

In order to make that happen, I would need to make sure that certain sections are done by certain times. For example, if the ‘Game Setup’ section is completed by the first playtest then I can receive feedback straight away. This allows me to present the Rulebook more often because the Rulebook I just helped make was built by working on every section a bit at a time. This meant that the Rulebook constantly had unfinished sections so I couldn’t show it to anyone, or at least I didn’t want to.

By the making the Rulebook one section at a time, I can show each section to the team as it is finished and receive feedback and implement feedback faster than before.

Collaborators

Graphic Design:

Brady and I met with Morgan, a Graphic Design student, during class on Monday to discuss an estimated delivery date of the Rulebook as well as what I could do to make the Rulebook transition from Development to Design easier.

She told me that if I include sample images, along with the text that is already there, it would be easier for her. My intention was to include images in as many places as possible, along with text to explain exactly what I wanted the image to look like. However, due to time constraints, I wasn’t able to provide everything that I intended to.

We agreed that Brady and I would deliver a draft of the Rulebook for Morgan to look over and the it should be deliver a week and a half from the time of the meeting. This goal wasn’t achieved either. Even though Morgan was given access to the Rulebook on Google Drive, the Rulebook was not in a state sufficient enough for submission. This happened because I underestimated the amount of work that was remaining on the Rulebook, as well as overestimating the amount of time that Brady and I were able to commit to the Rulebook.

 

Audio:

Ben, Ruby and I met with Bronte, an Audio student, during class on Wednesday of Week 9. We showed her our pitch, as well as the Sound Bible we had made, and discussed what kind of audio assets we would need. She asked us what kind of style we were after and how many tracks we would need, then we asked her about delivery and communication. We decided to use our SAE emails to communicate with one another.

Only using emails didn’t hinder us and I believe that is because we were only after specific audio assets which weren’t likely to change. The first samples that Bronte provided us were great and left us feeling that she understood the theme that we were trying to go for.

Below is a recent string of emails between Bronte and I.

pasted image 0.png

Bronte placed all the audio assets that she made in a folder in Google Drive, below is a image of that folder.

pasted image 0 (1).png

Animation:

Ben, Ruby and I met with Hayden, an Animation student, during class on Wednesday of Week 9. We showed him our Art Bible and discussed what kind of art assets and how many art assets we were thinking of. He asked us questions about art style and deadlines, then we asked him questions about workload and communication. We decided on communicating through our SAE emails, as can be seen below.

pasted image 0 (2).png

After the meeting, our first few emails were all about clearing up some details that were overlooked such as file formats and sizes. From there on, I had conversations with Hayden via emails every few days. This approach brought complications however. Deadlines were often made impromptu and complications that arose could only be addressed every few days. Instead of using email, I should have included Hayden in the Discord server that the team was using, especially since the art assets that we required were likely to changed depending on how we change the design.

Below is a an image of a Google Drive folder in which Hayden has placed all the art assets that he has made.  

pasted image 0 (3).png

Creating Item Cards

I have created a template card with the board game being made for Project 2. My intention when making this template was to make sure that all the information that was required to be on the card was clear and easily understood. I created this template using GIMP.

Card.png

When I created a new file, I set the image size to 14cm x 20cm. Then I created the black outline of the card, as well as the card layout, with the Pencil Tool with size at 10px. I separated the card into 5 different sections: the Title, Deck, Resources, Artwork and Abilities.

The Title is the section at the top of the card and has the largest sized text on the card.

CardTitle.png

To do this, I used the Text Tool and made a small text box. I then typed the name of the card, in this case ‘Kinda Gross Towel’, and expanded the limits of the text box to match the section. I then highlighted the text and increased the font size until I felt that it fit nicely within the limits of the section.

I made it like this so that, when a player receives the card, it is very obvious. Also, as players become more familiar with the game, they may come to associate the name of the card with its abilities so having the title be large is important.

 

The Deck section is at the top-right of the card, defined by a distinct circle.

CardDeck.png

I followed the same method that I used for the Title for the Deck section as well. I created a text box, placed the corresponding letter, expanded the limits of the text box to match the section and then increased the font until I felt it looked good.

This section tells players what Deck this card belongs to. It is used during the setup of the game, as well as when a player discards a card. I gave it a unique area because of how vital it is during the setup of a game. The letter in the circle is in bold and represents the first letter of the deck that is belongs to: M (Medical Bay), K (Kitchen) and CB (Cargo Bay).

 

The Resources section is on the right-hand side of the card and tells the player how much of each resource the card is worth.

CardResources.png

To create the coloured squares I used both the Rectangle Select Tool and the Bucket Fill Tool. I used the Rectangle Select Tool to to create an appropriately sized square. The square is small enough to allow for three squares of the same size to fit within the section, but also large enough to fit a decently sized number inside of it. I then used the Bucket Fill Tool to fill each square with the colour used to represent one of the resources. After that, I used the Text Tool to label each square with the amount of resources that the card provides for each resource type. I followed the same text method for the numbers as I did for the Deck.

This section has 3 numbers, each one inside a differently coloured square. Each square represents a different resource: Blue = Tech, Green = Bio and Yellow = Energy. I decided to give this section colour so that it stands out from the rest of the card and allows for players to distinguish between resources without the need for text. However, having colour be the defining factor means that it may be impossible for a colour-blind person to read it.

 

The Artwork section is in the middle of the card and is a visual representation of the Item Card

CardArt.png

This section is fairly large on the card and is intended to provide a visual connection from the card to the game board. However, due to the constraints of the project, this section may be cut. Another reason this section maybe removed is to make more room for the Abilities section.

 

The Abilities section is at the bottom of the card and is the largest section on the card. It describes the abilities that the player gets when they receive the card.

CardAbilities.png

Since some cards have both a Passive and an Active ability, I started by using the Pencil Tool, again at 10px, to draw a line to split the section into two. I then created a text box, using the Text Tool, on either side.

This section is broken into a Passive and Active area. The details of the abilities are listed in their respective area. In order to fit the wording of the abilities on the card, I had to re-word some of them. Even still, some of the ability descriptions of some cards don’t fit properly.