Sam's AAA Contribution Evidence

A weekly blog for the AAA Project

Week 1, Sunday 22nd of January

• Learned about pre-production design

It's the start of a new term which means lots of blood, sweat, and getting caught up in interpersonal relationships. Classic Uni. First, we had the cohort session where David briefly revisited Agile Project Management to (I think) remind us of the options before we dove into the deep end of the project. He showed us that Agile is where you have a roadmap plan, and structure where you can do multiple tasks simultaneously. However, some companies choose to do the 'Waterfall' method which is a linear set of tasks where each step is dependent on the previous step.

 He also showed us a video of a 'Naughty Dog' employee (Mark Cerny) who was doing a talk about pre-production and how sacred the process is. He talked about how there is a distinct difference between pre-production and production, saying that one is for artists, and one is for engineers. I agree with what he says but I still think that programming can also be an artistic process. The next step, he says, is to make a vertical slice of the game. Make it a completely polished, perfect, and playable but small part of the game. 1 level or 1 section. This makes it so that you can show publishers and customers what you're capable of and makes it easier to imagine what the final product will look like.

• voted on lead roles

I was tired and I bombed the speech. Won't happen again. We voted Dan to be the project manager. Dan is good with people but has very little game dev experience and low technical knowledge. However, I think that's fine because the Leads will help with that. Then I gunned for Stanislav to be the programming lead for a few reasons. He's a good programmer and a capable person with lots of games experience and He won't take it seriously unless he has a large responsibility. Last term he wasn't putting 100% in and it was obvious, tasks were done last minute and he quit the project to work on his pathway project 2 weeks before submission, I knew that he needed something to push him and it looks like the extra responsibility is the answer. This week he has been the most proactive and hard-working that I've ever seen him do before and we are well ahead of schedule rather than doing things last minute. He needed to have a stake in it and now he seems motivated. which is a good thing. Now I truly believe that the programmers have all their bases covered so we will succeed.  

• came up with a game idea

This was a bit of shambles. Honestly, the main brunt of the conversation was carried by Dan, Nathan and Miguel. Then there were bits and bobs from other people but like nothing from the designers. The main issue which we had last term, was that someone came up with an idea, we all nod our heads and then we pass that idea to the designers and expect them to design it. Harry, lead designer, told me that he didn't truly care about that game last time because it wasn't his idea and I fear that this might reoccur. We have to accept that not everyone will be passionate about the project and keep at it.

 The designers had almost 0 input so now they will be designing a game that they aren't interested in. Maybe it will turn out fine, but it's not how I would've organised the situation (based on experience).

• split off into subject groups

Stanislav did a cracking job, he came up with the different areas that we should be prototyping during the week and we were all able to complete them on time (spoilers!).

• made a TDD

As it turns out, Kristian's TDD was up to industry standard so we were able to copy most of his old one and agreed on different ways that code should be written.

• talked to the designers

We still didn't have enough information regarding design in order for us to get to prototyping, so we went over and had a short discussion about it.

• did my level-loading prefab task

My task was to prototype a 'saving and loading' checkpoint system. I would then eventually go on to cover save files. The first question I had to ask was "What data are we resetting and what data are we keeping when loading?". If we were only resetting the player, we would just have to teleport the player to the checkpoint on death like in 'Celeste'. However, this game will have enemies, puzzles, and objects which may need resetting which means we should probably reload the scene. One problem with reloading the scene for this is that we would need a new scene for each checkpoint which means we couldn't make such a seamless transition and we would have to have a new player object for each scene which would mess with other unknown variables.

 But then Alex said "Why don't you use prefabs?" and it suddenly came to me, an idea that would revolutionise the project, "Why don't we use prefabs?". Then, to reload a level we just need to destroy and instantiate it. The next logical question is "Where does the level spawn, and how do I make the transition seamless?". The answer was to have the level always spawn in the same place but teleport the checkpoint room to create the illusion of a large world. It works like a treadmill. This should result in an optimised level-loading system with the future of the project as the main priority.

Week 2, Sunday 29th of January

• Learned about marketing and publishing

Full disclosure, I was not present for the community session because I was at an event. However, I managed to make it back for the rest of the day and read through the slides about marketing and publishing. There appear to be 13+ lead roles in marketing which suggests how important marketing is to companies. You could have the best game in the world but with no marketing, no one will hear about it. A successful game is built on hype, people need to believe they want the product more than they actually do. 

If you look at 'Elden Ring' for example, dark souls fans from all over the world were looking forward to it for roughly 4 years. There was an entire youtube channel called "Elden ring news" which posted every day (for 621 days) to update everyone on whether the game has come out or not. This just shows the amount of hype surrounding the game and when the game finally came out, everyone bought the game, even people who never played a souls-like game before, old people, children, boys, girls, everyone bought it. So yes, marketing is important because if you can create enough hype, more than your niche target audience will buy the game just to see what all the fuss is about.

 Also, I've been looking into android publishing because I've made a game ready to launch. Seems like the main hurdle will be the Quality assurance test but after looking at some of the apps on the google play store, I'd say we'll pass with flying colours. 

• Did no programming in the lesson

I got back from the event at roughly 2 pm and I didn't have my laptop with me so I just chatted with everyone and got caught up with what's going on. Turns out we didn't have tasks because we were waiting on design to give us more stuff to prototype. Then Stanislav came over to us and said to "do whatever because we are waiting on design" so Kristian and I started playing games on the PC. 

Then we get to the main issue of a AAA company, communication. Apparently, someone reported us for behaviour? It needed to be communicated that we were allowed to slack off on Stanislav's orders but no one talked directly to us so we weren't allowed to express our thoughts on this. However, despite the visible slacking, programmers have been the best team so far, no doubt.

 Although, this does set a precedent. It means that if we slack off, it will be picked up on and we will be told off for it. I have faith that the system will work.

• Did plenty of programming at home

I did get some tasks assigned to me in the end. Puzzle mechanisms and activators. The job itself was simple and I could've chosen to do it the simplest way possible, but no. I decided to make this the best goddamn key-door system I could imagine. 

• Wire system

