Sheena @ BCT

Reflection

The making of this project has been a lot different than what I’m used to. 

As this was the first time making a game for a Studio project, I left most of the development process to Matthew, as he had done games plenty of times before. The process I usually follow includes a lot of time spent on research and ensuring each design decision was well informed before implementation. However with our focus on environmental storytelling, a lot of what we did needed to be implemented and tested to see if it was successful. That being said, there was research to inform us in a lot of decisions, but not as I’m used to. Although this difference was slightly jarring for me, I feel like learned a lot from working in a different style. I do feel like I would revert back to my normal development process though, as I am more comfortable with my own process.

The chosen goal for our project was something I’ve been wanting to work on, creating a game which communicates its story through game play, such as Journey. I feel we’ve achieved this goal well given the time we had and our small group size of two people. There’s definitely more that could be added, more hints to the hidden narrative or visual stimuli. 

I’ve really enjoyed developing this game, I’ve learned a lot about coding in Unity and it’s great to feel like I have a skill I actually kind of excel in. I definitely still have a lot to learn and would like to challenge myself with a 3D game rather than just 2D. 

Submission

Link to blogs: https://sheenaatbct.tumblr.com/tagged/CTEC709

Final touch ups

After fixing up all the little bugs from playtesting, I fixed up all the sound issues and all the other extra sounds I was given to implement (boss sounds for example).

Next was implementing a new enemy, a tiny little creature which doesn’t do much damage, but helps the player in terms of difficulty progression. 

This was easy enough to do, with the already made code from the other enemies. In fact a lot easier since the enemy just dies after it attacks.

With this done, Matthew and I were able to place the enemies where they needed, and could decide on where new enemies would spawn between each door opening. 

The code for spawning was something I did last semester, so I just referred back to that code for it. The way I did it isn’t the most efficient, there is definitely a better way to do it, however, I don’t have the time to learn something new.

At this point, we’ve done everything we could for presentation. There’s a little bit more that we could do for showcase but right now, we do not have the time. 

Boss and Playtest

Since most of the main part of the game is complete, with only some touch ups needing to be done, I started on the boss fight.

The mechanics for this mostly included things I’ve done previously with last semester’s Game and Play project, so I’ve taken the code from there.

Whilst playing around with this, I felt that the boss’ attack was lacklustre, so I added the mechanic of having the vines chase after the player briefly, rather than just popping up randomly.  I also needed a way to let the player know that the vines were being hit by the laser. For this I changed the colour of the vines to red when the laser is hitting them, which is a common technique used in video games (from personal experience).

Matthew also explained to me about boss battle mechanics, how they increase in difficulty, but also often have a twist which the player must adapt to, for example, the way the boss attacks changes. Unfortunately, we do not have time to implement a twist, but we can do increasing difficulty.

For the increase in difficulty, I’ve had the number of vines increase based on the boss’ health. There is also one of the previous enemies which spawns in the room, again based on the boss’s health.

I had a friend volunteer to play test the game so far, with its new changes.

I noted down all the bugs I noticed from their playthrough which I can quickly fix later on. Some other comments that they had were

Likes that the player can strafe

Enjoys the animated world

The one enemy (Error enemy) is spooky

Likes how the scenes give perspective on the world size

Interactable Environment

From Laurent’s and our playtesters’ feedback, we decided our game would benefit from a more “alive” and interactable world. By having everything so still, it was hard for the player to immerse themselves into the game, and feel as though the game world was alive. Without this, it was more difficult to create a narrative. 

Matthew worked on creating a bunch of animations where he saw fit and sent them over. After implementing them into uni, I immediately noticed how much better it made the game feel. The animations gave the world a bit of life.

Submission Blog

Link to blogs: https://sheenaatbct.tumblr.com/tagged/CTEC703

Playtesting

With everything stitched together, it seemed like a good time to playtest. 

Our goal with this game is to use the environment to tell the story. I haven’t done much peer playtesting with the mechanics and such as they are quite basic and only contribute a little to the big picture (of environmental storytelling).

We told half our playtesters to come up with a narrative whilst they played, and the other half were not told anything. 

