UNIT 22 P4

Just as a note, it was my task to compile the Unit 65 blog and prepare the relevant evidence.

GANK CHART

I've provided the Gank Chart as evidence that my work and contribution to the team was consistent over the course of the project. It also works as evidence for part of my work as I, as the producer, was in charge of up-keeping it both to keep a plan for the project as well as updating it when a task was completed or resolved in any way.

As for its actual content. The gank chart was started at about the start of P2, just after the paper prototype was completed. The very first lesson after its inception was spent assessing, planning and figuring out what would be needed for the games completion. The game designer broke down the prototype into steps, the artist started working at what sprites, animations and somesuch would be needed. I worked on the gank chart, turning that work into a cohearant plan. I also went over the mark scheme and our own previous documentation in order to further rationalise what needed doing.

In the following lessons, I was completing the paperwork and documentation required for the P2 of our project, pausing on occasion to talk to my team about various mechanics ideas, concepts and such and such, which made their way into the P2 game design document. I was also pausing to help coordinate the artist and programmer, such as making sure the assets the artist was creating was being utilised by the programmer as intended.

Over the next few lessons, I utilised my skills I had been refining in my Graphics Design elective to produce a menu as well as a layout plan the artist could use to begin working on the background. At this time (Friday, week 17), I realised that creating and animating sprites took plenty longer than I had anticipated on my original plan, so assigned myself the task of producing the enemy sprites in order to better balance the workload between people.

Continuing, I re-evaluated decisions made in the P2 game design document to better reflect the direction the game was taking in its current form, as well as rationalising it with my newer understanding of what was and was not possible in the time frame provided. The plan was amended to omit elements such as boss fights or power-ups, as those were mere fluff around the core gameplay and would've drawn resources and time away from the minimum viable product. I continued with the enemy sprite animations, and though the artist worked faster than me at these things, I was able to complete it while only investing the next two lessons on the task.

I took the next lesson finding or creating sound elements to be used in the final product. That done, I knew that a testing day was soon upon us and worked more closely with the team to coordinate, help out with and ensure that the prototype was ready for prime time. After two lessons effort, all that was needed was for Cian, our programmer, to show up with the prototype.

What could go wrong?

in the subsequent time allotted by the half term, I made sure that any tasks that had not been completed were completed. I again reassessed the plan and P2 game design document based off of the games current state and direction, and made sure that the animations I had produced were working, available to the programmer for implementation and of a high standard.

With our teams artist having completed the games soundtrack, and me having created most of the sound effects, I got the last created and implemented them into the prototype with the help of both the programmer and artist.

On the Wednesday, our programmer was absent. This was a big setback; two hours of work had been lost when the prototype really needed all the work it could get. I stepped up and had a go implementing an element into the game; a method in which the player could reset the game should they die. I wasn't as fluent with Unity as our programmer, but was able to implement it in the time without significant issues. I made sure that the controls were apparent to the player by writing them on the background of the level.

Now, the ball was in the programmers ring. He had plenty to do, but only one person can work on the prototype at any one time due to how Unity's sharing mechanics work. Leaving him to it (he needed the concentration I'm sure), I began assessing what would be required for the Unit 65 blog, as well as my own Unit 22 blog. I began work on the Unit 65 blog, and at the end of the lesson helped get the menu implemented right on time to help export it, handing it in and finishing the project.

P1 Game Treatment 

I have removed any slide which I did not directly create, to ensure only my work is being presented for Unit 22.

P2 Plan And Elements

I wrote, designed or produced every element of this powerpoint WITH THE EXCEPTION of the concept art located in section E. Yes, that includes the logo, and the layout plan in section D

P3 ASSETS AND SPRITES

Enemy Zombie

Sprite Sheets

Walking

Attacking

Dying

Animated Gifs


Walking

Attacking

Dying

Main Menu

In the original design vision, the idea was for the menu to split in two, each segment sliding off the side of the screen. The logo and menu options would slide upwards, revealing the game arena. Sort of how Battleblocks Theater worked with its drawing curtain and how the logo would be moved in at the end of a match.



Zombie Moan 1

Zombie Moan 2

Zombie Moan 3

These zombie moans were recorded both as a sound file for the zombies to play at irregular intervals, and also to meet the requirement that the game elements feature a 'voice over'. These moans are an action game with a silent protagonists way of fulfilling these requirements.


Retry Button Implimentation

One of the tasks I had to perform for my contribution to the group was a method in which the player could reset the game in an instance in which they died. I started out by drafting the code, using an online resource I found as a base for it. I created a button, linked it to a game object, and gave the game object the script for the reset button. I made the button a vibrant pink to go against the deep red backdrop of the skyline.

The button itself was attached to the camera as a HUD element. This turned out to be quite awkward when we exported the game, as the camera was at an odd zoom, which meant that the HUD element 'fell of the screen' somewhat, but it was still visible and still functional.

P4 GAME HAND-IN

There isn't much to actually put here per se. I helped produce and export the game as much as any member of our team. I did record the videos present on the Unit 65 blog, but I constructed the Unit 65 blog myself so of course I recorded the videos.

So... yea.