pharmacychallenge-blog

[pharmacychallenge-blog]

Patrick made some more awesome progress on the prototype, and for the other three members, the design stage is coming closer and closer to a close. Next week during the mid-semester break, I intend on stepping away from the design process and start to contribute to the project by implementing the various distractions the player will face, as well as creating a few models to help with aesthetic and immersion.

Again, very happy with Patrick's progress and excited to get into the development process next week.

Prototype Development 20/9

Using a mostly completed task description for prescription checking, I have started development on the mechanics of the prototype. However, after the task description is completed, some these mechanics will most likely have to be edited or tweaked to better reflect the documented design.

Development Overview

In this version of the prototype, I created a general outline for the prescription checking task. It requires the player to analyse the prescription, determine what pill type is required and give the required pill to the customer. Upon giving the correct pill to the customer, the player is given points based upon how quickly they completed the task and the next prescription begins.

Currently, the prescription does not do anything besides indicate which pill type is required, this is due to the design not yet outlining what information needs to be checked by the player to determine whether a prescription is valid or not. Additionally, nothing in the prototype has been modelled, with all interactables currently being whiteboxed with primitives. Additionally, the rounds can be infinitely played but will be capped when the full design is released.

Computer Screen

The computer screen is a persistent screen that the player sees that provides information on how much time they have left to complete the current prescription, upon which the customers leaves and the next round begins. It also displays how many points the player has earned while playing.

Prescription

The prescriptions, and other documents when added, will be the main hurdle the player has to overcome, where the player must check the information on these documents is valid. If not valid, the player will give a NO pill to the customer, rejecting their prescription. The display of the prescription only activates if its cube, representing a holodisk, is not held by the player and is not moving. Then the display spawns above it and rotates towards the player camera.

NO Pill

The NO pill is what is given to a customer with an invalid prescription. This is separated out into a different container to the other pill to give it a more dramatic feel as it is taken out. Maybe later be textured to include text to make it’s effect more obvious. A new pill respawns when a pill have been taken out and the container is closed.

Other Pills

All other pills that may be given to a customer with a valid prescription are held in a collection of drawers that correspond to a certain type. This will be updated later to convey to the player which drawers contain which pills. It is deliberately made using the physics VRTK drawer to make pulling out the pills more of a whimsical and visceral experience. New pills respawn when the required number of pills is no longer in the drawer and it is closed.

Customers

The customers are made to constantly look at the player, this is done with comedic intent but may be removed if players find it unsettling. Otherwise, the customers are where pills are given to, whether it be a valid or NO pill, upon which the customer is deleted and the next customer moves up to the counter.

[pharmacychallenge-blog]

Since Broderick, Daniel and I are still working through the design element of the project, Patrick took the initiative to start working on the basic functionality and mechanics of the prototype, using the design elements we have already completed. I feel he has made a solid start on the project, and am currently happy with not only the progress but also how the game is feeling. Well done Patrick!

I am keen to get into and start working on the project as well by utilising my programming and modelling skills, but still have a few areas in design to either complete or adjust.

9/9 Scene Setup

Setup a basic scene to at minimum prototype spacing for the playspace and see what size object need to be to be usable. At this stage, I am still waiting on design for the prototype to be established and cannot really implement and mechanics. However, do have potential prototypes in mind going forward.

[pharmacychallenge-blog]

Workshop 8-9 - Video Planning

The focus of these workshops was preparing for the second assessment piece, which is essentially a kickstarter video for the project, discussing its benefits and innovation. The objective of this video is to inform the audience of the project, and convince them that it is something that would be worthwhile investing in. The rough plan I came up for this video is as follows:

[pharmacychallenge-blog]

Designing Tasks to be Prototyped

Checking Prescriptions:

Due to the nature of this project, we feel that the most important task to be prototyped would be the process of serving customers and checking prescriptions. The reason for this is because not only is it the most common task pharmacists would complete during a normal day, but it also gives us an opportunity to test student’s pharmaceutical knowledge rather than their ‘VR coordination’ skills.However, displaying detailed information such as a prescription in a VR environment is a bit of a challenge. The information on Prescriptions is usually across multiple sheets of paper, which will be hard to manage in VR. Another issue is that if the item the information is written on is too small, players won’t be able to accurately read it, and if it’s too big, players will have issues interacting with it, as it will take up a lot of their VR space.We feel an interesting way of solving this issue would be to ‘futurize’ the prescriptions by changing them from traditional paper to a hologram disk. This disk will spawn in front of the player once the player has interacted with a customer. This disk will project a prescription above itself, allowing the player to switch between information by swiping left / right, and enlarge it by spreading it if needed. If they pick up and move the disk the hologram will disappear until placed down again.Once the player is happy with the information they have read, they can even accept or deny the prescription by hitting the yes or no button (alternative: throwing a large red pill at the customer if it is invalid). If the player accepts the script, then they will have to find the right coloured medication that is prescribed on the prescription. Points are awarded based on correct identification of prescriptions, and how fast the player works it out.

Collecting Medication:

Once the player has accepted a prescription, they will gain the task of collecting the correct medication for the customer. For this prototype, medication will only be in the form of pills, each pill being colour coded based on what type of medication it is. This colour code will be provided for the player through a poster on the wall (or through a tutorial depending on how far we go). Players must search for medication that is either scattered on the desk or hidden away in medical baskets / draws. The player can either throw the medication at the customer one at a time, or gain more points by collecting the correct amount in a container, then throwing it at the customer. Once the player finishes serving the customer, the prescription holo-projector self-destructs causing a small (purely aesthetic) explosion, then disappears from the game.

[pharmacychallenge-blog]

Discord Meeting - 06/09

Quicker meeting than usual, mainly used as a progress check and to clear up any concerns we had. Notes can be found here.

Nothing major happened. Mainly just assigning tasks to finish the GDD, planning our next meeting with the mentor team and organising how we are going to present our final project to the tutors in later weeks. 

My tasks for this week are to polish the game tasks and distractions I previously came up with, and really home in on the ones we plan to have in the prototype. Another thing is to start working on the prototype with Patrick, so we can get that on track.

[pharmacychallenge-blog]

Game Design Document - Technical Part 3

Camera

Since the game is a VR game, the camera will be ‘attached’ to the players face and move based on their movement. The only time this is not the case is when the player interacts with the computer object previously described above, as the camera will zoom onto and lock onto this screen.

Mechanics

Hand Movement:  Using unity VR functions, the position of the controllers can be used to determine where the virtual hands should be positioned in the virtual world.

Camera Movement: Using unity VR functions, the position of the headset can be used to determine where the virtual camera moves, and what direction it is facing.

Pushing: There will be colliders on the players virtual ‘hand’ objects that will collide with non-solid objects in the game. The virtual hand will add force to the collided objects rigidbody depending on how fast it was moving when it collided. If the hand objects collide with a solid object (such as a desk) they will go straight through it in order to keep the virtual hand positions linked to the real world hand positions.

Button Pressing: Works the same way as ‘pushing’ however, force doesn’t play a factor. If the player pushes the button all the way down into another trigger, the button will activate and send off a signal that it has been pressed. Points are given depending on if the correct button was pushed or not.

Interacting: There will be two methods of interacting with objects within the world.

Colliders: By connecting the colliders on the virtual hands with colliders of the objects in the world, the player can either knock them around or press the interact trigger to pick them up / move them.

Raycasting: This method is used when the player wants to interact with something out of reach (or that you wouldn’t touch), such as the customers. The player will point the controller towards the customer, then a ray-cast will be projected to interact with it. If it connects, an event will trigger, such as talking to the selected customer

Picking up: As described in the above mechanic, players can pick up objects by connecting their virtual hand collider to the collider of another object. Once this collider is connected, the player can press a button to connect the object to the virtual hands by making it a child of the hand object. This links the objects together, giving them the same movement based on the players hand positions.