We asked at the end what they thought the game was about, to determine whether or not they had interpreted a story/narrative. This is important as if they cannot, then we need to find ways to make it more clear. 

Other questions were more based on game design itself, asking about their thoughts on back tracking through the map, if they understood what to do, or if there was any other confusion. 

Overall, the results show that we have achieved what we set out. Almost all were able to interpret some sort of narrative, and all were almost spot on with the narrative we intended to show. 

Everything else was pretty smooth, there were just some issues with the way we communicated controls, and some game design issues. Most prevalent was not understanding that ctrl is used to pick up items, which could be resolved by having an animation or sound play to indicate something has happened. 

The one part which was under debate was the backtracking. Whilst most did not enjoy it, others did, saying it made sense with the exploration aesthetic. Those that did not enjoy it felt that it was boring and would have preferred shortcuts or a way to speed up the player.

In terms of length of play and deaths, most playtesters died once or did not at all. The average time was about 12 minutes. This is about right for showcasing and for difficulty, we do not want our players to be struggling to progress as that is not the aesthetic we want (in terms of the MDA Framework).

From this, we know we are on the right track, we just need to fix a few game design issues to create a nice flow to the game. 

Click keep reading to see all the notes I took

Adding in Details and Fixing Issues

With the game basically completed, I just needed to add extra details and fix up some issues that were a little bit game breaking.

I’ve added in all the areas I’ve gotten from Matt and had him populate the areas with enemies and rubble where he imagined for a complete play area. 

One issue that was really bad was having the laser be an extension of the player, which meant that shooting it in the right places means that the character may end up moving to a different area. I had a little google of this issue, with the best solution to separate the laser from the player, and have a different parent for it which is always in the correct place for the laser to appear. 

Another issue I had was while all the enemies were in place, all of the vine monster’s vines weren’t working the way they should, or at least two of three were not working. Max ended up helping me with this and talking me through the problem which fixed it up.

Matthew created some button prompts to show up to help the player along with controlling the character. I’ve added these to show up when most appropriate. 

Next was getting the camera to shake while the player shoots the laser. Brackeys comes to save the day with his tutorial on this. I also learnt to watch tutorials to completion because they usually go on to explain how to fix things that aren’t quite working right. Again, Max helped me with making the shaking end exactly when it needs to. There was a lot of experimenting with numbers to get the right feel to the camera shake. I added this camera shake to the big door opening as well.

See below these new updates!

I’ve started adding in sounds that Matthew has been working on, however this is a low priority item whilst we get some play testing done. 

Research on Collaboration

Here’s some notes from what I’ve read:

Conscious Collaboration

Collaboration is something which may occur spontaneously however it usually comes by with effort. To ensure a positive experience, there must a shared goal and understanding, which is held together with shared values. 

“It is through individual effort, something new is created, and that the glue is the shared vision.”

I thought this was neat to show the differences between work methods.

It’s almost natural for us to collaborate as social animals. 

Trust, courage, generosity and humility are important to have when collaborating. I believe collaboration would help to develop these skills and employ them in other contexts. 

Success from collaborating comes from surrounding ourselves with people who share the same purpose and support our goals. 

The book goes on to describe how to effectively collaborate, with some things like having the right mindset for working together, and beginning by planning the end goal. 

I think the skills described in this book would develop with collaboration and also develop other interpersonal skills.

Benefits of Collaborative Learning (Laal, & Ghodsi, 2012)

This paper discusses the benefits of using a collaborative learning style in the classroom, however the findings are quite relevant in any context.

Collaboration makes each person in a group responsible for their own actions and helps people to recognize and understand their peers’ strengths and abilities. 

In comparison to working competitively or individually, collaborating was shown to have higher achievement and productivity, make individuals more caring and supportive, allowing for more committed relationships and social competence, and gave individuals greater psychological health with greater self esteem. 

A lack of competition allows people to create healthier and more positive interactions with others and understand diversity. Individuals also develop critical thinking skills. 

For collaboration to work, there must be:

Clear positive interdependence

Promotive interaction

Personal responsibility

Relevant interpersonal skills

Work on improving group effectiveness

