Week Four
Thursday 4th March
Team Meeting
Team meeting – discussing progress up to now and assigning the next tasks. Together we discussed the first set of tasks that I set and went through work that people had already completed. We gave each other feedback and talked about what still need to be worked on. At this point we had a finished design for the Shaman and some concepts for the air region as well as a finished idea for the gameplay and structure of the level including the puzzle. Furthermore, we have designs for how the ability animations will look. Charisma has begun working on assets such as lighting and trees and her and Emilia will keep each other updated on asset creation to maintain the intended art style, which was also further discusses in this meeting.
Art style 1
Art style 2
Art Style 3
Moodboards provided by Emilia
We analysed these three art styles shown above during the call, taking into account the tone of the game, our individual artistic ability and our target audience (link to target audience and persona: ). Firstly, the tone of our game is calming, aiming to provide the player with feelings of inner-peace and relaxation as well as engaging them with an immersive experience that can act as a distraction and ease from the stress of the day. The purpose of the game is a method to unwind at the end of the day. Therefore, the art style of the game should be soft, not too vibrant or overly complex, but also still colourful. I think art style one is too dark and conveys more feelings of mystery, nostalgia but also something quite ominous. It sets a darker tone for me and isn't playful enough for the narrative of our game. Art style too is quite overwhelming in colour, I would say. It's a wake up rather than something that could put you at-ease. Art style three quirky, the colours are fun and set a more postive tone but the detail should definitely be toned down if we are to use it. After some discussion we did, as a group, decide on using the the Okami inspired art style (number 3) as inspiration for own creations.
​
At this point tin the project we have clarity for how we want the game to look and feel and know what we need to do to accomplish a successful vertical slice. I am confident that we know what we are doing and am excited.
For the next set of tasks, I wanted to encourage more communication and collaboration between members of the group because so far this is definitely a weak point within our team. I have encouraged people to share and talk about the work throughout the process, whether it be through slack or within one our team meeting’s, but I think that people in the team struggle to speak up sometimes. To combat this, I will try to keep up with individual team members to make sure they feel encouraged and valued and then hopefully they will feel more confident to speak up and share their ideas.
​
The next tasks are as follows; I have got Daniella to hand over her character design to Molly so she can apply it to the Shamans movement and ability animations. Daniella will now begin to work on controller mapping and especially how the player will use a touchscreen to move the player and use abilities. For this, she will need to collaborate with molly and share ideas, making sure that the design is consistent between their individual assets. Charisma has been given time to finish off her environment concepts for the air region and then discuss with Emilia, the planning and production of the visual 2D assets that are going to need to be produced. Together they will come up with an initial design iterations. I have given myself the task of designing the player interactions with the environment and puzzles. I will need to share these designs with Daniella for her controller mapping and Molly for her animation work.
​
So, to summarise here are the next tasks to complete:
Daniella – Controller mapping. Discuss this with Molly to relate this to the ability animations. How will the player make use of the touch screen?
Molly – Take the character designs from Daniella and apply to animation process.
Charisma –Further environment and asset creation. Discuss with Emilia to organise which parts you will do between you. Refer to asset lists.
Emilia – Planning and construction of in-game art assets.
Kiera - Interaction design, how will the player interact with puzzles and parts of the game at every stage?
​
Development Meeting with James
In this meeting, we discussed all of the progress we have made so far as a group and plans for the rest of the project including setting key milestones. James was happy with our progress so far and helped us brainstorm some insights into some of our design decisions such as the inclusion of parallax view and how we could incorporate that, as well as lighting in our design. After this meeting, Molly volunteered to research how we could combat implementing lighting using VFX or post-processing. It is important that all the assets are created with lighting in mind so when it is finally implemented in unity, shadows and highlights are in the right place and details as simple as the direction of light for each asset has been considered.
​
I really like the idea of using parallax view in our vertical slice. As we made the design decision to switch from 3D to 2D, despite what was proposed in the GDD, I think incorporating parallax view will make up for that in a way. It will still give that idea of a 3 dimensional world, catalysing the objective of creating an immersive experience with a suggestion of a greater, extraordinary world to be discovered.
​
During this meeting we also talked about the importance of maintaining consistency while we have multiple artists creating different assets for the vertical slice. This bought up the question of how are we going to monitor this. I have already thought about the process of checking assets as they are produced and creating a method of guidance and correction for the creation of each asset but it was suggested by James that I appoint a lead artist who would develop a this method. Emilia was interested in taking up this role and I agreed that she would be most appropriate for the task given her ability and experience. So she has been appointed lead artist and will be developing an art style guide as well as some tutorial work for how to re-create our intended style.
​
Lecture 1pm
Evidencing work and looking at the module profile. Below I have summarised how each category in the module profile will be marked and listed what evidence would be most helpful to show in my digital portfolio (this weekly diary and blog posts).
​
A - Knowledge and understanding
​
Evidence of professional industry practice
Collaborative practice and critical reflection
Evidence of pipelines and processes
Testing to show evidence of experimental methods
Iteration
​
B - Subject specific intellectual and research skills
​
Utilise design thinking skills in development, why is this fun? Why is this good?
Practice and training to support development
Evaluate yourself, what did I do well and what could I do better or with more time?
​
C - Transferable and generic skills
​
Summarise critical reflection
Are you showing up and collaborating with your team enough? Evidence! What have i contributed? Do I provide good support and add value?
​
D - Subject specific practical skills
​
Have I used technical skills to make this stuff and was it worth it?
Test ideas, QA testing, Feedback, asset testing, player feedback.
Friday 5th March
Lecture - Testing and manual version controls
Version controlling is a mechanism that keeps track of changes between different versions of a game element such as assets, scripts and builds. Controlling those changes means making sure that everybody works continuously form the same version.
Above is a table to show how to keep track of version control. Keep documentation of when the changes were made, notes of the changes, whether something was added or removed and note down the author of those changes.
Also make sure to keep saves of each game version.
​
Testing our assets, prototypes, and builds is essential. As each iteration is made, they should be thoroughly tested, and this should take place during development. We can document this through a shared table on a oneDrive or Google Docs document.
​
During this lecture we went over how to test games and the importance of testing regularly and hiring a rnage of individuals to do so. We also looked at some advice about testing, given by the experts, shown below.
​
Steve McConnell: Testings goal runs counter to the goals of other development activities. The goal is to find errors. A successful test is one that breaks the software. The goal of every other development activity is to prevent errors and keep the software from breaking. Furthermore, the test results are an indicator of quality, not a method to improve software quality. If you want to improve your software, don't just test more, develop better.
​
Scott Rogers: Testing is a great gateway job position for newcomers to the game industry. I have seen testers go on to become designers, artists, producers, and even heads of studios. You can find out a lot about games in a short time by working as a tester.
​
When testing our own game, we need to try to break them. We should ave someone play it who did not work on the development of the game as it's easy forget or miss that player other players might play the game differently to others.
​
As a team, we are interested in engaging especially with other young women and encouraging them to take a more confident step into the world of games and possibly games design. I personally don't have many female friends who are actually interested in many games at all and that's likely because they haven't had much of an opportunity to experience enough of what games really have to offer. I think it would be really interesting to explore how women and men play games differently, if there is a great different in what they look to take from a game, and especially how women who are new to gaming attempt to navigate a game.
​
There are 3 types of testers:
​
-
Those associated with the project.
-
Friends and people friendly to the project
-
People who have nothing to do with the project
The last one is especially important because they are most likely to give the most honest feedback.
​
Everything must be tested, not just the code.
Testing must be documented in full. The test page is usually formatted as a checklist that includes a list of all the asset which are checked if in pass/fail format, so basically whether it functions as expected or whether it does not function as expected or does not work at all.
​
Here is an example:
The documentation should include the version of the game, the expectations of how the game/assets should function, whether it passes or fails, why it passed/failed and how critical the bug is. CNT stands for Cannot Test. The notes should include any information that you think could be helpful to the development team.
​
As the lead for in building our game into unity, I will make sure to get our own documentation up and organised as soon as possible to keep track of the building and testing of our game.
Group Task
As a team, we came up with a draft table of documentation for this testing process. It was a short task so at the moment it is simplified. When it comes to building testing our game, we will have a new fully developed table to keep track. Here is the table from the task, below. This table also acts as an asset list/list of things to complete for the vertical slice. Emilia wrote up this table while as a team we discussed what needed to be included and what our expectations of each asset are.
We will create a more refined testing document for our development, but this was a good start. Each asset that we create will go through a system of it first being shared with the group for feedback and then if changes are required, they can be made then. Next they will need to be compared to the other assets that are being created so there is always a level of consistency between the art style and the quality of everything that we make. We will also make scene mock-ups of for each puzzle interaction of the game (stages) for another level of comparison and reflection. This will always be shared with the team on slack so we can all have a say and make suggestions for improvement, as well as give each other praise.
​
This whole process will take place before the assets are moved into the unity build. In unity they of course, will have a test for functionality, whether the quality is up to standard, the resolution is correct and its relationship with other assets in the scene is still good enough. Each of these questions will be answered and documented. throughout the process.
Week Four Reflection
As a team this week we have made strides in our design so that we are now ready to push forward hard on the creation of assets and start putting them into unity as we go. As asset creation is well under way, Emilia is producing a detailed art bible, as lead artist, in order to guide the team in keeping their work consistent in style. I wanted to begin building the game in unity and getting the basic programming done as soon as possible so I'm really happy we are ready on time. The lecture this week, on manual version control and testing was incredibly useful and we are preparing our documentation so when I begin unity development next week, I'll be able to keep track of the progress and changes on the get-go.
​
The tasks set this week aimed to improve communication between the team, and I have already heard that Molly and Daniella have been in discussion to inform each others work . And Emilia and Charisma have had calls over slack to discuss the process for asset creation. I think that encouraging small discussions will be encouraging and help people to feel more comfortable about speaking up and sharing their ideas when it comes to discussions as a whole team.
​
My work this week consisted of working on the interaction design and player experience, as well as some bits and pieces to assist the team development. I have made further changes to the project scope and added some detail to my game structure work from the week before, adapting it to the newer project scope. I also did some further research into the Anima Mundi GDD and reflected back on it to inform the gameplay design. The blog post for this work can be found here: https://kw4u19.wixsite.com/gamedevelopment/post/design-realisiations
​
My work on interaction design includes detail and analysis for the full journey of the player from the beginning tot he end of the game, the reasons behind the design decisions in each part and the players emotional experience from each interaction. The blog post for this work can be found here: https://kw4u19.wixsite.com/gamedevelopment/post/gameplay-design-gameplay-experience
​
Progress review:
​
We have another week of designing and planning before we jump into 4 week of development. I am pleased that we are on track and I will be beginning the unity build a little early, next week. The steps for next week include, making sure the art bible is complete and up to date, we have a full finished list of all game assets and how they are expected to look, and we have a complete storyboard for the game, from start to finish so we have a visual reference for organising the assets. Emilia and I are building the storyboard this weekend so that will be documented on next weeks page. The art bible will be finished by Emilia and this will have a guide for every asset design.
​
The project scope has been refined once again and has been documented in full under the project scope tab at the top of the page. Here, there is a brief proposal for what I want this vertical slice for Anima Mundi to accomplish, a full feature list and how those features will be presented, an asset list that is still subject to change as well as the pipeline analysis, key milestones and an overview of the expected budget for this project.