Sam's Weekly Blog

TEAM:

John - "Story" Designer

Shakir - "Level" Designer

Harry - "Gameplay " Designer

Sam - Programmer

Stanislav - Programmer

Angie - Artist

Bari - Artist

Miguel - Artist

Launcelot - Programmer

Week 1 Sunday 2nd October

Discussion summary:

 Brainstorming has finally kicked off and everyone is ready to suggest their ideas and get to work. The process at the beginning was quite repetitive, someone would suggest an idea, we criticize the idea, we take a vote, and we reject the idea. We started by identifying which game genres we didn't want to develop. I said no to Horror, Angie said no to shooters, etc. 

Then, we remembered that Bari was really good at 3D modeling which is a resource we ought not to waste so it sparked the conversation about doing a 3D platformer. We went through the repetitive process again until someone said something about mixing 2D and 3D in a paper mario-esque style. 

This led to further discussion about dimension switching and the movie "Everything everywhere all at once" and we finally decided on an idea. 2D puzzle platformer with the core mechanic of dimension switching. 

The story was yet to be added because we agreed that Jon would create the story but he was in Greece this week.

 What I did this week: 

I created a quick prototype from that showcased the integration of the dimension-switching mechanic with Unity tilemaps and Identified some problems which may arise later. One problem was "what happens if the player switches and gets stuck in the wall?", the answer harry gave me was "the player should die"  but also, how do we detect the difference between the player being stuck in a wall and the player touching a wall? So now that I discovered this early on, we can solve it before it becomes a problem.

What did I Learn?: 

Patience. As a programmer, I soon noticed that there wasn't much to do in the design phase and this frustrated me slightly. I wanted to jump into the project and get started. However. after seeing how much planning has gone into the game it made me realise that if I had jumped into the project straight away then the game would be underdeveloped, not fun, and hard to develop. Now that I know this, I can rest easy knowing that when the game is ready to be developed, it will be a full-fledged and well-thought-out game.

 An Introduction to Scrum. Scrum is the Agile framework that we will be following during the development of this game so it was good to learn what it is and how to use it. The way I understand it is that it is a structured way to control the flow of work to make sure the work is always consistent and good which, in turn, means the product will likely be produced on time and to a high standard. How scrum does this by using "sprints". A sprint is a period allocated to complete a selected number of tasks from the backlog of tasks. then, after the sprint, the team has a scrum meeting where they get to showcase what they've done and make any changes to the tasks. Then, rinse and repeat until the product is done. 

This method is good because we have a strict deadline of December 13th and this framework is heavily structured around deadlines and getting stuff done also we want to ensure everyone has some independence in the project. However, if we had more time, I may consider other frameworks as I think this one pressures people to work faster rather than harder. Also, In the future, I'd like to make a game with a bigger team but scrum is mainly suitable for a team with 3-9 members.

 Productivity 4/10

Morale: low

Week 2 Sunday 10th October 

Discussion summary:

 This week was busy. We discussed more about the design of the game, ironing out the kinks and developing the story (now that Jon is back from Greece). After a big discussion about the story, we started the project management side of the game. We opened up trello and started adding tasks. David told us that we had to add atleast 100 tasks so that's why it looks like this:

after preparing all of the tasks and organising them into different categories, the programmers started dividing the tasks up to be done this week like this: 

following this, we then put all of the assigned tasks into a sprint. A sprint means that it needs to be done by the following week. 