References:

Emmens, B. (2016). Conscious Collaboration: Re-thinking the Way We Work Together, For Good. Springer.

Battery Powered Doors and Fading out

It was time to put together the actual pieces of the game together that would make it have a story and end goal. 

The powercells need to be able to be placed into the generator in the final room, to open doors to find more, to open the last big door where the boss will be. With each door opening, the camera needs to show where that door is whilst it opens.

I’ve used a lot of what I’ve learnt so far, using animation events etc. to make this happen. Matthew has also made a fade for transitions, which I’ve used to change the camera to the door, but not back to the player’s location. This fade also gets used for other transitions, like moving between elevators and teleporting. 

Basically, everything here uses animation events to trigger everything. It was really annoying to get the timing right so that the camera moves when the screen is completely black. I’m sure there is a much easier way to do this but I just stuck with the way I know how.

The one annoying thing I had was when the powercell was inserted into the generator, I just deleted that object, however it caused unity to create many many errors, which didn’t really affect the game play, however it could cause some lag issues later on. Matthew suggested moving the powercells waaaay out of view, which made me realise I only needed the one powercell. This one powercell just had to move to the next location to be found, and once inserted again, move to the other location to be found again. On the final one, I just did as Matthew said and moved it waaaay out of the way. This resolved the issue.

I’ve also made sure that the rubble you can pick up does not interact with the generator as to not trigger anything prematurely. 

See video below!

Final

Link to our slides 

This is the final outcome for our project. 

The outcome for this project is how we imagined it to be from the start. We were lucky enough to get actual phones to use for the installation. 

In terms of our team work, I think there was a good spread of work between everyone. We all helped each other out, and gave feedback on each others work. 

Given more time to work on things, there are a lot of things we could have tested or taken a risk on. We only met up on Wednesdays to discuss and bring our parts together, however we may have gotten more done had we met up more frequently.

Personally, I felt like I could have contributed more. I didn’t really have a clear cut role, however I did help out where I could. This involved research, helping with the physical lay out, and giving feedback on the visual components. With the amount of members we had, I think more risks could’ve been taken with trying to expand our work.

Progress n Stuff

I’ve been working a lot on the enemies to get them all polished off. Firstly was getting the big plant monster to actually harm the character with its vine attack. I found this one tutorial earlier on when figuring out the other enemy that showed that you can record this in you animations (i.e. you can edit colliders to show up/change over the course of an animation!!). I tried using this method for the vine attack and it works really well! Had I known to use this method, I could have implemented it into the other enemy, however the other way works too so there’s no need to change when I have lots of other things to do. 

Matthew also decided to change the look of the first enemy, which just meant I had to swap out some sprites, everything else works fundamentally the same.

I got some animation updates for the player, death and waking up. I’ve set it up so that the player starts back at the beginning after dying. This was done using similar methods for switching between areas. 

All of this is shown below:

I also made some changes to the rubble. The rubble is an item that needs to be able to be picked up, but is also something that stops the player from moving. I had to add a collider which would stop the player moving through the rock. This made a few issues arise, all of a sudden the player was being dragged down. I played around with a lot of things (adding a rigid body and changing its type, changing where it would be positioned when picked up). Basically, the rock was trying to be exactly where the player was, making it push the character out of the way. I just had to make a few adjustments to ensure it didn’t interfere with the player.

See below:

Week 9

After presenting our project to the class, Ben gave us some solid criticism. Basically, our project has no real direction, or place in the world. It’s purpose is unclear. And I agree. We had been trying to come up with a clear target audience, or even an aesthetic to follow with little success. 

Anyways, we’ve chosen to focus on collaboration and have this following project description:

We are designing an interactive installation that presents a statement on the benefits of collaborating with others.

Andrew is going to continue looking into materials, as the fabrications man, Matthew is continuing on with sound research and I will be looking into collaboration and cooperation. 

This new direction is good for us, at least in terms of submission, but there is a lot of stuff I wish we had done with our previous idea and development process to have made it a worthwhile project.

No one really took charge as a leader in our group, which lead to each of us trying to follow our own process’s and trying to merge them all together. Which doesn’t work. I found it difficult to get heard and my team mates probably felt the same. 

