Harry'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 (26/09/22 - 02/10/22)

For our very first day we started out with a group brainstorming session, with everyone in the team coming up with ideas for what kind of game they wanted to create. I found that in this initial stage it was hard for the group to all be on the same page at the same time with what the idea for the game was. We eventually decided we liked the idea of dimension switching as a core mechanic. However, there was still some miscommunication at this point, myself and the designers thought that the team had agreed on a game fully surrounding the idea of switching between 2D and 3D perspective. Although, it later became clear that they were only suggesting this to be one of the levels among many other dimension switching concepts. Rightly so too, as a game surrounding the core mechanic of switching between 2D and 3D perspectives would quickly run out of new ideas to explore. This was something that I had not fully thought about before me and the other designers explored it as a concept. So, it was not until I was approached about it that I realised it was best to go with the core mechanic being switching dimensions in a more general way. That day we then settled as a group on each level featuring two dimensions that you switch between with a button. 

We also separated ourselves into roles as designers on the first day of this week, with me as the designated gameplay designer, working closely with Shakir, another designer being designated as the level designer. Then in charge of the story of the game was John, who wasn’t present this week, but started to brainstorm some ideas regardless. As this was the week before we learned about Agile Methodologies, we were still very unorganised and there wasn’t much overall progress made. Therefore, the planning process was quite slow and as I discussed previously it lacked good communication. However, in the coming days we all started to add ideas onto our Miro board for different levels we could have. This being the two different dimensions that you switch between each level.

One issue that was brought up was an uncertainty in how the camera of the game would work, it was not something I had previously thought through at all. As we chose to do a platformer, I decided on us using a fixed camera, with moving between rooms, because if we had lots of puzzle elements to our game then a fixed camera is good for seeing everything on screen all at once.

Later in the week I attempted to fill out the Game Design Document with my vision of how the game should be in order to make sure everyone was on the same page and get a slightly clearer picture of what the game would look like as a whole. I kept finding however that I was unable to tell if some of the ideas I was coming up with for the game were good on my own. Or rather, I found it tricky to think some ideas through fully and as a result some people disagreed with the suggestions I had for the game. Even though I myself am a designer, I believe it’s still important to listen to the feedback of team members from other roles, especially at a very early point in my experience of being a Game Designer. 

Something I learned this week is that I need to work on thinking my ideas through fully before fully pursuing them. Otherwise, this could potentially cause team members to work on tasks which I set as the designer to later be unnecessary or not right for the game, and it means I have to rely on my team members to spot any flaws in my design rather than me being able to myself. To improve this, I will try to communicate more with the other designers to see what they think, and also making my own prototypes for features I want to add to a game, this will then give me a clearer idea of what needs to be done, and how well something works, before handing it off to be designed technically and visually. In future projects during the early stages of development I need a Game Design document ready to go, and I need to improve at spotting anything that hasn’t been decided on by myself, rather than someone approaching me with an uncertainty they have in the project. As a result, sometimes if I am unable to spot these uncertainties then it’s also possible that design decisions could be made without my knowledge, since I haven’t specified something properly in the design document. 

Week 2(03/10/22 - 9/10/22)

We decided upon weekly scrums from this week onward, and everyone set themselves tasks to do by next week. For our scrum meeting, we discussed what everyone had done the previous week. There were lots of issues with actually fully fleshing out what the idea is. Yet again people were coming to me with design decisions that I should have already been thinking about myself. We also heavily discussed what the story should be about, as we had an entire person dedicated to figuring this out, so we could go for something ambitious. We ended up deciding on having our character be a struggling Game Developer, who is unable to reach the deadlines set by his boss. The game would take place during his dream and him being unable to focus is represented by the drift between dimensions in his head. Or, at least that's how I've interpreted it...

At the beginning of this week we created most of the tasks for our project on Trello, and we figured out more about what the idea was going to be. The main idea that everyone could agree on was switching between 2 dimensions each level. The previous week we had brainstormed some ideas for level mechanics, so I picked from them and proposed to the rest of the group which ones we should use, and in what order. 