The first question was "how does the activator know what It activates?" one possible solution was to add a GameObject variable in the lever and the designer can just drag in the object that it activates. But then the question became "How does the player know what the activator activates?"  okay well you can do this with matching colours, symbols, or line renderers but I wanted this to be the *best* so I chose to do some research. 

After looking at both Portal and Minecraft, I decided I wanted to make a Redstone-like wire which shows where it goes, what it activates, when it's activated, and can be changed in runtime. These wires are a dynamic system that can be used in a multitude of ways and is easy for designers to play around with.  

You're probably wondering "How do the wires work?". Each wire prefab has both a receiver and a wire. The receiver checks if it's colliding with any wires, then It gets whatever signal that the wire holds and passes it on to its wire. This passes on a current in a particular direction. The key thing to note, a receiver cannot collide with multiple wires but a wire can collide with multiple receivers.

 Then, each activator has a wire with no receiver and each mechanism has a wire but no receiver. 

• Lever

The lever has a ball and a stick. Rotate the ball and the stick moves. When the player presses E, The ball rotates to either an On position or an off position.

• timed button

The button is a stick with half a ball at the top. Flatten the ball and it looks like a button press. When the player presses E, the ball flattens (On position), then after a set amount of time the ball un-flattens (off position).

• pressure plate

The pressure plate consists of a cube with a smaller cube on top. Flatten the small cube and it looks like pressure is applied. I made it a trigger and said if any physics object triggers it, flatten the small cube and activate it.

• doors and elevators

A cube. It goes up when activated, It goes down when deactivated. Did I just describe a door or an elevator? 

Week 3, Sunday 5th of February

We Kicked off the week with a lecture on Wayfinding. David_ACM talked us through different ways in which wayfinding techniques are used throughout AAA games to help the player navigate a large open-world game. As a programmer, I didn't find the lecture very relevant but I still listened despite this.

 Then, we all got together for a scrum meeting. I told everyone about my cool and modular wire system and they loved it. I received lots of praise for going above and beyond the tasks I was given.  The thing is, right, that I was given the most basic tasks. I was given the "keys and doors" of this project. Meanwhile, Harry got Enemy AI,  Kristian got the elemental shooting and Stanislav was doing FPS mechanics. I felt as though I was given tasks that were far below my skill level. To get around this, I devised the best and most modular "keys and doors" system that I could do, to prove that I am capable of more than what was given to me. I gave myself more work, then I completely aced it, and now we have a cool puzzle system for the game.

Then this week, I was tasked with expanding the system. I added AND gates, OR gates, XOR gates, and NOT gates which allow the designer to implement an array of logic systems in the games puzzle mechanics. In doing so, I incidentally removed the only limitation of the wires: the fact that the receiver could only be colliding with one wire at a time. I made it so that it adds the colliding wires are added to a list and then it goes through the list and adds up the number of positive signals that it is receiving. Then, if that number is higher than its minimum number of inputs, output a positive signal. This allowed me to make the AND and the OR gates. Then I used inheritance to create an XOR gate to make it so that there is also a maximum number of inputs.

 I was also tasked with making a trolley system which is essentially a moving platform that, when activated, moves through a number of points and back again. Then, when deactivated, stops moving. This was a fairly easy task and so I also added a line renderer that joins the dots to create a path.

 Something did happen during the Monday session which I felt was a point of contention. Last Monday, Kristian and I got caught playing games, because we had no tasks to do, and then it was brought up to Stanislav as a 'behavioural issue'. This Monday we made a point of working really hard and barely talking. Then, while we were programming away, Nathan(Audio Lead) comes up to Dan(Project Manager) right next to us and starts loudly talking about 'magic the gathering' for roughly 10 minutes before I decide to ask David, loudly,
"What time is lunch?" 

" about half an hour".

" so are you saying we should be working right now?" 

"well, yeah"

I'm not entirely sure if Nathan got the hint but he soon sat down and started to do work. The reason why I didn't just confront them is that it's not my job to manage their workflow, it's their job to manage ours. Then, I decided to bring it up with my programming lead in our meeting on Wednesday which is standard procedure. He brought it up in the lead meeting and the official feedback I received was to just confront them immediately. apparently, Dan would've stopped immediately if I'd said something. However, as I said, it's not my job. The way I see it, if they are going to bring up our behavioural issues, they should hold themselves to the same standard and lead by example.

Again, the actual issue was not a big issue, its the double standards and the fact that I'm not allowed to raise an issue.

 I honestly believe that our team is facing similar struggles and red tape that AAA employees face. I have learned how it feels to be a small fry in a big company where your opinion means basically nothing, despite being equals in many other ways.

At this point I'm sort-of giving up on the 'formalities' because it doesn't yield results. In future, If I have a problem with someone I'll just say it and work it out.

Week 4, Sunday 12th of February

Bit of trouble for the project this week. Dan, the project manager, had called in sick. This meant that we couldn't start the next sprint on jira because Dan needs to click the button or something.

The issue was that Jira tasks were all over the place. We didn't know what tasks to do or when to do them, and it felt fairly disorganised. It was a breeding ground for miscommunication because I had to have a back n forth with Stanislav (Programming lead) as to what tasks I'm doing, only for Harry Stott (design lead) to tell me that I shouldn't be working on those tasks yet because the design was pending for approval. If everything was on Jira properly, Harry would've been able to see what tasks I was assigned rather than unofficial, private discord messages. 

What have I done this week?

1. Cleaned up the code using inheritance.

I added an Output script which stores whether the object isActive or not. Then if it's active it does something. if it's inactive then it does something else. This means that whenever we add a new mechanism to the game I just have to override the doWhenPowered() and doWhenNotPowered() methods.  I also learned that you can override the update method and do base.Update(). This makes inheritance so much more useful for monobehavior objects.

2. Arrow shooter

For this, I used my new-found event technique from programming class. I made this object modular so that every ArrowHole object subscribes a ShootArrow() method to a ShootAllArrows event which is triggered when the object is powered. Also, as-per Design's request, it only triggers once when powered.

3. Hidden book lever

This was just the lever script but with a different contextual function. When "e" is pressed in range of the book it rotates as if it was pulled out of the bookcase and it turns on a wire. I made it look cool, though.

4. Custom Control scheme