I think next time, it would definitely be important to set a clear leader, even if it means that I have to step up. I need to believe in my own capabilities more. I need to assert my opinions more clearly even if they may be wrong. 

Putting things together

We worked out a lot over this last little while. 

Firstly was changing up the lay out of the phones, as it seemed too organised to represent the chaotic aesthetic we were aiming for. For it to pair with the visualization though, it still needed to have four rings.

I shifted the phones out and around, so they fill up more of the projection space and to give it a more randomized and chaotic appearance. I used coloured post it notes to keep track of each ring.

Stuart was working on getting all the footage together to appear at the correct times. When trying to use these all on Heavy M (projection software), the program would start to lag, causing the videos to lose frames. There was also the logo for the program which would show up throughout the projection. This was a bit of a set back for us as we didn’t have access to other programs for this. 

The solution we came up with was to place everything correctly, then to export it as a video. Stuart could then work on placing the footage in the correct places and export this as a video to play on loop. This would get rid of both the lag and the awful logo. 

Stuart also wanted to experiment with having a background to the projection which would grow in intensity.

Week 8

Over the break, we met up 3 times to work on our project. 

I was in charge of coding, however I was struggling a lot with Processing. I chose to use Processing as this program is particularly good with visual and pairs well with Arduino. My only problem is that I haven’t used Processing since year 1 and I really didn’t know what I was doing despite watching a bunch of tutorials. 

It finally hit me that I could be using Unity and still get the same results, except I would actually know how to achieve it. So I made the switch to Unity. 

Matthew had been working on making different sounds. These were a bunch of notes that were inspired from the examples from games and such that he had looked into. We also tried getting different beats that would work together, like in Musical Chairs by Simon Watts. This didn’t sound so great though, so I thought to just stick with the notes. 

Andrew had been working on the step pads, and wiring them up to the Arduino to get them working. 

I had to use some old code from a previous project to get the buttons to only register once when stood on.

We talked a lot about what the visuals would actually show, but nothing really came from it. There were discussions about the whole aesthetic, Andrew suggesting we have it resemble a big robot, where the visuals are it’s face, the step pads being its fingers. This would work well for a target audience of children. 

For now, I just used the particle effect on Unity to at least have something shown on screen.

We did some play testing with this all set up in our studio space. 

We had people coming over to test as individuals and as pairs. Overall, people enjoyed interacting with our project in pairs, and would spend longer playing with it. 

They figured this would be found in a public space. 

Updates and More Additions

The player has a new skin! And more animations. Have a look:

And a new enemy to work with. This was an interesting challenge as the attack is ranged. The vines which extrude from the mouth of the enemy needs to be directed at the player. Luckily for me I found a tutorial earlier on when figuring out the enemy following the player. This is the tutorial here. 

Stress Testing

We had the projector up and running to test out the different screens; single layer of sticker paper, double layer, and the grey tones. 

It was pretty clear that the best method was the double layer, the opaque white makes for a clearer projection. The grey was too dark to see the projection well, and the single layer was slightly translucent to the colours already on the screen.

Rachael got onto putting another layer of sticker paper onto all the phones and placing them back up on the wall. The layout expands out from a central point so the intensity of the projection and paired sounds will spread out from the middle. 

The phones have been up on the wall for a long time, and don’t move despite having the wall shake or any other disturbance from the surrounding area. Blu tack really sticks well. 

The projector were using was used previously for another project and was left on for a week in a much more confined space without over heating. So no worries over this aspect. 

The only main problem is having the projector move, which would shift the projection off the phone screens. To try and avoid this, we have set out tape to show where the plinth and the projector must be placed, however it is still a little bit unreliable. Ideally, when showcasing this, we would have barriers to prevent people walking past the projector and stand. However, whilst studio is still an open work space, it’s unavoidable to have people constantly passing by (despite it being in the corner of the room).

We really need to work on the media that’s being shown. It’s looking good so far with our testing but it seems the program lags a lot when a lot of video files are placed on. Also as a personal opinion, the visual is very... meh.