We initially took on about 5 levels worth of tasks, as it was assumed by me that each level could be quite short, and the levels could switch mechanic quite often. I initially thought about a very simple idea for a first level where the shape of the camera changed, but I later decided there wasn’t enough direction for it to be taken. So, instead I decided the first level could be a fire/ice section, with ice blocks as platforms and ice spikes in the ice dimension, then hazardous fire in the fire dimension. I thought this could be a simple way to introduce the mechanic of fire and ice to the player without overwhelming them. By the end of the first day I had come up with some other mechanics for the other levels. This being Past/Future where your Future self cannot jump but cannot fall, due to being in a hover chair, which everyone liked the idea of. Another idea I had was a dimension with Earth and Space. Where you have Earth with normal gravity and environmental objects placed around, and then a Space dimension with zero gravity, but you die in 5 or so seconds. Then we re-used our 3D and 2D idea as one level, and I finally suggested a chase idea as a final level, where there’s a section of the level in which you are being chased, and when you switch dimensions you swap positions with the chaser.

I came up with the initial mechanics for what the fire and ice level would be. These were fire obstacles that damage you, Ice blocks that turn into water puddles, and also ice spikes which damage you. At this stage, it was Shakir designing the levels, and I had much more experience with Unity. So we came to the decision that I would be the one to implement his designs, as a result I could test his designs and suggest changes if I deemed it necessary. This was likely, as the designs were made without being able to test the mechanic, so it can be easy to make an oversight by just thinking about the level in your head. In the coming weeks I would learn that this, however, was a bad way to do it. Making the roles as separated as they were meant it was the responsibility of one person for an entire section of the design, with the other designers merely making suggestions for changes. With me being delegated as the overall ‘Gameplay’ Designer, I had much less responsibility after the first week, so it would’ve made sense for all of us to be involved in all areas of design from the very start. Otherwise, I’m sitting around waiting for the designs without much to do.

An Initial movement script was also created this week by the programming department, it involved a system whereby the player would have a downward velocity applied to them as they let go of the jump key. After testing this though, I felt that the numbers definitely needed changing. The fall clamp speed, as it was referred to, was too high. In comparison the player was falling much too slow, so the applied speed from letting go of space was noticeably odd. The script was made in a very versatile way, however, and it was easy for me to edit these numbers, which I did. I changed the numbers again and again until it felt more right, and it was useful that it was clearly explained what each variable did, and how it changed the physics of our player. I also suggested an addition to this movement script we had, which was increasing the fall speed as the player held down the ‘s’ button mid-air. This meant the player had the ability to fall quicker if they wanted to.

Player damage was also discussed at this point, and early on I declared that the player would have 3 health as they went through the level, and we would have place-able checkpoints which the player would then return to upon death. We then ended up with a versatile damage system made by Sam, where we attach a script to an object, and then that object would damage the player, causing them to lose health. Enemies were also discussed, I initially decided we would have three types of enemy. A shooting enemy which just shoots straight forward, a melee enemy which runs after you, and another shooter which switches dimension when you do. I made the decision that the player cannot kill the enemies, meaning they only really act as obstacles. I may later regret that decision, but I wanted the focus to be more on the platforming, and also couldn't think of a unique way in which the player could kill them. If there was it would argueably have to involve the core mechanic of dimension switching. Perhaps if the game had a larger scale there could have been a way to switch dimension and make an enemy collide with a hazard for example. However, for our short indie game I didn't deem this necessary. 

Communication was still a huge issue at this stage, I was not very good at identifying things people were unaware of in the project. This week was supposed to be our first sprint, and many members of the group were unaware that we were supposed to be sprinting. I was also still very unfamiliar with Scrum, and should have looked more into how it works. In the coming weeks I would start to be more familiar with it as a process. It was also suggested that many of the tasks on Trello were quite unclear, I was still having trouble with fully fleshing out the design ideas, and was very much making up the design as I went along, rather than planning ahead. Many tasks that I proposed needed doing were very undefined, and this definition would come slowly over the weeks rather than fully planned out at the beginning.

Near the end of the week, we discussed which method of version control we would use. I had been very familiar with Plastic SCM from previous projects, and it was simple due to it being integrated within Unity. However, the downside is that Plastic SCM limits 3 people on the project. We also had no experience at all using GitHub, we decided that using Plastic SCM with just 3 people would be ok, without the future knowledge that it was mandatory for everyone to be in the project for the assessment. 