On This one, I used a static class to store all of the KeyCodes of all of the controls. Then when the others are programming, they will use my class to access the different buttons. THEN, the KeyCodes may be changed in the settings at anytime and saved. To do this, I created a dictionary to link a string with a corresponding KeyCode and then I would have buttons that use that string to change the KeyCode to a different one. I got the first half of it done and made a working prototype but I still need to implement the save files.

Week 5, Sunday 19th of February

Okay, full disclosure, I'm writing this one a couple weeks late but this was certainly a week to remember. Each time that I do a task or project to my full ability, I end up really proud of myself. My tasks this week were to create the 'custom controls' settings and then the backend saving and loading (JSON Files) to accompany them and I have to say, well done me. At the risk of sounding egotistical, I did a pretty awesome job of it and I'm very proud of my work.

For the controls, I found a way of grabbing a list of all the keycodes of the keys that the user is currently pressing. I used this to grab the first input that the user pressed after selecting a key. Now, what can I do with this data?  well as it turns out, a keycode is an enum which means you can use it like a data type. This means that I was able to create a dictionary that associated the name of an action (e.g "moveForward") with a keycode variable (e.g KeyCode.W). The dictionary was so that I could pass a string into the UI button responsible for changing the control, and change the according keycode. Next, I assigned each control from the dictionary to appropriately named keyCode variables (e.g  crouch). Using this, programmers would just have to access my static controls class to retrieve a keycode instead of unity's input system (e.g if(Input.GetKeyDown(controls.crouch))).

 But wait there's more!  I was also asked to implement unbinding keys and restoring keys to default. To unbind a key, I just made it so that if the player presses the DEL key while trying to bind a key, it will set the key to "KeyCode.None".  For restoring the keys to default, I created a dictionary which paired up the name of an action with the hard-coded default key. Then, when the player is trying to change the key, they may press backspace to restore that key to default using the string passed from the UI button. I also created a "Restore all to default" button  which goes through all of the keybinds and sets them to default.

That was the smart bit, but now comes the tricky bit. Saving and loading. At first I figured I would just do the same method for saving and loading that I had always done, using a function to convert a c# class to a JSON object. However, I was storing the keybinds as a dictionary but function couldn't format a dictionary into JSON text. So what are my options?

1. store keybinds as an array, then convert the array instead. However this means that it can get messy if we decide to add more keybinds later on. we would have to manage the order of the array using numbers which can increase the likelyhood of making a mistake(e.g moveForward = array[1]) as it is apparent which key is where.

2. stop using JSON and find another way to store data in the persistent data path. Its a possibility but it seems like this will take the longest to figure out and may not be worth the result.

3. convert the dictionary into two lists when storing in the save file, then convert those two lists into a dictionary when loading from the save file. Essentially nothing changes with this solution as I'm still working with dictionaries(e.g moveForward = dictionary["moveForward"]) and it means that adding a new control to the dictionary will automatically update in the save file.

As you may be able to tell, I chose to go with number 3. This gave rise to another brilliant idea of mine, where I was able to make it easy for other programmers to save and load data. What I did was make a dictionary for each data type and did the same thing I did with the keybinds. Then I made a function that takes in a string and some data then checks if the string exists in the dictionary. If it doesn't, then it will add it to the dictionary, if it does then it will update that key's value. The end result of this means that programmers can write:

And this will dynamically save whatever's contained within the dictionary.  This currently works for floats, bools, and vector3

Programming is cool and all, but what have I Learned about AGILE methodology?

1. I have to make modular code that accounts for every possibility as I don't know what the future may hold regarding the big picture of the project.  I have to accept that those pesky designers will come up with new stuff and therefore I have to keep my code structure flexible.

2. I need to keep making new branches when prototyping a new feature so that people can still be testing in \main. I'm also being careful when merging the branches so that I don't delete other people's work.

3. I need to be constantly updating Jira when doing tasks so that the leads can keep an eye on progress and scope the project accordingly. 

4. I need to be sharing information and logging things on confluence (such as prototyping videos and known bugs) so that my team members have some insight into what's going on with my work-flow

I hope this ticks the boxes, sam signing out.

Week 6, Sunday 26th of February (reading week)

okay so this week is technically a reading week, meaning that we don't have any on-campus lectures. We had a meeting on Monday in a Discord call and we went over the overview of the project. I had very little input in this meeting and there wasn't anything super interesting to talk about so i barely remember it.  Then, we were expected to have a programmer meeting at some point this week to organise what we're doing but Stanislav never called a meeting. Long-story-short, I didn't do any work for the project this week. On Jira my only task was to create some level-loading triggers but that consisted of basically nothing so it wasn't worth doing, especially since level design wasn't complete yet. Now, you might be right in asking "why didn't you just ask for more work?" but the answer is simply "I didn't want more work". I had worked so hard the previous week that I was burned out and didn't feel the need to request more responsibility. On top of this, I had some general depression which aided my procrastination.

So those are my reasons and explanations, many factors that go into it but next week those factors will not be present and I will be back to my old self in no time!

...

...

Well I didn't do much so what can I really put In this blog?

I CAN PUT MORE ANALYSIS OF AGILE METHODOLOGY. I did barely any work all week right? So this means my manager and the project manager need to have a word with me and discuss 1. why I didn't do anything and 2. What I can do to make up for lost time. However, I didn't receive any messages asking for updates and I didn't have to give an explanation when I informed them that I hadn't done anything. The central point of failure in an agile structure like this is the managers since they are also the central conduit for responsibility. Employees get paid to do their job but if they don't do their job, employees get paid for no reason. To address this issue, the idea of a manager would be invented to make sure that the employees do their job and if the employees don't do their job it then becomes the managers fault. This means that someone will genuinely care about whether the job gets done since they can solely be held accountable. However, in this case, there is no accountability placed on 1. The employees, 2. The subject leads and 3. the project manager. The only consequences are the uni grading system and the games quality is hardly reflective of that. This means that employees can get away with not doing their job because managers can get away with their job which means the project manager can get away with not doing their job. All of this means that no one has to do their job because there is no tangible incentive or accountability system.

We either needed more authority or more shared responsibility. You can't have a structure like this without authority, it doesn't make sense.