Throwing: Once the player has connected an object to the virtual hand object, they can unconnect it by releasing the button. This means the object will no longer be a child of the hand, and will move on its own. The object keeps the same velocity when it is released, so is thrown according to how fast the player was moving their hands at the time of release.

[pharmacychallenge-blog]

Game Design Document - Technical Part 2

[pharmacychallenge-blog]

Game Design Document - Technical Part 1

One of my assignments for this week was to complete the technical section of the GDD. As I have a background in both programming and game design, the team felt I was best suited for this section. Main Menu Screens

The following screens will be the base layout for the main menu. The background for the menu will be one of the pharmacy environments the player will play the game in. They will be able to look around and interact with the environment, sort of like a ‘free roam’ version of the game. The interactable menu will be located right in front of the player, and will be the most obvious feature they should interact with. 

The player has the option to start the game, which then provides them the options of what type of pharmacy they want to work in, and then the difficulty. The pharmacy type determines the environment and type of tasks the player will be assigned during the play through, and the difficulty determines how many tasks there are, and how detailed the player has to be.

Players can view a ‘logbook’ of the results from all their playthroughs, so they can get a sense of their progress, personal bests and the areas they need to focus on.

Options allows the player to adjust settings to their like (volume, resolution, etc.), as well as choose whether or not they want distractions in their playthrough. (Which is also available to change during difficulty selection). 

User Interface

These are the screens that will be available to the player whilst actually playing the game. The first is a log of all the tasks they have completed / need to complete, the second is how long they have spent in the current playthrough, and lastly is the pause menu when the player hits the pause button. These screens will be located on a computer object that is located on the players desk. This computer object will act as the UI for the player, since UI’s can be quite awkward in VR space. Players will be able to see what is displayed on the screen without interacting it, but will need to zoom in on it in order to change the information displayed or see the information better.

[pharmacychallenge-blog]

Week 7 Workshop

Workshop notes can be found here.

The main focus of this workshop was covering assessment #3, and working out what deliverables the team would have at the end of this unit. The team feels comfortable that by the end of this we will be able to supply the following:

- A Game Design Document that fully details the game - A prototype of our game - Project file (not build) that shows off the base  - Playtesting report / results that show off how effective (or not) our prototype is - An Individual (not team) document that supports the rest of the deliverables.

The rest of the workshop was spent clarifying a few concerns with the teaching team, regarding the innovation component of this assessment. Another thing was organising access to a VR kit to experiment and start developing our project. Deb kindly offered to give us access to her lab room Mondays 1-4.

[pharmacychallenge-blog]

How to make a VR game

Since this project is the first time tackling creating a VR game, I felt it would be beneficial to look into how it actually works, so I can take away some of the ‘magic’ and feel more comfortable heading into the development phase. Below are a few notes I took while researching this topic:

Getting started - It’s a simple as ticking on a boolean. Go into Edit>Project Settings>Player and check the box to enable “Virtual Reality Supported” - There are many useful pluggins on the unity store (Unity VRTK, SteamVR CameraRig, VR Samples, etc.)

Development Tips - Don’t underestimate the planning stage       -  It’s also important to get creative with your 360 degree storyboarding - Spend more time on sound. R&D’s sound-lead VR experience.  -  It’s tempting to try a lot of new innovations all at once, but it pays to limit your variables.

Other - Computer may lag or judder as the computer is rendering the same content twice, rendering the Unity IDE also has some overhead, so it’s best to occasionally check performance on the target devices as well by creating a build of your project, and running it directly. - You cannot move the VR Camera directly in Unity. If you wish to change the position and rotation, you’ll need to ensure that it is parented to another GameObject, and apply the changes to the parents Transform. -  Depending on the complexity of your VR scene and the hardware you’re running, you may want to alter the render scale. This controls the texel : pixel ratio before lens correction, meaning that we trade performance for sharpness. - There is a raycasting for Eyes in VR, used to determine where the user is looking. 

Sources:

https://unity3d.com/learn/tutorials/topics/virtual-reality/interaction-vr