This week, I learned a lot about Agile Methodologies, and how the process of Scrum usually works in a project. I also learned a lot about clear communication between team members, as I was leaving a lot of the design in my head rather than writing it down at this stage. Which is a big problem for the other members of the team being able to understand what's going on.

Week 3(10/10/22 - 16/10/22)

This week during the lesson we learned about the different forms of version control, Local, Centralised and Distributed. As stated before I already had experience using a form of Distributed Version Control which was Plastic SCM. Distributed Version Control means that everyone in the project has a copy locally on their system, as well as a copy that exists in a Centralised Hub which members of the group Push to and Pull from. Even though I had already used Distributed Version Control, I had not previously used the idea of branching within projects, as we generally would work in separate scenes to avoid conflicts, and I would usually be the only one changing a scene as a designer in previous projects. However, the concept was simple enough to understand. We created a GitHub repository for the project on Monday and I soon created a Level Creation Branch to create the levels in for the project. This way after implementation of the level design I can make sure it works and suggest any additions or changes I might have with the level designer Shakir.

This week John, in charge of creating the story, had created an initial draft for the in-game dialogue, there were a few small suggestions that I made to this. At this stage though, I was still very conscious of getting too involved in the story, as I knew I had very different opinions creatively compared to many of the other members of our team, and this could become a problem for the game as a whole. Due to the fact everyone in the team had such different ideas creatively, It meant a risk of being inconsistent across different disciplines. Which is why I held back from certain suggestions, which I knew were only opinions from a creative perspective. The game would need a consistent tone overall, and we began to decide that this game was going to have quite a serious tone. This is not something I would normally want to do, I prefer working on more light-hearted and silly games. As a result, if we were working on more of a light-hearted game I think I would have been more passionate about it and would have felt that I could be more creative in my design process.

By this week, we also started to have some designs ready that I could implement into the project. In the previous week Sam (programmer) had created a modular system for switching dimensions involving tile maps, whereby the player would be seamlessly teleported between 2 different tile maps. For the first level, I wanted the tile maps to be completely the same, but this of course still worked fine with that system. I soon began to create the designs made by Shakir (level designer) for level 1. Some things had to be adapted based on scaling etc, and I had to make suggestions for changes based on testing the levels. It was very understandable that the levels would need changing since they could not be tested in Google Slides. I found the overall process of this tiring however, as I’m just doing the ‘grunt’ work so to speak, and for the most part I wasn’t actually designing. In the future weeks I would look to get more involved, as I was eager to work on the project a lot but felt I had no design responsibilities at this stage, except giving feedback to my fellow designers.

One design problem that was also brought up this week by the programmers was what should happen when the player switches dimension into a wall, should they die? Or should they just be teleported to the edge of the wall? The second option could be very unreliable, as the player might be teleported into a hazard which would be very frustrating. Therefore, I thought it best that the player is instantly killed if they teleport into a block. But, on the condition that they would know the wall or block is there. Making it fair since a competent player would be able to avoid this. Thankfully, since I had decided to have the same tile map for each dimension, this was a problem that could be solved by Sam (programmer). In conclusion, the Ice blocks for the Ice dimension (solid platforms which the player can stand on) would kill you if you switch dimension into them. I chose to denote the location of these ice blocks as puddles while you’re in the fire dimension, so the player is well aware that they will switch dimension into death while standing on a puddle.

With a lack of a strict Scrum Master or an overall Project Manager in our team, we very much struggled to follow the ideologies of Scrum. Even though we had supposedly been sprinting since the previous week, we did not still have a build to be playtested by this stage, so we were not following the iterative cycle that Scrum should. This usually would involve making a working build of the game each sprint, and then evaluating what needs to be done next based upon playtesting. We roughly were undergoing playtesting every 3 sprints instead, which is not ideal. 

Week 4(17/10/22 - 23/10/22)