Week 7, Sunday 5th of March

 After a week of absolute SLACKING, I am back on the ball and ready for anything! I turned up late and missed one of Alex's lectures which means I felt amazing compared to my peers. As I got In, at midday, I had a chat with a couple of my classmates who were feeling pretty down considering the progress of the game and they were really finding it hard to see success. I (with an untouched positive outlook) reassured them that we have got plenty of time to get back in the game, put our thinking caps on, and make a half-decent game.  I'm really starting to get into this. 

Speaking of 'slacking', the team has been noticing a serious decline in work quality coming from the design team so I decided to do a bit more digging as to "why?". It seems to me that Harry S is storming ahead and working all hours (on both his pathway project and this group project) and it looks as though john is being dragged up with him. Harry is teaching john the ways of dragging and dropping other people's work into a unity scene and overwriting bug-fixes in plasticSCM. all jokes aside, Harry and john are doing amazing, despite a lack of experience. However, James L appears to be completing all tasks assigned to him which then leads me to believe Harry isn't setting him enough work. When I asked about this, Harry said "I thought he had enough work to do" but James was exclaiming "give me more tasks!" James is a good 'employee' but not going above and beyond which means he won't be gaining experience at lightning speeds. Continuing the 'design Audit 2023', I'd like to outline what's going on with Justin and Shakir. They simply don't do anything. By the looks of it, they both seem to have personal reasons as to why, but this doesn't bode well for the design team. From the results of my Audit, This is not a motivation issue for the design team. This is a Manpower and experience issue and with this in mind, I would say they are doing a top-notch job. 

The whole point of Agile, in my opinion, is to be ready and flexible for any situation. I feel like the current situation is that the design team is understaffed and that the team structure and scope isn't adapting to this. What I would suggest is letting programmers and artists help with implementation as things are being created so that designers don't have as much work to do. However, this sort of decision is out of my hands.

Now then, time for the technical side of things. What have I done this week?:

• Implemented reloading from checkpoints into the demo

I dragged in some box colliders that saved the game into the scene. I reckon Harry just didn't know how they worked just yet.

• Load the Next Room and unload the previous room triggers

I've got a list of objects that contains the "Rooms" objects and then a counter which tracks the rooms you are in. this then turns off the previous room and loads the next room.

• implemented art for wires and lever, then I reimplemented the wires in the scene.

This task was particularly frustrating. my job involved finding the mesh of the 3D model oddly named "pGear1" to the wire and then resizing the wire and its accompanying hitboxes to fit the mesh. However, this caused a problem where all the wires in the game had now shrunk to a microscopic scale. Usually, this wouldn't be a big deal but I was a dummy and was working in /main and had pushed changes. I was then tasked with fixing my mistake by reimplementing the wires.

• Merged UI into main (also created pause menu UI)

As it happens, Sam Brent was not able to merge his pause menu to the main branch either through a lack of trying or technical issues. I was then tasked with helping him so that I could implement my control settings with the main game. However, when I looked at his code it was a programmer's worst nightmare. repeated blocks of code, two-letter variables, drag-in variables, the lot. despite this, I still wanted to use his implementation to make him feel useful and to ensure his grade reflects his work. However, the pause menu straight-up didn't work and I didn't know what/where the problem was. When I told Stanislav, I came to the conclusion that I should just redo the pause menu and implement my control settings along-side it because it wasn't worth messing around with Sam's system.

• introduced a "reload save data" function to reset checkpoints

Harry Stott raised the issue that he couldn't playtest the game from a fresh new save without deleting the save file. Each time we press play, it loads the player to their last checkpoint which means playing the game from the beginning was impossible. I tried multiple ways to implement the "clear save" function. After lots of testing, I figured out that the problem was that the save file takes a while to delete and this caused problems to do when creating a new file. Then after trying to fix this issue for a while, I gave up and decided to find a different angle. Instead of deleting the file and making a new one, I opted to just clear all the data like this:

        saving.floatDictionary.Clear();

        saving.boolDictionary.Clear();

        saving.v3Dictionary.Clear();

        WeaponElementController.elementOne = Element.ElementType.WATER;

        WeaponElementController.elementOne = Element.ElementType.FIRE;

        saving.instance.save();

        OnLoadLastCheckpoint();

• Now you cannot shoot and move the mouse when in the pause screen.

I made isPause into a static variable so that we can restrict certain actions while paused.

Week 8, Sunday 12th of March

Time management. Work ethic. Skill. These will be the things that make or break the project. As a new initiative, we were told to log our available hours on confluence. This gave me the unique opportunity to sort my schedule out and allocate some time to this blog and my personal pathway project. I decided to do group work majorly on Monday, Tuesday, and Friday and minorly on Saturday, and Sunday. This meant I could spend Wednesday and Thursday on my own stuff. This week I made an active effort to stick to my schedule and it went pretty well. On Tuesday, Stanislav asked me if I could get the Ammo prototype done by Thursday, but since I'm not working on the group project Wednesday and Thursday, I said no and he set it for Friday instead. No harm done. I think people shouldn't be scared to reason or bargain with their boss. Typically in a workplace, you need to look out for your self-interests because your boss won't. Your boss' goal is to get work from you as fast, as cheaply, and for as long as possible. Therefore you need to make sure you have boundaries to protect yourself from being taken advantage of. Now, obviously, Stanislav isn't our actual boss and there is no money/firing in play but since we are treating this like an actual business, we need to put the same boundaries in place to ensure everyone's well-being. Also, I will reserve my right to refuse to do extra work, but I am not going to let my colleagues down so I will do extra work if needed.

• created settings UI and functionality

So Sam Brent's other tasks were to create settings and functionality for the pause UI. However, his code was a mess and didn't necessarily work again. I said it would be much easier if I just remade it. Sam was thanking me and seemed amazed at how I did it. He acted as though I just did 8 weeks' worth of work in one night but it really was that simple. I don't understand how it took him so long to half-do those tasks. Needless to say, sam no longer has any tasks so im not sure why he keeps asking questions about framerate settings. Its really awkward because we can't tell him to do nothing and we can't fire him nor can we rely on him for anything important. The main problem is that he actually appears to have high work ethic so we can't even say its his fault. We just have to keep giving him null tasks I guess?

To change the resolution its simply Screen.SetResolution(width, height, screenType);

