#games proposal

[victoriacarrfutureworks]

XB3001 - Reflective Diary #12

I base coloured the main menu screen and implemented visual and audio feedback on the menu options, so they make a ‘click’ sound when the mouse hovers over them, and they light up as well. It was looking very nice visually. I also made the game over screens for both the deaths of all the A.I and the timer ending, utilising sound and the event construct to make them more dramatic to the player.

The biggest task completed at this time was the score screen, which is shown when the player completes the level. It involves a timetable that uses blueprint to add or subtract values together. It displays the player’s score in the game level, the score the player gets for the amount of time left, the score taken away for the number of deaths, and the total for all three. The player can then select to try again for a better score, or quit the game.

[victoriacarrfutureworks]

XB3001 - Reflective Diary #11

I then had a go at creating the countdown timer for the game and making that a game-fail state if it ended before the player was finished, then coded that to the HUD. I did encounter an infrequent bug where the timer would end too early, but determined it to be a program bug rather than a blueprint bug, where the delta seconds became de-synced. The only fix for this when it occurred was closing and re-opening the project.

I changed the menu screen with a sketched out version to see how it looked, and it turned out very nicely. I re-coded the controls, options and main menu to fit with the new menu screen, so it wouldn’t have to be replaced later. I also added controls to the pause screen to enable the player to view the controls whilst playing, in case they needed reminding.

I started messing around with how to add dialogue from the tutorial teacher ghost, trying to get it to pop up and stop the player moving when it is there, so that they read it. I managed to code in one line, but was unable to get it to cycle through the different dialogue lines on a button press. If I had time, I intended to look into getting it to type out as well.

It getting late in the development stage, we decided to cut the introduction sequence from the game as there just wasn’t enough time to draw and implement it in, and it seemed a better idea to put more focus into improving the mechanics we had than to add something completely new at this stage. We have also decided to settle for more basic textures in the game, as there is a lack of time to complete all of them.

[victoriacarrfutureworks]

XB3001 - Reflective Diary #10

After watching more gameplay of The Haunting, a 1993 Genesis game, I determined that the level itself could be done a much better way, and would avoid the need to code the mechanic of hiding walls into the modular wall pieces. I spoke with Phil, the level designer and 3D artist, to get his thoughts on the matter as it would mean more work for him. He liked the idea, and didn’t believe it to be too difficult to do, so he agreed to produce the work as soon as he was able.

The level was changed accordingly, and the vertical slice protorype was now split between two level blueprints. One has the outside of the house with an introduction to the gameplay, and the other is entirely the inside of the house where the main gameplay will take place. It looks a lot better, but the layout needed a little improvement, so I worked with the level designer to implement this.

Our audio engineer collaborator’s honours project was due, so I spent time working with her to implement in what sounds she needed to show and submit for her project, blueprinting them into the game. It sounded good!

[victoriacarrfutureworks]

XB3001 - Reflective Diary #9

I successfully got the mouse to move, as it turned out I had just missed a checkbox. Coming back to the issue with a refreshed mind helped find that. I also finally managed to stop the A.I from leaving the house when they weren’t supposed to, but can still leave when fleeing the player.

I finally coded in a game-win state by creating a killzone the player cannot enter over the end of the A.I’s fleeing point. When all actors of the A.I class is destroyed (upon entering the killzone) the player wins. My next job was to try working on a way for the player to fail if all the A.I die, but I wouldn’t be able to use the destroy actor node as that is used for triggering the win state, and we also wanted the bodies to remain in the level for the player to see. By using a variant of the coding in the win state, but instead using the ‘dead’ Boolean, I succeeded. The job after that was to code in a partial win, where at least one A.I dies and one escapes.

[victoriacarrfutureworks]

XB3001 - Reflective Diary #8

I changed the behaviour task to make the A.I move randomly instead of point to point, to stop them from following each other. It also allowed for a different experience each time, and made the A.I more unpredictable to the player. The next task to solve with them was to stop them from leaving the house when they weren’t supposed to, as they kept escaping out the open door the player enters in through. In trying to block the A.I from leaving, I messed around with the collision on both the A.I and the player character, and successfully fixed the bug of getting trapped in possessed objects. The player also now goes through the A.I, so they do not collide together, as a ghost should.

Decided to research other ways to fix the escaping issue, and came across the option to filter navigation classes to create different types of navigation. This seemed like a plausible solution, but needed some more extensive research putting in. I also made a small mouse A.I for the player to practice scaring on before entering the main house level, which only has the one task, but I could not figure out how to get it to move, I couldn’t understand why.

With it approaching the end of the development time, the game itself was looking very good and we had a lot of assets to utilise, however we were very much lacking in textures. I decided to start trying to work on potential contingency plans.

[victoriacarrfutureworks]

XB3001 - Reflective Diary #7

Returning to class following Maria’s visit, I chose to focus on bug fixing now we had a compiled game.

I succeeded in stopping the A.I from playing the death animation when they weren’t actually dead in the behaviour tree, which had then caused them to slide along the floor as they continued to move after the animation had played. It turned out to be that the float numbers in the ‘scare’ blueprint and the animation blueprint were different. It was a hilarious bug but had to go.

I also coded into the character blueprint that once they energy bar is depleted the player was then kicked out of possessed objects, which prevented the player from getting permanently stuck inside a possessed object. They could still get stuck and be forced to wait for the energy to deplete however, which was another bug to look at.

[victoriacarrfutureworks]

XB3001 - Reflective Diary #6

We learned a lot from Maria Stukoff’s visit. She gave us all a good lecture on Sony’s approach to indie development, and ran us all down on how to make a good game pitch and pointers on how to work on our games. Four group’s games were shown to her, and we showed our ‘Spoopy Brigade’ third. As team leader I did most of the talking, and took on board what she had taught us about pitching in the lecture and the feedback she gave the groups prior to us. The game and pitch seemed to be very positively received, and she was impressed with the work we had done so far and liked the direction we were going in.

My biggest concern in showing her was her witnessing any of the aforementioned bugs but, somewhat thankfully, she did not play the game herself and instead watched us play, so we were able to circumvent them by intentionally avoiding what was triggering them.

[victoriacarrfutureworks]

XB3001 - Reflective Diary #5

After enjoying a Valentines weekend, we all returned to work for a very long crunching session through the Monday and Tuesday to put the game together for Maria Stukoff’s visit, a representative from Sony, on the Wednesday.

The game finally became a proper playable demo instead of a whitebox room. It was unfortunate that it took such a crunch session to get it there, but it was amazing to see it all finally working together. We used base colours whilst we didn’t have textures for our objects to make them look nicer and pop out, and Will had added small animations for reinforcing the scared people and an animation for the scaring itself, giving good visual feedback.

Bugs became apparent after the game was together, such as getting stuck against objects, getting trapped in objects and A.I triggering the possession mechanic, but this was okay for Maria’s visit as she was aware they were in-progress prototypes.