This week, I attempted to join the in person session remotely as I was away. This meant I was a bit less connected but still carried on nevertheless. The lesson was on the Gestalt Theory. I sort of was able to follow along, there was a lot about UI which I found interesting. Our project has little to no UI however, still useful for the future nevertheless.  That day we agreed that the fire and ice level needed more mechanics than just fire hazards, ice blocks and ice spikes. So, I set out to come up with as many new mechanics relating to fire and ice as I could for the first level, and then proposed them to everyone else in the group. One good idea that was already proposed was moving platforms that move in the fire dimension, but stay still in the ice dimension. This was a really good idea which allowed for a lot of creativity in the level design. Other mechanics I came up with were Springs which only work in the Fire Dimension, wood platforms which fall in the Fire Dimension, but act as normal platforms in the Ice Dimension. Fans which push you and are only turned on in the Fire Dimension. In the end the rest of the team were happy with all of these ideas, except wooden platforms which fall in the Fire Dimension. This was understandable though as the moving platforms could be used in the same way. Once we had these new ideas going it was just up to the programmers to put them into action.

We also decided this week on a minimum viable product,  as production for the game was slow, we still barely had a first level by Week 4. It was unlikely we'd have 5 Levels by Week 11. Initially, the rest of the team proposed 3 levels as a minimum. However, I suggested instead that 2 levels and a boss would be better, since it can be important to bring the game to a conclusion. This meant scrapping 2 of the ideas we had for levels, In the end we chose to scrap our Past and Future level idea, and 2D/3D. Then, the idea I had for a chasing enemy which swaps position with you, was made as the boss. Level 1 was still Fire and Ice, and Level 2 would now be Space and Earth. With this new minimum viable product, I felt confident we could get the product done, considering it was still Week 4. Still, there was an ever growing worry in the back of my mind that the project would become a game about Fire and Ice, instead of different dimensions.

Design of Level 1 continued this week, with the addition of the new mechanics that we decided upon. The designs were still being done in Google Slides, I personally think this is quite a limitation as you can’t really get a sense of how it's going to play. It was ok though because I can always test them when I implement them. Once again I had a few suggestions for the level designs, we had some floating fire for example. There also began to be an underlying feeling among the group that the levels needed much more challenge, Level 1 was progressing slowly, and we were nearing the halfway point of the project. I was starting to run out of things to do, other than wait around to implement said designs, so I needed more contribution toward the level design soon. We were still very strictly divided at this point, and I was starting to understand the importance of more of the tasks being done collaboratively so that the responsibilities can be split evenly among the designers.

At this stage, the artist responsible for creating the environment, Angie, was having trouble visualising the overall setting and context of the level and requesting that a ‘floor plan’ for the level be made. This was not something that I considered would be as helpful as it was, but I then went ahead and made lots of placeholders for the aesthetics of the level map we had so far. These were just ideas I had about decorative objects which would need to go in the scene. It worked a treat, and gave a much better understanding for the artists for knowing what the level should roughly look like with the art in it. I’ll definitely do this ahead of time in future as I never thought about how helpful it can be, and it means I get to draw my own bad versions of the art as well (I shouldn’t waste too much time doing it though).

Week 5(24/10/22 - 30/10/22)

This week we started to implement the dialogue that John had been working on into the project. At this point I proposed that we create a separate branch from this and leave the dialogue side of things completely separate until the end of the project. We could still pull changes from main, it’s just that the changes in the Unity scene would be overwritten. We decided on using Fungus for this, (a third party plugin for Unity to help implement in game dialogue). I already had experience with integrating Fungus into gameplay using hitboxes that trigger dialogue, so I helped to set it up ready in the project for when we wanted to start the dialogue implementation. We quickly realised however that we needed a function which froze the movement controls, so the player couldn’t run around during dialogue. It was also suggested that the story needed reworking at this point, so John was going to do this before we started implementing properly. 

We also had our first playtesting of the game by other members of the class, getting some first impressions of the game. Many people seemed to think the game needed much more added, and it was stated by the level designer that the level designs were finished. As a result, I requested that I take over and add more to the first level of the game. I really felt I wanted to experiment with our current mechanics. So that weekend I started to create some new rooms straight into the level.