https://unity3d.com/learn/tutorials/topics/xr/getting-started-vr-development

https://unity3d.com/learn/tutorials/topics/virtual-reality/vr-overview

https://simpleprogrammer.com/unity-vr-development/

https://www.bbc.co.uk/rd/blog/2016-11-virtual-reality-production-tips

[pharmacychallenge-blog]

Mentor Meeting 31/08

Had a meeting with one of our mentors, Esther, and showed off what we had been working on, our updated shared asset list and few game ideas we came up with. Meeting notes can be found here. 

The main thing I worked on for this shared asset list was working out some potential game mechanics for tasks and distractions during the game. Below is the list I came up with:

[pharmacychallenge-blog]

Discord Meeting 30/08

Meeting notes can be found here.

Main purpose of this meeting was to get everyone on track and prepare for the mentor meeting the following day. 

As previously mentioned, in order to prepare we set up a ‘shared assets’ document to show to the mentors to keep them on the same track as us. This meeting spent making sure everything was completed and accurately portrayed what the team was thinking. 

Another thing that was brought up was that we were really lacking a backlog to keep us all on track, so Patrick kindly decided to organise that for us. Our backlog can be found here.

Continued assigning section of the GDD to members, and set up a repository so we can start prototyping our project.

[pharmacychallenge-blog]

Solution Statement and Storyboard Planning

A task for the workshop today was to create a solution statement that accurately and concisely portrays the project brief. My solution statement was to following:  - To design / create a realistic VR experience that accurately portrays the daily life of a pharmacist in a risk-free environment. Other team members came up with statements such as: Dan -  Design and develop a virtual learning experience of a busy pharmacy workspace that challenges students with everyday encounters and distractions that pharmacists often experience in the real world. Broderick -  Design a VR learning experience for pharmacy students that portrays the daily distractions often encountered in a pharmacists day. ----------------------------------------------------------------------------------------------- After that the team did a few brainstorms for our storyboard planning. The main ‘storyline’ we came up with was focusing on a stressed out pharmacy student being overwhelmed on their first day as a pharmacist, with all the various tasks and distractions. They’re sad and leave disheartened. Then we show the same student playing our game in VR, and learning in a safe environment, feeling much better about themself. While this is playing out, we explain the benefits of using it and how it prepares them for the real thing. The video ends with the student feeling happy and confident in their new job.

 The main thing we were unsure of was actually portraying this in a video with low production quality. The 3 main ideas we came up with were: 1. Filming paper cutouts being moved around on paddle-pop sticks 2. Filming a first person view of hands playing out the game as it would in VR 3. Doing a merge of the two, using art assets to portray difficult scenes / models

[pharmacychallenge-blog]

VRTK Testing

Unfortunately, despite being a VR focused brief / project, we initially weren’t provided with access to a VR tool kit to allow us to test and iterate our development on the prototype. This was due to the mentor team not actually having a VR kit, and the teaching team already allocating the kits to the teams that are working on their briefs. Thankfully, Deb was kind enough to allow us access into her development room, which contains a VR setup. Patrick and I took this invitation and played around with various player controls, gameplay mechanics and UI elements. Since Patrick has taken the lead in the development of this project (due to previous experience with VR game dev), he had a better understanding of what everything did, so acted as a ‘guide’ for this testing session. Overall, we decided on the physics system that felt best, as well as what mechanics we will include in our project.

When playing around with the UI elements in VR, it was found that the current plan for the Menu UI probably wont work too well, as it just feels bad to use in a VR environment. Therefore, I will have to redesign this section of the Game Design Document, making it more ‘VR friendly’. This will probably be done by picking up and placing objects in certain locations (such as a computer disk or pill placement), which will then load the required information / game / etc.

While a bit late in the cycle, this session was a great start into the development of the project. A more detailed version of this session can be found on Patrick’s blog here.

[pharmacychallenge-blog]

Mentor Meeting Prep

In order to catch our mentors up on what we have been working on and what is expected, we created a document that details the important sections of our work so far. This document can be found here.