To change the volume its just AudioSource.volume = volume;

To change brightness I did Light.intensity = light;

To change Fov its camera.fieldOfView = FOV

you get the idea, all of these settings are extremely simple to implement so I don't see what he did for 8 weeks. Now you might be thinking, maybe the code is simple but the method was hard to find. no, each of these was the first thing on google. I had no idea you could set the resolution before I googled it.

• saved and loaded those settings

Using my efficient saving and loading system I just saved the values from the UI elements and loaded them in the Start() method.

• created prototype for ammo

In a separate branch, a cursed one, I added some UI on the screen to show your ammo. Then I added a new variable to bulletData which is AmmoPerShot so that each element can have a different ammo cost. Then I used Kristian's very modular and cool code to make the ammo counter go down when shooting. I made sure to include a maximum and a minimum ammo value. I also made an ammo crate which, when touched, gives you full ammo. Sadly, I don't think this feature will be used but the prototype is there none-the-less.

• created the activated enemy

These are enemies which have their Main script turned off, then when they are connected to a postive power source, it turns the script on which activates their AI and health. 

• saved the latest elements used

Week 9, Sunday 19th of March

This was not my proudest week but I managed to get more done than I thought I would.  The Monday's session was good, In the meeting, I brought up a few good points regarding enemy design. I felt the enemy's design had been neglected for 7 weeks and that Harry Crossman was just left to his own devices for too long. As it turns out, it seems as though stanislav did already bring it up in the manager meeting and had taken over the design of the enemies. I also mentioned to the programmers how Harry C's main class for the enemies was not good enough to be used on all of the enemies. There were many methods and attributes that wouldn't be used by all of the child enemy classes. There were also a lot of drag-in variables that designers had to set when placing them in the scene. In hindsight, we should've had another programmer check Harry C's code/progress because it seems we neglected it until it was too late. Now we have to use this class and it isn't up to a good enough standard. On this front, Stanislav and other manager's are virtually silent throughout the week which is part of the problem.

Also, the night before Monday, Nathan was telling me and Harry S that he was swamped with work but that he's "got meetings all day tomorrow". I was interested in this and decided to watch him during the Monday session since his desk is so close to mine. We had the big group meeting for 10 mins, then Nathan had a manager meeting for 30 mins, then he argued with john about story for an hour. They agreed to disagree and john suggested that Nathan writes some dialogue to show him how its done. Then Nathan watches youtube for 20 minutes and now its lunch so I leave. After lunch he writes a line of dialogue then gets up and starts talking to people for an hour or so. Then he sits down and starts cutting out his paper 'Magic The Gathering' for another 30 mins while eating cake or something. Then, he writes 5 more lines of dialogue and goes back n forth between cutting cards out and talking to people at the other side of the room. Now go to his blog and see what he said he did during this day, he's very good at making himself sound more proactive than he is, which is maybe why managers haven't caught on yet. Maybe I didn't see it but I don't believe he did any audio work the entire day. This wouldn't usually be an issue but I was told that he can't do work at home for technical reasons but if that's the case, he should be spending 100% of his time making audio assets. We currently have 5 audio assets in the project files and on confluence, it says there are over 30 to do. I'm not a manager, and I'm not in charge of Nathan but at this rate, if something doesn't change, it would be a dream to get the necessary audio assets in time and to a good standard.

Another thing, I had a horrible case of food poisoning which made me violently ill all night on Monday-Tuesday. I felt pretty bad on Wednesday and started work on the support enemy on Thursday.  

 Support enemy. 

This is an enemy that runs away from the player and casts bubble shields on enemies in line of sight, which protect other enemies from specific elements. 

1. I started by giving all the enemies that can be shielded a script called canBeShielded.

2. I got all enemies that have canBeShielded and put them in a list.

3. Then I got those enemies and did a ray cast to each of them to see if they were in the line of sight.

4. I got those enemies and tried to apply a shield to a random one

5. if its already got a shield, the shield fails

6. on success, it adds the enemy to shieldedEnemies, and adds the shield to Beams.

7. for each enemy, get the beam, and draw a line between the enemy and the support enemy.

I managed to get this part working properly however I struggled to get the enemy to move to the furthest point from the player in the room. Currently, the enemy is repulsed by the player. I also didn't get around to making the bubble interact with bullets yet.

Week 10, Sunday 26th of March

Support enemy scrapped

 It turns out that the support enemy, which I was working on most of last week, was scrapped from the game due to scoping issues. I knew about this suggestion beforehand and pushed Harry to suggest it to the other managers as I strongly agree with this notion. Not only was there a lot to finish with this enemy, programming-wise, but there would've had to have been a lot of work for art (Model, UV, Textures/Materials), audio (situational sound effects), Design (strategic enemy placement) and Stanislav (Fresnel shader for shield and beam). This takes a sizeable weight off of my shoulders and means that I can focus my time on some of the game-breaking issues running rampant in the game. A blessing in disguise.

 Backtracking issues.

 This is a general term because there were lots of issues with the room-loading system when Harry unexpectedly introduced backtracking into the game. Near the start of the project, when I first saw the level design for level 1, I said to Harry "Have you thought about putting backtracking in the game?". He then proceeded to get defensive and was strongly against the idea. When I asked why, I was met with "Stanislav said so". I took this as a "definitely no backtracking in the game" notion and then when I designed the room-loading system and the checkpoints, I had no intention of allowing backtracking. I was assured that "we will make debris fall and block the player from turning back" or "we will have doors lock behind the player" but now there's a U-turn so I will have to adapt the system to accommodate this.

• checkpoints don't turn off so players can collect them twice when backtracking

I was hoping for a two door system (or something equivalent), like in portal, where you enter a room, grab a checkpoint, exit the room and the door closes behind you. However, with backtracking, this is not going to be a thing.

• enemies turn back on when you re-enter the room

again, if you couldn't re-enter this room then this wouldn't be a problem.

• levers and physics objects don't save when you die or reload to your checkpoint

if you open a door with a lever or crate, that lever or crate will be reset on death and therefore the door behind you would close.

• collectables will reappear on death.

Progression system.