I was very much eager to properly introduce the player to the newly created moving platforms from the previous week by Sam. So, I set out to create a few rooms which explored this mechanic in detail. The first room I created was a very simple room which introduces the player to the moving platforms. It would be in this room that they learn that the moving platforms only move in the Fire Dimension. In this room they are used as basic lifts moving up and down, with one of them moving left and right as well. It was important for this first room when they don’t know what the mechanics are for the moving platforms that they cannot be punished for this lack of knowledge. So, there were minimal obstacles placed here as a result.

The next room was a room adapted from one that Shakir (who was previously doing Level Design) had designed. I decided to add upon it though, I felt it needed some more challenge by this point. We also had shooter enemies ready to implement at this stage, and so I decided to add one of these enemies to this room on top of one of the moving platforms, guarding a key.

Up until this point we already had water puddles placed in the fire dimension denoting where ice blocks were in the Ice Dimension. While creating and testing the levels I thought it was definitely necessary that the fire hazards had a similar thing, as I kept dying by not knowing where the fire was and teleporting into it. So, as a result I created ash piles for the Ice Dimension. These would show where fire was going to appear after switching dimensions, so that the player could be aware that they were about to collide with fire if they switched.

I also finally added one more room utilising these moving platforms. The idea for this one was freezing the platforms at just the right time, so that they almost formed a staircase to get to the desired height. I also thought there should be an enemy shooting at the same time, so you have to juggle dodging the bullets together with trying to freeze the platform. I was in the dark still about how challenging players would find this. So in the next week I would look to receive any feedback on the levels I created. It would presumably need changing based on playtesting. 

As I was pushing these changes to Github, it was soon pointed out that my commits needed to be clearer to the rest of the team. I was naming the commits to something vague such as ‘Level 1 Stuff’. Instead of going more into detail about what exactly was changed. This is definitely something that will be improved upon in the later weeks.

Week 6(31/10/22 - 6/11/22)

This week, I wanted to give Shakir something to do now that I had started doing Level 1. So, I thought it would be good if I got him started on Level 2 straight into the project. I showed him the tools which the programmers had provided and how to use them. Then, I left him to his own devices. I still had to make sure all the mechanics were clear to him, as he could still not test the mechanic since it had not been made by the programmers yet. When I’m level designing I find it best to be able to test the mechanic as I draw out my levels, partly because it gives me a lot of ideas. Also, as a design principle I’m aware that it’s important to design your levels around the mechanic, making it better when you can test out your mechanic along the way, and getting familiar with how it’s going to play. This being said, perhaps I should have suggested he wait until he could do so, as it would have helped a lot in knowing how his level would play out. I did however ask for an early version of the mechanic so we could at least get some idea of how it was going to work, but it was too much help as it didn’t work properly yet. The mechanic was supposed to be that upon switching dimension, you lose all gravity and control over your character, then whatever previous momentum you had is carried over. However with the early mechanic which was being tested to make the levels, the player could still control the character in this state, so it could have resulted in some wrong level design decisions being made. Based upon this, it is clear to me now that we may have jumped the gun on using Unity to create the levels, however it was still better than Shakir having nothing to do.

I also got feedback from fellow team members about the level that I created this week. One early suggestion was that the room I added where you have to freeze the moving platforms in the right place was too hard. Since the platforms all moved at different unrelated speeds, the timing of freezing the platforms was very inconsistent. So as a result I made the moving platforms line up at the end of their cycle, every cycle. Two of the platforms would move the same distance at the same speed in their cycle. Then there was one platform which moved double that distance, but I made it move twice as fast so that it got there in the same time as the other two platforms. In short, the platforms lined up for you to jump up every cycle consistently. This way the player couldn’t be frustrated by waiting a long time.

This week we also made the decision to make the player always die in only one hit, this is because we already had very generous checkpoints, so dying more often was ok. It also meant that the player couldn’t power through areas of fire for example to get to a checkpoint, so we wouldn't need a way of making the player bounce off of fire, and it wouldn't matter whether the fire was a trigger or a regular collider, since the player would always die.

Another change was a small delay in the player's jump for the sake of animation. One of the artists had created a jump animation whereby the player's jump would be delayed ever so slightly so the animation had time to play. I thought this would be ok, since the delay was only very small. 