What did I do this week?:

 I had a few tasks this week but the one I want to talk about is the Dimension switching mechanic. It works by teleporting the player to a different tilemap based on the vector difference between the two tilemaps. For example, if the ice dimension is physically (0x,40y,0z) away from the fire dimension, then it will teleport the player exactly (0x, 40y, 0z) from its current location and therefore results in a seamless transition between the two maps and makes it more versatile for creating the map as the dimensions are physically separate so you can build them individually. In addition to this, I made it so that you can have any number of Dimensions. This is done by making a list of dimensions and calculating the vector difference between the current dimension in the list and the next one (or it goes back to the start).

 For the camera system, I made it so that there is a list of camera points and each camera point is an object with a trigger, if the player triggers the trigger it teleports the Main Camera to the camera point. I also made it so that the camera points teleport with you so that you can place half as many camera points.

 I also, did player damage, health states, iframes, and a shooting enemy (like bullet bill) but that is really basic stuff so it's not worth going into.

 What did I learn?:

 Simple tasks are fun when you have to be optimised. Due to having other programmers on the project and this being a large project, it's important to have organised and optimised code. This means using suitable variable names, legible code, and modular encapsulation. it's also important to make it as easy as possible for Harry (designer) to implement our features in the level design process. This means it has to be accessible and intuitive, including the adaptability of variables in the inspector. This process adds an element of difficulty which wasn't present during my previous game jams and this makes it more interesting and fun to do menial tasks.

 An introduction to Kanban. Kanban is the more fluid alternative to scrum where all team members can access and edit a communal task board. This means there is transparency among all the team members, the flow of work is consistent and the schedule is flexible. However, the lack of formal roles may make it difficult to manage and the flexible nature of tasks makes it unpredictable when the product will be completed which will affect the business side of the project. For this project, I think david put us in scrum because time is our biggest issue currently so the regular deadlines of sprint tasks will be good.

Productivity 6/10

Morale 5/10

Sunday 16th October Week 3

Discussion Summary:

We caught up on what everyone was doing. The main topic of discussion was about setting more explicit tasks on the Trello so that we could communicate tasks more effectively . Then, I had the task of setting up a Github repository for the project which was fairly simple. It consisted of sending everyone a link and informing them on how to access the repository and how to use github desktop. 

What did I do this week?:

This week, I set myself the task of solving the pressing issue of stopping the player from getting stuck in the objects/walls when switching dimension. This was a difficult initially as the objects you were getting stuck in were also ones that you had to stand on so we couldn't just use OnTriggerEnter2D. One Solution I came up with was to extend the collider of the block through the wall so that the collider would push you out into the safety. However, this was an inefficient solution as the designer would have to go through and change every block, also it was buggy.

 The second solution was to have a trigger in the relative location in the opposite dimension, then if you were touching that collider and tried to switch it wouldn't work. There were many problems with this, however, as the trigger would've had to have been placed manually. The final solution, and the one I went with, was to replace the box collider with an Edge collider (for standing on), then putting a box trigger inside the object which detects if the player is touching.

What did I learn?:

Any solution is preferable to no solution. if it works, it works. While presentation and organisation is important in coding, I think that having no functional solution is worse. This was a huge problem for the game and that finding a solution was paramount, even at the cost of cleanliness. 