[pharmacychallenge-blog]

Game Design Document Pt. 2

Game Flow/Game Progression

As soon as the game starts, the player is placed in front of their work station (which will be either a counter / desk as described in part A). Since there are still some issues with virtual movement causing motion sickness in VR, player movement will be restricted, so this will be the main location where the whole level takes place. The player will have a grace period to familiarise themselves with the surroundings, and give them a chance to play and interact with the various tools and items within their reach. After this short period is over (or has been skipped), the player will be met with their first customer, and thus their first task.

Tasks will start off as one at a time, simple activities. As the game progresses, the tasks will become more complex, stacked and time restricted. Another obstacle the player will encounter will be various distractions that are typically found in a pharmaceutical environment. Most of these distractions won’t directly affect the gameplay and will simply be small things to throw theplayer.

For our prototype, we expect to have the following features and game flow:

Player starts game and familiarises themselves with their play area

Player has option to read and remember instructions in front of them

Typing / public murmur can be heard in background

First customer arrives and asks them to collect an item for them

Player turns around and finds item, gives it to them.

Baby starts crying in background

Player has option to offer lollipop or ignore it

Another customers asks a  question, player presses button to answer (green card for yes, red for no).

Player has to deal with two customers at the same time, has to juggle two tasks at the same time

Player is interrupted by an associate (or phone call) to look over a document, presses red or green button depending if it’s all good or not.

Player receives points based on if they were correct or not

Player continues with previous customers

Customer throws up on players desk

Player can ignore it or clean it up using cleaning tools

Process continues, test effectiveness of each  distraction type as game goes on (player performance, accuracy, multitasking, etc.         

[pharmacychallenge-blog]

Game Design Document Pt. 1

Since one of the expected outcomes of the project is a design document detailing the game (or games), the group decided to make a good start on it for this design cycle. We broke the typical layout of the document up into parts and identified the more important areas to complete first. I was assigned to work out the level design for the project, so I explored things such as the aesthetics, theme, interactable as well as the game flow / progression.

Themes

Mood

Since the game at its core is essentially a pharmacy simulator, the obvious setting for the game would be within a pharmacy. This means the theme of the level will be very professional, clean and organised. However, since the player is restricted to the one location (but allowed rotation), their work station will be an ‘organised mess’, containing objects that wouldn’t usually be stored in the same area. This is so the player can interact with everything they need to, without physically moving from the spot. Below is a rough layout of what the player space will look like:

Objects

Ambient

Medical

Detailed (prescriptions, instructions, ingredients,     etc)

Interactive

• Customers - Will approach the player and either ask questions or want medication. Once spoken to they will move to the waiting area.           o Prescriptions - Player has to inspect them to determine if they are legit or not. Player then presses a button once decided. • Medication           o Pills - Coloured differently depending on type. Player must collect and    provide the right colour and amount to customers           o Syringes - Again, coloured differently depending on type. Player must    collect and provide the right colour and amount to customers • Medical Containers           o Containers (Baskets) - Contain more documents and medications           o Drawers - Contain other items such as cleaning equipment, bandages,  etc. • Machines           o Computers - Since HUDs are awkward in virtual reality, the computer    screen will act as a HUD that displays important information for the        player (Timer, Database, Score, Current Task, etc.)           o Phone - Will randomly ring throughout the game, if player answers they  will be given a question and will have to push a button depending on answer.           o Dispenser - Player has to push the right symbols in order to get the        right medication           o Buttons - Used to approve or disapprove scriptures or questions • Documents           o Papers - Used to give instructions to player, and also displays colour      code for what each medication is and does           o Clipboards - Does nothing mechanically, used to build atmosphere and  gives player more things to interact with           o Pens - Does nothing mechanically, used to build atmosphere and gives  player more things to interact with • Cleaning Equipment - Used to clean up accidents, lose points if workstation is messy for too long • Lollipops - Used to calm down upset children (and customers) Game Flow/Game Progression