One other big programming issue that was brought up was the idea that since the player had to suffocate in the walls in Level 2, these walls could not be made with tilemaps. The original idea for this level was Space and Earth, where most if not all of the environmental objects exist in the Earth Dimension. Then there are none in the Space Dimension, but you have no gravity. The problem with this is of course you need to suffocate in an object if you teleport into it from the Space Dimension to Earth. However, as stated above, these walls could not be tilemaps, because it seemed as though this was quite complicated to program, and easier with individual objects. For the suffocation script to work, the object needed a normal collider, and a trigger which is smaller inside, if the player collides with this trigger then they die. This wouldn’t have been able to work if tilemap colliders had been used. It would make it a lot harder for creating levels as we would have to manually place the objects instead of using tiles.

This week there was also still in fact an issue of understanding how the level would look for some of the objects. These were mostly the level elements themselves. One big aspect of confusion was the fire hazards, at this point in the project they still looked like big orange squares. So for next week I looked to improve the placeholders again to help out the artists. With there still being this confusion at this stage, it shows that I still need to improve communication with artists by making clear placeholders for everything, or stating in a clear way the setting and context of the environment.

By the end of the week I finished off the initial designs for level 1, with 3 extra rooms made. I decided to use verticality more, as previously the rooms had been just from left to right only. I then decided that these rooms should be the hardest yet, to really challenge the player. So the final room I created involved strict timing of jumping between moving platforms. One problem I was worried about however was a problem with the moving platforms. When the player lands on a moving platform they are supposed to be parented with it in order to follow its movement. This was currently not working though, so the platforms would be sliding out from underneath the player as they land, which increases the level of frustration when paired with a high difficulty of platforming. I would look to make sure this issue was fixed as soon as possible within the coming weeks, as it was a very big gameplay problem.

Week 7(7/11/22 - 13/11/22)

This week was our first recorded playtesting session. If we were following Scrum properly, it would have been our 6th or 7th. Our team was more following Kanban, with it being less iterative. As I stated before though, it was hard to follow Scrum without anyone enforcing it or any consequence for not doing so. 

This time when playtesting, it certainly seemed as though the final room I made for level 1 was far too challenging. It was with the very strict timing of the moving platforms, and the issue of the moving platforms sliding out from under you was still happening. To solve this, I addressed the problem with the moving platforms to be much more urgent. It was also clear that the timing was a bit too strict in this section, so I made that more generous. It was also quite confusing as to where to go, as there was a part where the player must travel up instead of from left to right. As a simple solution I added some arrows which direct the player in some areas.

Another thing was clearing up more of the placeholder assets, there had previously been some confusion expressed about the fire obstacles in the project and what they would look like. There were also one way platforms which were still just grey blocks for gameplay.  So, I had to figure out what these were, and create placeholders for both these and the fire obstacles. I decided in the end upon the context of a bookshelf, and created the placeholders then put them into the project. The confusion seemed to be cleared up for the most part. Although, ash piles were still not known to be as such. Instead of creating more placeholders I decided to add labels to many things within the project which may be unclear. 

Near the end of the week I spent some time going through the story with John as I had some ideas about the overall context and direction it could have. With 2 people doing it, it would be easier to make it sound less robotic. I later found out that John was not happy with many of the changes of tone made, I’m generally not a very serious person so I would have liked it to be more light-hearted. However, I perhaps should have seen that this was only subjective. I think John has also since learned to follow his own creative decisions rather than listening to everything everyone else says. I still feel bad about this nevertheless.

I also made the Game Design Document more complete based on what we currently had in the game, and the rough idea of what it would be going forward. Ideally this could then be referred to by the rest of the team. I started to realise that in future, there should be a Game Design Document prepared, with designers having already tested and experimented with their ideas, before proposing them to the team, and directing people on what should be done.

Overall, I felt quite underused this week, since I had once again passed on the level design to Shakir for the second level, there wasn’t much left afterwards. I still am learning more and more about the importance of clear communication, everyone has to be on the same page at all times. Even if that means re-iterating a few things, just to make sure, As you may think you’re on the same page and not realise.

Week 8(14/11/22 - 20/11/22)