It was clear that I had to find a way to get rid of all these issues with one clean system. two birds one stone type deal. With the progression system, I can save where the player is in relation to the progression of the game, then turn on or off specific objects based on the progression value. The player's progression is incremented and saved when they grab a checkpoint, so we can track which objects should be on or off based on its nearest checkpoint

if player's progression == object's progression

• turn on object

else

• turn off object.

This means all the designer has to do is set the progression of all the checkpoints to go from 0 - 10, and then set an object to the progression value of its next checkpoint and it will set active as the player captures the previous checkpoint and turns off when the player grabs the next checkpoint.

 separated progression/gameplay saving from settings saving.

One issue I noticed us having was that we had two conditions for saving but one save file

1. when the player captures a checkpoint, saves the player's position and progression.

2. when the player applies settings, saves the player's settings.

I once-and-for-all decided that it would solve a lot of my problems if I just made it two separate save files. Settings for fully persistent data that does not reset when you die or reload the scene, and JSONSave for gameplay-relevent data that only saves when you get a checkpoint.

 programming-wise there wasn't anything too smart but it was a lot of work and it was fairly impossible to debug.

 saved the lever's state and physics object position.

 This one was so tricky that even the legendary David_ACM couldn't seem to figure it out. I will now go through the limitations of the puzzle.

• JSON files can't store game objects

• there are multiple instances of these objects

• designers may add more of these instances to the scene

• these objects must be parented to the room that it's contained in

• no excessive or complex work on design's side of it as they may make mistakes.

• no editor-only code

After lots of deliberation and discussion, I nearly gave up. Then, I noticed that the only truly persistent data that I could reliably draw upon was the name of an object in the hierarchy. I coupled this with my existing saving-loading system and used the object's name as a unique string to save the data. Then all design had to do was name every lever and physics object uniquely and its all good. 

I also added a Debug.LogError and UnityEditor.isPlaying = false to kick the designer out of play-mode and log an error telling them if they mess up the naming convention.

Room loading.

 Currently, the issue is that Harry S is using the turnOnOrOff script to load and unload rooms. This is a trigger that contains two lists of objects, a list of objects to be turned on and a list of objects to turn off. One issue with this is that he is dragging in two rooms that turn on and 14 other rooms that turn off and this is crazily inefficient when it comes to implementation. Another issue is that there is nothing saving this, so when the game reloads, the rooms all turn back on too. I solved this by making a room loading trigger where all the designers need to do is drag in the rooms that turn on, then all the other rooms automatically turn off. Then, it saves and loads a list of integers, which store references to the turned-on rooms, in a JSON save file.

 Replaceable wires system. 

There are fixed locations where wires may be placed and unplaced.  The player picks up wire pick-ups from the ground or from defeating enemies. The player may only hold 1 wire at a time. If the player looks at a wire point (found by doing a raycast)  while holding a wire, the wirepoint will change colour. If the player presses the interact button during this time, the wire is placed. if the player is looking at a placed wire and is not holding a wire, the wirepoint will change to a different color and the player may press the interact button to pick it up.

 I am so proud of the versatility of my wire system, half of this wouldn't be so easy if not for a few good decisions at the start of the project.

Week 11, Sunday 2nd of April

Morale is low, the managers (aside from Harry) aren't being very responsive during the week, and some team members are hard to reach. The project contains plenty of "unsolvable" bugs, the audio is not in the project yet and Harry is trying to implement wall textures despite sizing issues. Despite this, we need to keep going and get this done. 

THIS WAS A CALL TO ARMS FROM A FRIEND IN NEED! Harry was starting to get anxious about the progress of the project when everyone else started disappearing. I took this as a huge smack in the face and decided to get all of my tasks done over the weekend so as to make Harry feel better. From this point forward I was determined to complete this game regardless of the cost to myself or my other grades. We were in it together. Myself, Harry and Kristian went into hyperdrive when times were tough. 

The main issue with Agile methodology is that a lot of responsibility is placed on the management and therefore if the management is unresponsive or inactive then the workflow will reflect that.

 This is what I did over this weekend: 

wire pickup visuals 

Made it look like the player is holding a wire when holding a wire.

levers and buttons activate from looking. 

This was long overdue. I did this with a raycast going from the players camera in the direction of camera.main.transform.forward. This detects if the player 

Can activate levers with earth.  

For this, I had to delve deep into Kristian's implementation of elemental hit detection. After asking questions and poking holes, Kristian had to rework this system to account for more objects to be interactable. I then just had to make input a subclass of hittable which allowed me to detect which element the lever was hit with.

Enemy drop system. 

Since dictionaries cannot be edited in the inspector I chose to use two lists. There is a list of objects that may or may not drop, then there is a list of percent chances that each object can drop. Then there is a for-loop that goes through each object and decides whether to instantiate it or not using its corresponding chance value. This all happens on enemy death which is detected using the OnDeath event on the enemyMain script.

Saving and Loading unlockable elements and combined elements 

Anything that involves looking into and adjusting someone else's code adds an extra mental hurdle to the task. However the task was just daunting rather than actually difficult. All I had to do was create a new list of unlocked elements and then inject a few lines of code into the appropriate places. This taught me that we shouldn't be scared to read and edit someone else's code because its mostly stuff that we can understand if we follow the code logic and look up the appropriate documentation.

made arenas randomize which order the enemies spawn in 

I looked up an algorithm called the "Fisher–Yates shuffle" and it worked like a charm. Any Questions?.... This is a top tip, If you're trying to do something difficult yet unspecific to your code, there will likely be an algorithm or solution already out there. Just google it.

activated objects script 

In order for Harry S to have more work-around options, I created a wire receiver that, when powered, turned on [x] Objects. I also added a boolean that decided whether the objects turn off again when deactivated or if they stay on forever after.

 fixed progression system with death 

This has been a thorn in my side for a few weeks now. When trying to add a feature involving save-files, you have to think in the 5th dimension. There are different circumstances that do different things when it comes to saving and loading.

1. Reloading the scene

2. dying to an enemy

3. Reloading save data

4. Entering and Exiting play-mode

5. making a build + 1. 2. 3. 4.

6. closing the application and opening the application

In each of these scenarios, the progression system could either work or not work. I discovered that the main cause of the issue was that i was loading the file in the Start() method but setting the progression in the Awake() method. This meant that the progression value was always set back to 0. something like that.

