Full Beta Game Play through with Picture in Picture
This playthrough shows the exergaming game, “The Adventures Of Pirate Cove” being played by both myself and my brother to validate that it works when running on Kinect.
Gameplay Video:
trying on a metaphor
Sade Olutola
AnasAbdin

Discoholic 🪩
occasionally subtle

@theartofmadeline
Misplaced Lens Cap

oozey mess

if i look back, i am lost
Lint Roller? I Barely Know Her
KIROKAZE
No title available
ojovivo
Monterey Bay Aquarium

Janaina Medeiros

Love Begins
let's talk about Bridgerton tea, my ask is open

izzy's playlists!

JBB: An Artblog!

Kaledo Art
seen from United Kingdom
seen from Singapore
seen from United Kingdom
seen from United States
seen from China

seen from Malaysia

seen from Ukraine
seen from France
seen from United Kingdom

seen from United States
seen from United States
seen from United States
seen from Spain

seen from United States

seen from United States
seen from United States
seen from Norway
seen from Brazil
seen from United Kingdom
seen from United States
@exergamingforstudents
Full Beta Game Play through with Picture in Picture
This playthrough shows the exergaming game, “The Adventures Of Pirate Cove” being played by both myself and my brother to validate that it works when running on Kinect.
Gameplay Video:
Finalising Documentation
This is the final documentation that will be written for this project. It covers all aspects and has been stylised in a way that it is at least somewhat more unique than an average documentation.
The version 1.0 of the documentation can be found here.
Working Off Developer Feedback And Making General Document Amendments
I submitted my design document over 6 weeks ago for approval and am yet to receive any feedback on it. With the deadline looming overhead it was decided that the best course of action would be to make my own changes and hope for the best. With this in mind, this version of the Game Design Documentation focusses around changing the core goal of the game from “Winning The Captains Favour” to “Earning 3 Pirate Keys” to open buried treasure. It also has a few grammatical and spelling errors fixed.
The version 0.75 of the documentation can be found here.Â
The absolute final version will simply have some style changes to the document to make it look unique.
The Adventures Of Pirate Cove Innovation Presentation
Every good product has a good marketing video behind it. As part of this project, I had to form a video that in 90 seconds addressed an issue and explained how my game innovates on ways to solve said issue.Â
Innovation Video:
The large bearded man at the start of the video is meant to represent a young child. Stupid I know but I don’t have access to children of the recommended target audience so an extension of the imagination is required.
Completed Game Build To Beta Stage
Over the past few weeks, my game has made leaps and bounds in its development. In the last build, there were hosts of errors that I didn’t believe I could fix. However, since then all of the bugs and errors have been fixed. The game no longer crashes if a player leaves the game area with a ball attached to their hand in the Number Wharf Level and objects don’t randomly get stuck in mid-air during play.
Furthermore, the game now has sound. Almost every action the player can make is accompanied by an appropriate sound and every playable level has a background track.
Finally, the game has a fully animated start menu and has a loading screen incorporated so that there aren’t any weird loading pauses during gameplay.
Full Playthrough:
There are still some issues present in the game that are purely Kinect based. These revolve around the Kinect registering hands and their correct places in the game world. This can best be seen in the Number Wharf playthrough where the player on the left of the screen spends most of their time attempting to answer one question, which they can’t because the Kinect refuses to register their hand in that position. Currently, this bug is very much hit or miss, in that sometimes it happens and sometimes it doesn’t.
Moving Forward:
At this point, given the closeness of the submission date, the game will not get any more major updates. It will simply get bug fixes if necessary.
Completed Conceptual Build For Tug Of War Game
I have been able to complete the conceptual build of my tug-of-war game, this means that I am now able to move around as much as possible and measure the total movement then relate it back to a strength variable. Comparing strength variables I am able to move an onscreen rope and declare a winner at the end of runtime regarding which teams flag is furthest away from it’s starting position.
Full Playthrough of the Tug-Of-War Game:
There are some changes that need to be made so that the game is more enjoyable, however, because this is a working conceptual build of the game making these changes this late in development is not required and may not happen.
Moving Forward:
Now that I have the two games complete I can work on the game menus. They should be very simple, the difficulty will be interacting with buttons using Kinect. After this, I will make some stylistic changes to my game and export a final build for assessment.
Completed Conceptual Build For Mathematics Game
I have been able to complete the conceptual build of my mathematics game, which means, I am now able to pick up objects and place them back down, I am able to generate random, basic mathematical questions and answer them for points and I am able to declare a winner at the end of runtime.
Full Playthrough of the Mathematics Game:
There is one small issue that is currently being diagnosed. That being that when the player leaves the screen and has a ball connect to their hand the ball is deleted from the game. I simply need to check for when an object is deleted and add it back to a list variable so that it can be spawned back into the appropriate position.
Moving Forward:
With this build complete I will now move onto the Tug-of-war pass game. This should be considerably easier as all my game will have to do is measure the speed of Rigidbodies linked to limbs and add those values to a score that is represented by a progress bar. After this, I will be moving onto creating an interactive hub world so that games can actually be selected. At which point, my conceptual game build will be complete and ready for submission.
Incorporating More Game Incentive and Modifying Locations
Over the last couple of weeks, I have been developing new and better ways to increase the enjoyment factor of my game. One of the major ways I have been developing is in-game incentive. Currently, my game works by giving the players points and affirmative text for positive actions. This form of feedback may be sufficient for older audiences but is not useful for young children who don’t have the full concept of numerical values representing better or worse performance. Furthermore, I have been advised to change one of my major locations due to its inappropriate subject matter.
Chest and Keys and Incentive:
One thing that I have discovered in my research and from consultation with teachers that have students in the desired demographic is that students react more positively to working towards an actual goal instead of receiving numbers that represent a value. What is meant by that is that students will react more positively to a physical object than to receive 100 points for winning a game.
With this in mind, I have decided to implement a new island into my game. On this island, there will be a chest with Three keyholes. The new idea being that when students beat a challenge they receive a key instead of points. The first team to get three keys will be able to open the chest and receive a large amount of gold and pirate treasure. Along with being crowned the class champions for the day.
The hope with this inclusion is that players will be able to engage more with the game and because of their age would find it more interesting over multiple playthroughs.
Replacing Inappropriate Objects:
When presenting my game to teachers the most pertinent piece of feedback I received was that the Number Tavern was considered very inappropriate for the core demographic. This was said even though there is no reference to alcohol or alcohol references present in the game. Nevertheless, with this in mind, the Number Tavern will be completely remodeled and changed into the inside of the pirates’ ship. This was chosen as it most closely resembles the already generate map.
Final Build Updates:
With the deadline fast approaching there is a lot of work that will be cut from the final game presented. The main item to get the axe is the Wordy Shore game. Given the amount of time left and the logic required, I won’t be able to implement it in any form for the final game.  This being said the game will still be present in the definitive version of the GDD. Furthermore, the ideas mapped above will most likely not be present in the final build of the game either but will similarly be present in the final GDD as an important game mechanic.
Incorporating The Early Years Framework
The Early Years Learning Framework is used to describe the main principles, practices, and learning outcomes that are integral to the support and improvement of a child’s learning up to the age of five. The Early Years Learning Framework strongly emphasises play-based learning and the importance of language, and social and emotional development of young children. The three key elements of this framework are principles, practices and learning outcomes.
Principles:
Secure, respectful and reciprocal relationships
Partnerships
High expectations and equity
Respect for diversity
Ongoing learning and reflective practice
Practice:
Holistic approaches
Responsiveness to children
Learning through play
Intentional teaching
Learning Environments
Cultural competence
Continuity of learning and transitions
Assessment for learning
Learning Outcomes:
Children have a strong sense of identity
Children are connected with and contribute to their world
Children have a strong sense of wellbeing
Children are confident and involved learners
Children are effective communicators
Sources:
Australian Government Department of Education and Training. (2017). Early Years Learning Framework. Retrieved from https://www.education.gov.au/early-years-learning-framework-0
ECRH. (2018). Belonging, Being and Becoming: The Early Years Learning Framework. Retrieved from https://www.ecrh.edu.au/approved-learning-frameworks/early-years-learning-framework
What it Means to my Game:
Personal Breakdown:
Each individual section has its benefits and uses in my game or can be used to justify parts of my game and explain how they are incorporated. This section is a personal breakdown of my game given the framework
Principles: (Top Third)
The usefulness of my game can be justified from the Principles section of the diagram. Children, like all of us, learn from repetitive and reflective practice. Meaning that they respond well when they are given positive reflection for their actions. i.e. The game gives them a reward or encouragement for a correct or valid action. This can be furthered in my game with how all actions never have a negative reaction but a positive reaction. If a student gets an answer wrong, they are asked to try again and if they get it right they get a congratulatory message. Ultimately, it can be seen that for children, all the trivial things make a significant difference.
Practice: (Right Third)
The most obvious section of the diagram to discuss is the practice section. As is already well-established children of the chosen demographic greatly benefit from learning when they are playing and interacting with games. With this in mind, this is a further section that I can use to explain and justify the implementation of my game within the classroom. It also further explains the implementation of basic learning into my game. When I started developing my game it was purely made to drain energy from children before they entered the classroom. However, with a new understanding of this learning practice, it was decided that teaching basic maths and grammar would be more beneficial to both the development of the children and the teaching team that may decide to implement this game.
Learning Outcomes: (Left Third)
My game has the most to learn from the left third of the diagram. As can be seen, children engage well when they are immersed in an enjoyable setting. i.e. The more fun they have within a virtual world the more they will learn. This can be used to back up my use of a pirate world as the games main setting. If I was to simply have minigames that happened within the normal world there is a chance that the children playing the games would not learn from the experience because they themselves would not become immersed with it. It would be similar to playing a fantasy game such as Skyrim but one of the main objectives of the game is to have a 9-5 job and no powers. It isn’t enjoyable and you as the player would disassociate from the experience very quickly, the same ideals can be related to young child learning. With this sentiment in mind, the importance of having an immersive experience is more solidly confirmed and proven to be a useful induction into my game.
All research Congregated from research conducted by Thomas Priest and Riley Webb.
Teachers Breakdown:
Although it is important for me to assess my own work using the Early Years FrameWork it is much more important for a teacher who would actually use the game with children to give their honest assessment on it and to get useful feedback given their examination of the game.
*Feedback from the teaching team of Russel Island*
Practice: (Right Third)
Holistic Approaches:
My game works well in showing learning in a very different way. Instead of sitting in a classroom, students can pretend they are in a different world and still continue to learn.
Responsiveness to Children:
My game has appropriate subject matter for children of the demographic age. This means that my game can be used by the teaching team within a school setting and that the children will interact positively with the generated theme.
Intentional Teaching:
My game works well with a teaching approach known as Narrow Pointy teaching. This is because the questions asked are simple and all within a simple work set. As an example, in the numbers game, the numbers only go from 1 -10 instead of implementing negative numbers or larger numbers.
Assessment of Learning:
My game is also useful for teachers as an assessment device. By monitoring the game and the students playing it they can make conclusions based on student actions.
What’s missing? Continuity of Learning:
The one thing that my game is lacking is the continuation of learning. Meaning, that although my game works well it doesn’t push the users any further than the base game. With this in mind, algorithms can be put in place to see what students are doing well and pushing their skills to further their learning.
Learning Outcomes: (Left Third)
Encourage Strong use of Wellbeing:
Something that was commented on was that the game was very useful in allowing students to express their learning in a new and fun environment. This meaning that teachers can get a better gauge on what they know, better than if they sat them down for a test or asked them a straight question.
Controlling Multiple Interactions, Adding User Interface and Playable Character
Now that I was able to pick up and move objects freely in my game world I need to add a way that the character could interact with multiple objects appropriately. However, to interact with multiple objects I needed to have them spawn in.
Spawning Multiple Objects:
The code used to achieve this is the exact same as seen in my previous videos. All it does is select a random spawn location and a random object to spawn.
Interacting With Those Objects:
A huge and somewhat silly issue that I had with interacting with these objects was that I was attempting to handle all collisions on a single script. Therefore, every time an object was interacted with all objects of the same type would be interacted with in a similar manner. I was able to remedy this issue by having every object have its own script and allowing that script to register interaction.
Creating a User Interface:
Now that I could work with all of my objects and not have any issues I needed to generate a user interface that relayed the appropriate information to the player. This information being time remaining, score and their team. The interface created is based on the proposal available here. An issue I can see in the future is that Unity’s scaling system will cause headaches for multiple resolutions. A bridge I will have to cross when I get to it.
Implementing a Playable Character:
To better engage with games it has been noted that children enjoy characters instead of floating joints on a screen. With this in mind, I implemented a playable character. This was accomplished by taking a 3D model and taking off the head and both hands then placing them in where the joints usually go. However, the joints are still present, as they handle the collision with objects, their mesh renders have just been turned off. The character, at this stage, looks pretty bad, this is because of the lighting in the level. This will have to be manipulated in the future as to not give the children playing nightmares.
This character modeling would not have been possible without the help of a modeler name Bryce Rochecouste who pulled the original character model apart and textured it for me. His blog is available here.
Going Forward:
It is imperative that I now focus on the game logic required to make this an actual game. That means generating randomized questions that are within the scope of the core demographics learning capacity and allowing them to answer said questions and receive points. Once this is completed I will be moving onto work in the Tug-of-War Pass location.
Breaking Down Development Classes and Generating a Final Appendix
In the final part of my main draft Game Desing Documentation, I run down the abstract development classes in my game and reference the assets I have utilized in the appendix. Furthermore, the appendix houses documentation pertaining to a project timeline for the piece that I am following to the best of my abilities.
The version 0.5 of the documentation can be found here.
The following versions posted will be improvements on the 0.5 documentation from feedback given to me by my mentors and peers. Further adjustments may also be made during playtesting, however, this is unlikely.
Designing Game Graphics and Discussing Sound Implementation
To further my work on the Game Design Document I have generated simple low fidelity and high fidelity mock-ups of how I envision the game world I am creating will look. I have also explained, with visuals the design and look of all three areas my game is focussed around. Thos being, Number Tavern, Wordy Shore, and Tug-of-War Pass. With a breakdown of the visuals, I was then able to systematically explain how I believe sound would best be implemented within the game and which sounds I believed would best fit the game world.
The version 0.4 of the documentation can be found here.
Generating Formal Elements and Discussing Technical and Design Aspects
As part of my further continuation of the Game Design Document, I have generated lists of Formal Elements that include items like player interaction patterns and game rules whilst also implementing my ideas on the technical and design aspects of the game. These being introductions to individual screens seen by the player and their interactions with said screens as well as game mechanics and level design.
The Version 0.3 of the documentation can be found here.
Forming a Story and Game Play Explanations
As a continuation of my previous work on the Game Design Document I have specified the gameplay aims of my desired game and designed a simple story to accompany the players as they interact with the media.
The Version 0.2 of the documentation can be found here.
Adding Resources and Controlling Interaction
With my motion controls working perfectly I needed to now focus on creating a game world for my players to play inside of and creating interesting and useful interaction with objects so that my game can actually be played.Â
Picking Up Objects (Child-object on collision):
The Kinect SDK comes built in with gesture recognition, “supposedly”, which allow me to make a clenched fist to pick up objects. However, I found it easier to use a basic collision detection system between the objects on the screen. This collision detection allows me to simulate picking up objects in the game world and moving them around.
Also, without really planning it I somehow managed to make it so that I could transfer the object between hands.
Dropping Objects (Child-object(null) on exit):
Once I had made it so my players could pick up objects I had to form a system that would allow them to drop the objects as well. This ended up being a solution that went through multiple stages. I originally want the object to be dropped when the player lifted their hands up. But this was difficult because if more than two people were playing the other players could just lift their hands up and this would drop the object. What I ended up with was a system that improves hand-eye coordination. The player must now lift their hand to their nose in order to drop the object. This hopefully will allow for another possible teaching angle on the game.
The model works well granted the children playing the game are responsible and don’t use it as an excuse to hit themselves in the face.
Adding in Appropriate Scenery:
This is a pirate game after all and what Pirate game would be complete without a hearty tavern? (All alcoholic references removed of course) This is just simply a representation of one of the background settings the players can use throughout the game.
The scene may need a little more work. Maybe some background characters but for now it works well as a backdrop.
Adding Highlights to Objects:
When the player is frantically trying to answer questions it is imperative they know which objects they are selecting. With this addition, the object will change to a highlighted yellow color and once the object is selected it goes back to its original color. The time set for selecting items is 0.75 seconds as this best allows for players to have to be sure they are selecting the right object whilst also not being too long and annoying or unfair.
The highlight is very simple at this stage but most likely will not be changed as it works effectively for the proposed project.
Forming and Beginning A Game Design Documentation
One of the most important things when developing a game is creating a Game Design Document. I have recently started one for this project and have started by explaining my desired platform hardware and giving an insight into what games have influenced me and my decisions as a game developer. I have also briefly outlined the main game mechanics and their individual goals at the start of the documentation as a precursor for a more in-depth analysis at a later date.
The Version 0.1 of this documentation can be found here.
Reflecting On and Updating the Original Proposal
After the most recent consultation session with Peta, I was able to get some very valuable feedback on how my game could be improved to try and appeal to children over a longer period of time. I was able to corroborate this with the research I did and discovered that although my game targets a niche market it doesn’t do much in the way of introducing a story that would be able to further envelope the player(s). Given the age demographic and how young they are, having a nice story, even a really simple story would be beneficial for the half-life and overall playability of my game.
The Changes Made:
Original:
Originally, I was planning on just having 3 separate games that the player(s) could choose from. At runtime, the player would select a game, play it and be done with it. I was planning this because the entire point of my game at this point was to be a before school activity and I was working off the basis that “anything is better than school.” However, even games within schools need to be more engaging entertaining than simply click here and play the game.
New:
With the feedback I received, I decided to implement a story into my game. Even though it will be incredibly basic I believe that it will increase the overall enjoyment felt by players whilst also being an additional challenge where I can flex my creative muscles and see if they still work.
The Story:
The story I have devised around pirates. This was chosen as pirates were something that I could conceivably do that would have the least amount of gender bias (i.e. It is easy to have female and male pirates). The children playing the game need to go from port to port to collect treasure. To make the captain happy (planned to be a random generation between male and female captain) the crew has been split up into teams where each team challenges one another to get the highest amount of gold at each port (this is where my scoring system comes in). There will be two modes for the children to play. One mode where the game automatically takes players from port to port and one where the teacher can decide at their own discretion where they want the children to go next.
Selection Screens:
Pirate Select - Male
Pirate Select - Female
As stated above the gender of the captain will be randomly generated at run time. Some days a male captain will run the crew and other days a female captain will run the crew.
Pirate Map:
Each port relates back to one of my game ideas and the names make it pretty obvious which port belongs to which game.
Working into the future:
Although the story adds a lot to the gameplay and the overall “gaminess” of the interactions I feel that my concept lacks the feedback loop that is important for children to receive to keep them entertained. Although, as adults, we can get enjoyment from seeing a small score counter go up the same does not apply to children. Therefore, it appears that my future work on this game will be centered around increasing the viability of the proposed story whilst also working on ways to implement the said core feedback loop in a way that it would be appropriately found on a pirates ship. Furthermore, any feedback implemented will have to be changed from captain to captain. Given that most feedback will most likely be audio 2 differing audio sets will need to be created. One for a female voice and one for a male.