This week, we started to implement dialogue properly. I thought it best that the dialogue did not interfere with the rest of the branches. However, the scene changes kept being overwritten as were updating from Main. So, for now, I suggested the creation of a prefab object which held all of the dialogue information. Then, we could keep dragging this into the scene. So after we went ahead and created this, John started to add in all the dialogue ready as dialogue blocks in Fungus, ready to be implemented.

I decided that swimmable water should be scrapped this week, since there was only one instance of it, and it would be a waste of programming efforts to make this as a result. The melee enemy was also created and ready to be used, so I soon had to get this into the levels more.

We also had some major merging problems in Github this week. As more of the artists started being involved directly in the project more, it meant there were instances of trying to change the same thing. At one point I was trying to implement some of the art assets properly and was trying to get the scaling right. Meanwhile there were large scale changes being done to the tilesets by Angie in the same scene. This meant we had big issues merging, and I learned to be extremely careful about changing the same scene file even in different branches, as it can result in a loss of work for 1 or more members of a team. In this case it meant Angie had to redo everything she had done with the tilemaps. I also added a room signifying the end of level 1, this being a completely blank room with floating objects where the main character would have dialogue with his mother.

It was suggested by other team members that the story had improved. However, it was still not how John wanted it which is a big problem since it is his job. I think it’s very important that everyone gets their own creative freedom in their own particular areas, however of course there should be a consistent tone overall. I wish I had seen earlier that John was unhappy with the direction the story was going and stepped back a bit.

Later in the week the ladders had now been programmed. Previously, the idea was that the ladders are missing from the Fire Dimension, but I decided it serves barely any gameplay purpose to do that. Due to this, I changed it so that they are consistent with both Dimensions.

This week I learned that it’s very important to tread lightly when changing the same file or scene in Unity while working collaboratively. In future I will always communicate with others to check if they are editing a file before editing it myself.

Week 9(21/11/22 - 27/11/22)

This week we aimed for a solid playtesting of level 1, with people who had never before seen the game. So, I got to work on creating a more polished version of the level, making sure everything was all ok before sending it over to the playtesters.

I also realised that we did not have a room utilising the melee enemy, so I added in a new room at the end which put the player on a path of encountering such an enemy. The melee enemy worked in quite a simple and effective way. It would patrol in its current location left and right, and then it would attempt to chase the player when they got close. I made this room fairly simple aside from the melee enemy, as I didn’t want the player to have to deal with the melee enemy alongside a puzzle of some kind.

Once again, we were barely following scrum, and had just one recorded playtesting session at this point. However, we were ready to go with another session this week, and after some cleaning up of level one I sent over a build for playtesting, alongside our survey.

The feedback from this was very helpful. Firstly, the delayed jump to assist in visuals was very noticeable when playing. We needed to find some way of removing or lowering this delay. There was also a big problem of the player being able to jump off from the walls to gain height. This was quite a big problem which I maybe should have pushed to be fixed sooner. One of the playtesters even thought it was supposed to be a feature. Most of the issues were to do with the physics of the game, so partly not a design issue. However, I needed to be changing around the numbers perhaps to get it working better, as I had the ability to easily do this.

Most of the playtesting found the level design to be okay, there was one slightly controversial section though. During the level, there is one specific part where you must stand upon an ice block, and jump up and down switching mid-air to get a moving platform to lower. Some players found this satisfying to figure out, and some found it frustrating waiting standing in the same place for the moving platform. As a result, I made a compromise. Still in keeping with this idea, but making the moving platforms faster so that the player wasn’t waiting as long.

It also appeared that the melee enemy could easily be tricked into getting stuck in the current state of the level. This was just a case of raising the height of a platform slightly.

One other thing, was that the decision to make the players health just 1 hit, was not very well communicated to the rest of the team. One artist only found out by playing the level and testing themselves, when they had been tasked with creating the UI for this. If they had failed to realise this, there could have been wasted time if they went ahead by creating art for it. Once again it seems that my communication of design decisions was lacking, and that needs to be improved further. 

By the end of this week I started running out of tasks to do, and asked that I take over for level design once again. This time though, I was adamant that the existing designs would stay In. I would looking into starting this during the next week.

Week 10(28/11/22 - 4/12/22)