What did I learn? 

That sometimes in a AAA company, it's not only the managers that are responsible for others, but that we all need to be responsible for eachother. If we notice someone having a hard time or not doing work, we shouldn't say "its a manager's job to talk to this person" maybe it's up to all of us to check on each other and help out where necessary.

Week 12, Sunday 9th of April 

Following the aforementioned Call To Arms, I was ready and raring to go. One small hiccup, Stanislav couldn't think of any tasks to give me. At first, I was glad to have some time off but then I realised that there are many issues in the game and I should help to solve them. I then began a dialogue with the project manager to see what I could do.

 I said "lets look at the project as a whole. Is it finished?"

"far from it."

"Well then there must be something to do"

"The enemies are the biggest issue so far but Harry C's working on them"

"Do you trust him to get it done?"

"No", "Stanislav, do you think Harry C can get the enemies done in time?"

"No"

"I'll do them then, I'll smash it out in two days, easy."

"Yeah you're on enemies now"

I know I just signed myself up for a TON of work but this was one of the many vital and difficult decisions that the project manager is supposed to make to ensure a successful project. I pushed for this decision this time as it was programming related but there were many other times when difficult decisions were not made. Some of it was design, some was art, and some was music but all those decisions had contributed to this game's many issues.

I will discuss these at a different time but for now, I took over the role of Enemies. I decided to recreate the the "main" class to make it more modular, clean, efficient and easier to use for designers. 

The small tasks.

Enemy jump points 

Unity has an "off mesh link" component. I made two empty objects with this component and made a prefab. That'll do.

Enemy drop expiry

Made enemy drops delete after the specified time. If time is set to 0, then this doesn't apply (for pre-placed drops)

Vacuum range and random velocity on enemy drops 

On start, the drops move randomly. If the player is within range of the drops, they move towards the player. 

Recreated 4 of the enemy types, the enemy main class, and edited the superconductor. 

To modularise the system, I made the EnemyMain class only contain methods and attributes shared by all enemies, then I created three scripts based on commonly used behaviours. 

• moveTowardsPlayer

• shootAtPlayer

• strafe

• shoot barrage

I made it like this so that the ranged shooter can have shooting, the beserker can have moving and the gunner can have both moving and shooting. I also wanted it so that designers can make any enemy strafe (which is a child of moveTowardsPlayer) or shoot a barrage(subclass of shootAtPlayer)

Any specific features (such as exploding, charging, or flying) or specific weakpoints (propeller, element core) should exist on a new subclass of EnemyMain.

Ranged Shooter

These guys shoot at the player but I adjust the enemy's aim based on how offset its gun is. 

Melee Beserker

While he does have the moveTowardsPlayer script, the Berserker script is responsible for the charge ability and attacking. I created a simple finite state machine. Attack <--> idle <--> charging. And I basically followed exactly what the designs said.

Ranged Gunner

This has the strafe script. I went through many different ideas and algorithms before I found this one.  This makes the enemy seem like it actually has a brain.

Elemental Core

This is an elite enemy and behaves like one too. It charges up and shoots the player with a barrage of bullets. for this, I made the gun randomly offset everytime it shot a bullet so that the bullets come out at random angles

Note: Harry C had been working on this for 11 weeks and I did the enemies from scratch in 2 days. In addition to this, There are no game-breaking bugs with these ones and the code is more modular. This is not a humble brag, just a straight-up brag, because I'm extremely proud of my work.

Week 13, Sunday 16th of April 

This week I've been fixing some major issues that have plagued the game since the start that no one's been willing to fix. 

1. Steam now pushes crates

2. Crates get pushed properly by water now. The issue was that the projectiles spawn from the muzzle of the gun and move toward the centre of the screen. This means that the water hits the crate from a weird angle. To fix this, I moved the "muzzle" to the centre of the camera. 

These bugs were really annoying. Despite them being someone else's jurisdiction I still decided to fix it.

 Also, I'd like to talk about some issues in the game that could've been circumvented by good decision-making. Now you might be thinking "Hindsight is 2020, I'm sure they made the best decision given the information they had at the time" but no, these were decisions that weren't made due to poor planning and a lack of confidence.

1. Two-door system. In order for room-loading, enemy spawning, and puzzle completing to work simultaneously, there needed to be a small two-door intermission in between sections. Technically this is the best solution for a seamless transition between rooms, separating combat from puzzles, saving + loading, and progression tracking. However, Harry S said that it "Looks Weird" Which caused a lot of issues and workarounds.

2. Backtracking. It needed to be more certain from the start whether backtracking was going to be a thing or not. When I asked Harry S if backtracking was going to be in the game, he said "No, absolutely not" and when I asked why he said, "Stanislav ranted about how bad it would be to include in the game, I feel like I have a gun to my head". I should not have taken this as a good reason but at the same time, I understood what he meant by this. Needless to say, he changed his mind which meant that all the puzzle mechanics, level design, enemy spawning/AI, checkpoints, collectibles, and element unlocking had to now change to accommodate backtracking but if we were more decisive about this from the start, we would've set the systems up in a different way.

3. Ammo. This is less of a technical issue and more of a design issue. They were unsure whether they wanted ammo or not to balance the more powerful elements so I started prototyping it. While prototyping I thought "What happens if you run out of ammo while doing a puzzle?" and my question was met with "We'll cross that bridge when we come to it". After several weeks, I had assumed that ammo was purged from the game but then I get a message from Harry S "What happened to ammo?". Then it dawned on me, they probably hadn't balanced the game for ammo and they probably hadn't solved the issue with puzzles. We then had to do a quick compromise of "infinite ammo drop points near puzzle bits". Good enough but not great. This should've either been purged from the game or constantly worked on.

4. Unlockable elements. I had a bad feeling about this. I felt as though experimenting with the different elements was part of the unique selling point but then they cut the number of elements you can use in half, making it harder to experiment with them. This is another moment where I think "If I was at the manager's meeting table, I would have more of a say". Despite the core concept having issues, it would've been fine if the player unlocked the elements in short succession of each other. However, they decided to put earth (also unlocking lava & mud) all the way in level 2 which is about 20 minutes into the game. Design-wise it was weird but not terrible, the consequences carry over into my next point.