David was giving a lecture about Github and how amazing it is. I struggled to get onboard with it as it was less integrated with unity as things like PlasticSCM (which i've used before) but in the end I changed my mind because with Github is free and you can have as many collaborators as you like whereas With PlasticSCM you could have 3 people on the project for free and then its $7 per user.  It just seems better that we can have everyone on the project at once.

Sunday 23rd October Week 4

Discussion summary:

 We gathered together again as a team. The main topic of discussion was the evaluation of the story and dialogue. until this point, Jon had been writing almost unfiltered. Some of us picked up on the fact that the story sounded quite cheesy and the dialogue was too explicit. This means that the dialogue was very descriptive. After a bit of back and forth between the team and Jon, Jon took the criticism head-on and started changing the dialogue to be a bit less descriptive. Problem solved.

 What did I do this week?:

 Early In the week, I fixed the camera panning so that it doesn't pan between dimensions but does pan across rooms. This was done by only interpolating on the x-axis and instantly teleporting the camera on the y-axis.  Then, I started work on the moving platforms mechanic. These platforms will freeze in the ice dimension and move in the fire dimension. Also, I made it so that you can add many points for the platform to visit and it moves along the points and back again. Also, I moved around some scripts and made the GameManager scripts which hold static variables such as isDimension1 which keeps track of which dimension you're in. Still got a few bugs involving checkpoints but that's for next week.

What did I learn:

 No pain, no gain. anything worth getting is guarded by pain, like a rose with thorns or like a cool mechanic which is hard to make.

 David taught us about the Gestalt theory which was interesting to learn about. Its basically about how we perceive patterns and how information can be presented in an ergonomic way.  I like psychology but design isn't my thing. Also, harry was watching the lesson through discord on my laptop but I'm not sure he was able to take in much. 

Sunday 25th October Week 5

Discussion Summary: 

Had a chat with Stanislav about what to do about the respawning bug where the player respawns in the wrong dimension and then the dimension switch mechanic breaks. After many ideas, we came to the conclusion of doing a 'caveman' method to fix it. To us, any problem is solvable but as programmers, we are always looking for the most efficient method in the least amount of time. Doing a 'caveman' method is just solving the problem regardless of optimisation or future problems that may arise. He was also telling me that he had an issue with motivation so I asked for this method to be implemented by the next day. He made a face as if to say 'no promises'-- so instead I asked for him to at least update me the next day... he got it done and dusted the next day. what a legend. 

Aside from this, we caught up with what everyone's been up to. we addressed that the artists needed to communicate more as they didn't know what bari was up to the previous week. After asking them a few questions recently, I think communication has marginally improved since we talked about it. The design team is going strong, all of them are having an input on the story and Jon is taking criticism like a champ Meanwhile Shakir reckons that level 1 is done so harry said: "if you think it's done, it wouldn't hurt for me to add more." So Harry has begun designing the rest of level 1 (which I think is going brilliantly). 

What did I do this week?:

I made a singleton GameManager object which involved using DontDestroyOnLoad(). However, this meant it would instantiate another GameManager when you reload the scene. To counter this, I used GameObject.FindObjectsWithTag("GameManager").Length > 1 to delete the current game object if a GameManager already existed in the scene. spawn GameManager -> if one already exists -> Destroy(this.gameObject).

This object had the static boolean isDimension1 which keeps track of the dimension that the player is currently in. The issue is that I had to do a U-turn on my dimension flexibility from before as I used to have it so you could add as many dimensions as you wanted but now there can only be two. The property 'static' makes it so that it can be accessed from any script which makes it useful when implementing small workarounds for the dimension switching. 

An example of a small workaround is when I was tasked with making the bullets of a non-teleporting enemy show in the opposite dimension but dont hit the player. To do this, I had a local variable called thisDimension which is set to equal GameManager.isDimension1 in the start() method which keeps track of the dimension that the bullet is in. Then I just had to do if(thisDimension == GameManager.isDimension1). This therefore proves the utility and necessity of the static variable.

Next, I worked on making the shooting enemy flip horizontally if a Boolean FlipTheGuy is true. This also meant  I had to change how the bullets worked and how they spawned. Now they spawn from an attackPoint's position and rotation. This means that when the attackPoint rotates, the direction of the bullet also rotates because the bullet is always moving to its transform.right.

What did I learn?:

 shorter deadlines and more work increase stress. a moderate amount of stress increases workflow. The only thing we don't have control over is the idea of consequences as no one is being paid and everyone will get a good grade if they write enough in their blog. However, there isn't much need for consequences because I'm working with a very conscientious group who want to get the game done and to a good standard.  The only issue is that most of us aren't stressed at all so the work isn't being prioritized. For me, I've decided to take on more responsibilities such as organising the team, increasing communications, and procuring music so that I can induce stress and motivate myself to work on this. It also makes me more passionate about the project which means I can sell the idea to people. Now, I just have to keep talking about the project, glue everyone together and get them to my level of stress so that we can get this done.

 Cortisol is the stress hormone and Increases the sugars in the bloodstream which enhances the brain's use of glucose. This potentially increases problem-solving ability and learning.

 However, too much stress is certainly a bad thing, but not enough is also a bad thing as it can cause anxiety, overthinking, and defense mechanisms such as denial, repression, displacement, and general aggression. 

aside from this, I was fairly busy and couldn't work on the project much this week.

 What did I Learn?:

 Winning an argument does not define who is right, it just means someone was convinced. If con men can convince people to waste their life savings on snake oil, then objective truth cannot be decided by a convincing argument. However, the incorrect argument will not have much evidence to defend it. Even so.  if I win, I should always second guess my reasoning and if I lose, I should second guess my evidence. This should help me discover what the truth is.

Sunday 13th November Week 7

Discussion: 

The discussion this week was kept brief because a lot of people haven't worked on the project this week. although this is a bad thing, It's also no one's responsibility to make sure everyone does their job. instead, it's all of our responsibility to do our own jobs. No ones paying us, no ones punishing us, no ones rewarding us, and the grading is based entirely on this blog so motivation is lacking but I have faith that we'll get it done in the last 4 weeks. Crunch culture is real, and I tend to indulge. 

What did I do?: 

I did a few vital bug fixes because there aren't any complex mechanics or programming to be done. I reckon the programming is very close to completion, we just need to do the boring bits like bug fixing and minor changes. 

More specifically, I removed the 'platform parenting' script which someone had added to the moving platforms. Due to the way we have done the hierarchy, we cannot parent the player to the moving platform because all the moving platforms are children of "teleport with player" which teleports when the player dimension shifts. basically, the player was teleporting twice. The second bug was that the ranged enemy's bullets were deleting on the bookshelf so I set the layer to "onlyTouchPlayer" which ignores bullets. Also, I added ranged activation so that the enemy only starts shooting when the distance between the player and the enemy is less than the 'range' variable. 

What did I Learn?: 

To address current problems before moving on to new tasks. Time and time again, we get so caught up in getting stuff done that we forgive or ignore minor bugs when we should be addressing every little thing. This would often come back to bite us. 

Sunday 20th November Week 8

The Discussion:

On Monday, we all reported what we had done the previous week. most of us had done stuff, Stanislav said hadn't done anything but I believe that it's because he didn't have any tasks to do.  Everyone else had reported to work, as usual, and everything was on track.... on Monday. 

What did I do?: 

The project is on fire... there are bugs upon bugs upon more bugs. it seems the majority of our problems are coming from either GitHub or people who can't use GitHub. we have 4 unused branches, 2 mechanically broken branches, 1 branch with unsolvable missing textures, and 1 main branch. now imagine the chaos if someone were to attempt to merge any of these branches into the main branch. I think that's what happened. Some people still managed to do work but when I opened the project today to start work on the moving platforms, everything was broken and I knew my work wouldn't be saved due to the demand for reverting the project to a previous backup. 

Instead, I came up with an idea for what I wanted to do for the moving platforms. The main issue was that we want the player to move along with the moving platforms as they moved. The classic solution for this is to parent the player to the platform OnCollisionEnter2D. However, we couldn't do this because the moving platform was a child of the teleportWithPlayer object. This was a 'root' object and its job is to teleport by the same vector as the player. My solution to this was to make a simple if  statement in the teleport script which says "if transform.root.name != "teleportWithPlayer"  then teleport the player, else, just teleport the teleportWithPlayer object". all of this was just on pen and paper until Im able to implement it on a fixed project.

 What did I learn?:

"If it ain't broke, don't fix it" but also "if it is broke, and you didn't break it, refuse to fix it".  sometimes we can just get in eachothers way when solving these problems, especially when it comes to github, so its often better to just stay out of the way (and keep communicating), until the problems resolved. also, it can be a good learning experience for the person who caused the problem to solve it so that they never make the problem again.

Sunday 27th November Week 9

Discussion: 

It's crunch time! throughout the week we've been communicating and sorting out the project. 

After getting some useful feedback from our QA testers, I decided it would be a good idea to chat with people about each point.

1. The enemy art style doesn't fit with the rest of the art for the game - firstly, I asked Miguel about what I should do about this, as he is the unofficial art lead, and he said that its Bari's own responsibility for his art and that this will reflect in his own grade, as long he gave us something then its fine. I decided to ask Bari about it over message. He told me that he really tried his best for the first time and that 2D isn't his forte. now, either he's the best con-man of all time or he genuinely tried his best, because what he said really moved me. I think his art is fine, considering all the factors.

2. We had multiple accounts of the physics system being buggy or unsatisfying. Also, the mid-air movement speed was heavily dependent on the frame rate. My proposition is to remove all of the complex physics, ground detection, and composite tilemap (all of Stanislav's work) and replace it with a simplistic movement system using rigidbody.velocity. Not only would this solve all of our current problems but it would also solve all of our future problems. This was a point where if I was in charge, I would've made an executive decision that would reduce the bugs to a minimum and increase the playability of the game. However, on this occasion, Stanislav was in charge of the player movement and physics so I asked him. he said "I'll just fix the bugs, it won't be that hard" and that's where I employed Miguel's philosophy of "if he doesn't do it, it's his own fault and I can live with that". There have been so many programming issues which I had no control over, I like problems that I can solve.

What did I do?:

 This week I did mainly bug fixes, but it was a fair bit of work.

 I Implemented the music (which I procured from an ACM music student who goes by "Remi Rorschach" on Spotify). The complexity comes from the Idea that we wanted different music for the different dimensions but it would be layered so that the songs overlap. For example 0:29 of the ice music should sound similar to 0:29 of the fire music so that there is a smooth transition in the music when going to the next song. To implement this, I just used AudioSource.time to get and set the time stamp of the audio clip. Then, when switching dimensions, I would set the timestamp of the next song to equal the time stamp of the current song. 

I fixed the ladder-climbing bug. The bug was that when there are two or more adjacent ladders and the player could only climb up one of the ladders before losing the ladder physics. The source of the bug was that the ladder was using OnTriggerExit2D and therefore you couldn't have any overlapping colliders. My solution for this is to just remove the collider from all but one of the ladders, then stretch the remaining collider to cover all the ladders.

 Next on the list was fixing the teleporting issue when cameras wouldn't teleport with the player. since this has happened a lot at different stages I decided to do a blanket fix and just drag the cameraPoints into the TeleportWithPlayer object and remove the part of the script which teleports the cameras. that should do the trick.

 There was also a problem with the way moving platforms worked in that if the player was stood on a platform, the player wouldn't move with the platform.  One regular solution for this is to parent the player to the platform OnTriggerEnter2D and then unparent it with OnTriggerExit2D. HOWEVER, we couldn't do that because the moving platforms were children of teleportWithPlayer which teleports by an offset every time the player teleports, this meant that the player would teleport outside the map if you switched dimensions while on a moving platform. We toiled around for a few days and then I came up with a clever solution! "if transform.root != teleportWithPlayer, then teleport", this means that if the player is a child of any object in teleportWithPlayer, then it doesn't teleport twice. epic stuff.

 told you it was a fair bit of work. 

What did I learn?:

 QA testing is a really valuable resource. or more like, the conversations we have about the QA testing are really valuable. Not only does it mean that you get an outside view on the project from the pov of a player, but you also have a winning argument against people who rationalise their delusions regarding work. I'm not saying it happened on this project (and I'm not naming names) but if there's someone who thinks they've done an amazing job but they actually haven't done that well, they will argue forever and explain why their work and decisions are good. But then they'll get a wake-up call when someone says "actually, 90% of the QA testers also have found issues with your work". There is no retort to that statement which sounds good. You could say "the QA testers don't know what they're talking about" or "it's only a prototype" but at the end of the day, as long as the sample size is big, you have to stop and re-evaluate your work-flow and your creative decisions.

Sunday 4th December Week 10

I Know that we were meant to write something for the blog every week but that doesn't necessarily mean we have to work hard on this every week, right? During the Monday session, I implemented the Int to detect whether you were in level 1 or level 2. This is not very efficient or modular but we needed it working so that level 2 could be designed. However, at this point, I could only do a handful of things for this project so I decided to focus on my other assignments.

 The main thing we needed at the time was the Level 2 design. I saw that Shakir was not getting Level 2 done quickly enough so I suggested that harry take over which I think was a really good call. It's a good thing that Shakir didn't object to this as Harry's been implementing the level design and knew exactly what to do. On top of this, I've worked with him before and have faith in his work ethic and ability to get it done in time.

 On this project, I haven't had the authority to override any executive decisions that needed to be overridden, as everyone acted as equals. Each person had their own jurisdiction and made decisions relative to themselves and didn't dare to overstep. However, this suggestion I made for level 2 design needs to be noticed because I made a calculated decision based on probability, experience, and knowledge that would widely benefit the project. Next term, for the AAA, there will be a project manager and subject leads who will make executive decisions for the good of the project and I hope I get to be one of them.

 Aside from that, yeah, I didn't do anything on the project this week :D.

Sunday 11th December Week 11

Level 2 design was fully underway and john has been implementing the story, the game was finally coming together. All they needed from me was a few technical tweaks. 

One thing that they needed for the story implementation was a StopMovement(), StartMovement(), canTeleport(), and stopTeleport(). This makes it so that the player cannot perform input during dialogue sequences. It wasn't in my jurisdiction to implement this, however, since it's been Stanislav's task for the last 5 weeks. On the other hand, it is such a small task that anyone could do that I decided to just get it out of the way.

 Then, I proceeded to climb up the pile of back-logged programming tasks. We had this task of adding a background to the void dimension which will grow and shrink to the size and dimension of the camera and after talking with harry about how to do it for 20 minutes...... I came up with the solution of "just put it on a UI canvas, on the background sorting layer". The sudden realisation of how stupid we'd been made us burst out in laughter with a hint of sadness. Then it was simple to make that UI object turn off and on based on which dimension it was in.

 Next, because the player can only survive for 3 seconds at a time in the void dimension, I started work on the "void timer". This was a UI clock in the corner that counts down until you die in the void dimension. This was another simple yet tedious yet necessary task, just created a timer (time += Time.deltaTime) then (text.text = maxTime - time). There was only one hiccup which was that the timer kept ticking to -1 after death. This was fixed with a simple if statement. Again, these are just tasks that no one wanted to do but must be done before the 13th.

 Finally, I implemented a twinkle animation whenever the player switches dimensions. the best thing I did was use Animator.Play("swapAnim") instead of messing about with the animator system. Every project I've had a huge issue with this system and it's the most tedious work. Maybe in future, I could make my own animator system. It wouldn't be hard and would be incredibly useful.

What did I Learn?:

suprisingly lot about procrastination, it turns out that stress is not the cure for procrastination but the cause. The mind is threatened of the upcoming task/deadline and that makes the brain go into shock and subconsciously makes you avoid the task at all costs as it is the source of stress. Even if the task isn't that bad in the end, stress comes from the perceived task. The reason why I correlated stress with productivity is that whenever a deadline is coming up, most people get the work done and go into overdrive. However, in reality, they are only doing the task now because they can't avoid it any longer as people are going to face them the next day and say "why isn't that task done". It's actually the LACK of stress and the ABUNDANCE of interest which is that increases the quality and quantity of work. only stress just increases quantity.

The stress approach vs the interest approach