This week, we got the prologue of the story working nicely within the main branch. It was no longer safe to leave it as a prefab, with the scene changes being overwritten. We started applying things like rotation of the player GameObject and moving the player to certain areas. These were direct scene changes, So I thought it was time that we pushed the dialogue to main, as this would stop work being lost every time somebody else pushed changes to that same scene.

Another thing was that many people were still unaware that the second level would not consist of tilemaps. However I tried being more clear this time, and reiterated how it was going to be. The problem was that Shakir had been blissfully unaware that we couldn’t draw out the level with tilemaps, since I forgot to tell him directly. Now that I was taking over, I would look to first convert his level map into something which achieved the same gameplay, but without tilemaps. We had the mechanic for level 1 ready also, so I could begin creating and testing the level properly. 

Firstly, I had to create some placeholders for the level’s canyon environment. I attempted to optimise the objects in the level, re-using 4 basic shapes to achieve an entire level’s worth of gameplay. This ended up working fairly well, I created a floor asset, wall asset, floating platform asset, and a non-uniform slope piece of land. I then re-used these 4 placeholders to create the entire level, with different them being in positions and rotations. Before creating any new designs however, I first re-created Shakir’s initial level made with tile maps into one using placeholders. I also requested the moving of a key. I felt that the player needed some incentive to learn the mechanic, as up until this point the entire game had been based around fire and ice. The player would have no idea it was about dimension switching in general. So I put the key just above the player, but in the Void Dimension, so that they would try and jump and switch together. This was to try and make them learn the mechanic of the uncontrolled zero gravity.

Once I recreated the existing level, I began drawing up my own designs. It would be assumed by that point the player had come to understand the mechanic more, I could start to add some more interesting puzzle elements to the game. By the end of the week I made a few extra rooms, involving puzzle solving. The last of which made more use of the melee enemy. During the level I made use of  ‘Void Objects’ which exist in both dimensions. Straying too far from the desired path, or easily skipping parts of the level.

I was very much trying to optimise the amount of art assets that needed to be created for this level, hence why the environment consisted of just 4 reused objects. I also did my best to not add too much more in terms of features, and re-used the ice spike assets but coloured differently to represent Void Spikes. 

Week 11(5/12/22 - 11/12/22)

For our final week, I assisted John in getting Level 1 dialogue in completely. By this point though he was getting quite competent with the use of Fungus for in level implementation and didn’t need my help.

We also had the death timer ready that kills the player after a set amount of seconds. We decided upon 3 seconds after testing it in the level, and this worked quite well. There were still a lot of unimplemented animation and art assets as well, so I did my best to ensure these got added properly. I didn’t want any of the artist’s work to go to waste.

Nearing the end of the week, we finished up the entire story and dialogue of the game, with the inclusion of level 2. John was adding in the dialogue based on his Story notes, as I assisted in some areas with Unity if needed. We decided in the end on him having a short encounter with his boss with him being late to work at the end, and then he wakes up. Revealing that it was just a dream.

We also managed to replace the canyon placeholders I had with work that Angie made, since I suggested the idea of recreating my placeholder’s shape exactly; it meant it could have saved her a lot of time. However, I felt like I was partly taking away some of her freedoms with her just making an improved version of my placeholder. The decision was up to her though and so that’s what we did. The entirety of level 2 was made with 4 canyon prefabs. I wasn’t sure if my suggestion for doing that was good or not in terms of visuals, but it seemed to solve a lot of issues regarding time and functionality.

One thing we failed to do this week though was follow scrum properly by releasing a build to be playtested. In future we will ideally have a project manager who will be making sure of these things.

Week 12(12/12/22 - 13/12/22)

On the final day of development, we finished off by adding freezing of the movement to the dialogue, final art assets were added in, and any small adjustments to the level were also made. I finished off by ensuring the game would close after the story dialogue had concluded, and added in a pause screen containing a quit and retry button. This meant we were covered if there happened to still be any issues which could soft-lock the player. After that all that was left to do was upload the project. 

Overall in conclusion, I learned a lot about working in a collaborative environment, and the importance of communication in a larger group. In future projects I will look toward communicating my design decisions more, and write down any decisions in a Game Design Document Early on to allow better large scale communication. 

EVIDENCE OF WORKING IN A COLLABORATIVE INDIE GAMES ENVIRONMENT