5. Level 2. We needed to cut level 2 or assign more people to it. Any open-eyed project manager would've seen that we had over-scoped since there were only 2 people placing things in unity. either programmers and artists should've been more active with level design or we should've scrapped level 2. So why wasn't it scrapped? Three new elements and three new enemies were introduced in level 2 and people were so attached to the idea of having these features that they didn't even dream of scrapping it. However, if someone had the guts to say "We don't have the man-power for this, let's move earth unlock to the dining room and introduce the three enemies in the three following rooms, then make those rooms slightly bigger" but sadly no decisions were made. He didn't even say that we were able to do it, there was no comment on the scope.

6. Art implementation. Ideally, the art implementation should've happened a LOT earlier. Many assets didn't make it into the final game because programmers needed time to implement them, time which they didn't have. Maybe it would've been better to make something and implement it as you go along rather than squishing it in right at the end. Someone should've been keeping an eye on this and acting accordingly. At the end of the day, this is one of the core jobs of management which just wasn't present.

7. Audio Implementation. The same thing here. As soon as an audio asset was ready, it should've been implemented into the game. Also, I know that there were issues with Wwise implementation but there should've been a better way around them rather than just cramming everything into the end.

8. Work ethic. What to do with people who don't work? Although there was no punishment system that could be administered by pupils, there should've been more clear decisions regarding what to do with people who don't work or cause issues. Whether they get a lecture, lose their tasks, etc, there should've been something in place. At the very least, there should've been more interaction from the managers to make sure that everyone is working (especially during the Monday sessions). Just a message saying "Hey what are you doing right now" or a "How's progress?" we pretty much only interacted during Mondays and I think this left a huge gap in efficiency. Don't get me wrong, boundaries are good too, but too many boundaries allow for people to get lazy. When I had my week off in the reading week, no one contacted me or cared.

That's just to name a few. As I said, these problems aren't just visible from hindsight, I had knew that these were problems but I didn't have the power to solve them. This is just proof that I was right about these things which makes me think I would've been a good manager. 

OH WELL, WHATS DONE IS DONE.

Week 14, Sunday 23rd of April 

With the final week closing in on the deadline, there has been a rush of final bug fixing and finishing touches. Stanislav is juggling his blog with audio implementation while Harry S is struggling with navmesh stuff. Despite the fact that my work is done and that there's no more tasks left, I decided to stay in contact and ensure that the project gets onto itch and that everyone gets credit. I had a bad feeling about Oliwia working on the itch page since she has a history of not linking people as a contributor, therefore I sent a quick message to Dan. As well as being project manager, he's also an artist so I trust him to do a good job of it.

Aside from that, its going fairly chill. I'd now like to reflect and say what I thought about this whole process. 

It stumps creativity

I believe that the process has been more about production and meetings than it has about creativity. The design was quite bland and aside from the art, nothing made me go "Oooh thats creative/unique/cool" (aside from my wires ofcourse). I feel like people didn't want to get silly or embrace their creative freedoms because of the pressure to make a good game. It seems like most of the process was just doing the process for the sakes of the process. Like meetings about meetings regarding meetings. For me, this is not what game development is supposed to be about. Here's another question, How can you expect someone to have fun playing the game, if you didn't have fun making it?

Its slightly elitist

The separation of manager and non-manager was a problem. Some students placed them on a pedestal, some managers thought that they were better than others, some students thought that some managers thought that they were better than others, and some students blamed some managers for every issue. This brought resentment, competition, and communication issues. While you could argue that these positions shouldn't have existed, I would say that we just needed a bit more equality. For example, if all information was shared properly, if we had the same permissions on collaboration software, if it was possible to earn your way into the manager meetings etc. I agree that we needed managers, but the idea of them being superior in any way is wrong. Instead of thinking of it as a pyramid, I think of it as just another job role. Art, Music, Programming, Design and Management.

The weirdest thing is that Nathan was a manager, despite being a team of one, and this meant having a seat at the managers table and having his Ideas heard. I thought that was weird, especially when he doesn't discuss audio related things. However when I try to have an input they say "its a manager meeting, stop talking". bit odd.

Jira is brilliant, but only if you keep up with it

Jira was a really good project management software because it meant I could just complete the tasks right in front of me and move on yet also have all my future tasks planned in advance. However, at one point I had to make my own personal list of tasks in a notepad file due to my manager not being able to add everything to Jira. At that point, I had invisible tasks that other people weren't aware of and it got confusing as to what I was doing at any given moment. At one point I had Harry S add loads of tasks that I had done which weren't officially on Jira. Also, when I absorbed Sam Brent's tasks, those tasks were still assigned to him, and looked like he had done them. While Jira was brilliant for the most part, people forgot to purge and remove tasks. At the end, I had loads of tasks that were purged so it looked like I had loads. So In conclusion, the software was brilliant but issues were caused by the people who used it. 

education or lack there of. 

This is a two-parter. People were grouped together, then told to assign managers, then we were told to just make a game. While we were supervised and advised in some areas and there were lectures, it felt as though we weren't taught how we should function as a team or the best way to work. It was like David just watched us and didn't interfere as if it was an experiment. Maybe that's the teaching style, maybe we are supposed to learn via trial by fire, but I think we had lots of game design lectures (like the one about backtracking) when we could've had some insights into how to run a team.

 Part two is less subjective. Only the managers got taught how to use Jira and Confluence properly. It feels like they had a completely different education from us which is annoying because we didn't get a choice in the matter.  This meant that if we needed to add a task or change something, we had to guess how to do it. 

Despite this, I think the trial by fire worked. I have learned a LOT from this whole experience. The best thing it taught me was that I don't ever want to work in a AAA company, but if I did I'd be the employee of the month. 

Incentive and punishment

The only incentive and punishment is the grade given by ACM but most people believe that they just need to write the blog and pretend to do work to get a grade. This means that there is no real incentive or punishment which therefore means that people aren't motivated to go above and beyond or even do the bare minimum.  I'm convinced that The only people who did lots of work either believed they needed to for the grade or they have some other motivation (pride, competition, artistic passion, peer pressure, etc.). For a structure like this to work there must be some kind of incentive to work harder.