Reflections: A Post-Mortem

The following is a post-mortem for my game, Reflections. You can find the game here.

Reflections is a game based off of an artwork that I saw on my trip to GOMA (Gallery of Modern Art) called Lightning For Neda, by Monir Shahroudy Farmanfarmaian (further info on another post here).

In Reflections, the player can bounce colourful lines off of the mirrors that they are surrounded by. The longer the player charges the line, the further the line travels. There is no specific goal or objective in the game, just expression. The player can shoot lines of various lengths and various colours in order to make abstract art.

The most challenging, and most rewarding, part of this project was making sure the lines bounced correctly. The way that the game works out where to reflect the line is by Raycasts and RaycastHits. A Raycast travels in the direction that the player is looking, until it hits an object tagged ‘Mirror’. When it hits, the ‘normal’ (a Raycast that travels perpendicular to the object) is recorded. The code then figures out the angle difference between the incoming Raycast and the normal, then shoots an outgoing Raycast on the opposite side of the normal at the opposite angle.

I’m quite happy with how the mirrors turned out. Using a Render Texture on a Plane and a Camera behind the plane has given the effect of a mirror. An important thing to note is that each plane needed its own Camera and its own Render Texture assigned to it.

There are actually a few things that I would like to improve, if I had more time. Most importantly, I would have liked to change the lighting. As it stands, the mirrors only reflect well when they are set to emit a blaring white. I would of liked to have a setting, that the player could change, that could make the background lighter/darker. For now, the player must shoot lines in a white space.

The next thing I would fix in the game is a small bug in the controls that I wasn’t able to fix. When the player charges a line, there is a small chance that, when the player releases the button, no line shoots. It isn’t gamebreaking, but it is a little frustrating when charging a line.

Finally, the Colour Randomiser that I put in place, which randomises the colour of the entire line when the player shoots a line, has a tendency to select white over all the other colours. While removing white from the list of colours is the easiest solution, I would prefer to implement some sort of weighting on the Randomizer. That way I can keep white, which would be a very powerful colour if I was able to change the lighting.

Advertisements

Conscious Grasp: A Port-Mortem

The following is a post-mortem on my game, Conscious Grasp. You can find the game here.

Conscious Grasp is a game made solely by me over a two week period. The game attempts to create a feeling of disorientation and being lost, eventually finalising with a sense of belonging.

The inspiration for this game came from the earliest memory that I have. The first thing I remember is opening my eyes in a park, facing the playground. The park was not familiar to me but, as I turned around, I saw my parent’s house. I don’t know how I knew that that was my parent’s house. I just knew. I walked from the park, across the road and into the house, all around the age of 3.

To try and evoke the feeling of disorientation that I had in the park, I created a map that has tiles added and removed through a script. This means that there is a form of randomisation. When a player moves a set amount in any direction, a row of three tiles will be spawned ahead of the player and a row of three tiles will be removed behind the player. This results in a map that is constantly changing, even when the player doubles back. You can read more about the programming behind it here.

I’m really happy with how the tile spawning system turned out. I started this project without too much programming knowledge, so I am glad that the system works as well as it does. The system uses a list of tiles and can be expanded just by making more tiles and adding them to the list. It has a lot of potential and, if I had more time, I would of have made more tiles in order to add more variety into the map.

If there is one thing to improve, it would be the fog that obscures vision. It’s purpose is to hide when tiles are spawned but visually, it looks very ‘hacked’ in. There is too much contrast in light between objects in the fog and objects out of the fog. If I had the time, I would remove the fog and the directional light then replace them with a spot light that looks in the same direction as the player. This would create a similar, view limiting, effect but would be less obvious than the fog.

 

Project 3 – Post-Mortem

For this third and final project of Studio 1, some of the students in the class were split into teams of three while some students opted to do this project by themselves. I was in a team that consisted of Ben, Ruby and myself. The project required the class to brainstorm as many verbs as possible. Then all the verbs were gathered together in a single document and discussed amongst the class. It is after this that the teams got together to discuss what game they wanted to make. However, there was a caveat. This caveat was that the game must be controlled with a single joystick and a single button. The single button must perform the verb that the team has chosen.

Our team selected the verb ‘Boast’ and decided to make a game in which the player must navigate around a city and boast to people who are smaller than them. Every time to boast to someone smaller than you, your head gets bigger. This, in turn, makes it harder for the player to navigate the level.

 

What Went Right:

Teamwork:

The team used Discord to communicate with each other throughout the project. Since it is available on both computer and mobile, team members were able access each other whenever it was needed. It was an excellent way to communicate who was working on what and when they were going to be working on it. Source control was also very easy since we would be able to determine when people were working and when people were committing their work. As a result, we never encountered a problem that required us to regress to an earlier version of the game.

The reason why this happened was because all members of the team were very willing to communicate with one another and were transparent when it came to their availability. Each member of the team, at one point or another, had approximately one whole week where they wouldn’t be able to contribute to the project and that was told to every other member of the team as early as possible. This allowed the other team members to prepare for the decreased output of the team and adjust the plan accordingly.

What I can learn from this is that communication is the key to a good project. Even though the project is incomplete, but submitted regardless, the team was happy with what they achieved. Being able to adjust plans as early as possible and assign work to different people as need be was a great advantage. With good communication we were able to manage members’ expectations while maintaining a positive attitude.

 

What Went Wrong:

Communication w/ Collaborators:

For this project the team collaborated with an Animation student named Hayden and an Audio student named Bronte. The team met with them both within the first few weeks of the project and discussed the game, as well as what deliverables the team would need from each of them. After that meeting, all discussion was delegated to emails and it was at this point that things started going downhill. While the team did receive the assets they needed, some required adjusts and it took days for that information to be received.

The reason why this happened is because emails were sent every few days, meaning that it wasn’t possible for a reliable and quick response from any of the involved parties. This resulted in delayed feedback and adjustments. This delay could last anywhere between a few days to a week.

What I can learn from this is that all members of the team, either internal or external members, need to use the same method of communication. The internal team (Ben, Ruby and I) had excellent communication but the external team (Hayden and Bronte) didn’t. Including the external team into Discord and Hack n Plan would allow them to work autonomously, thus removing the need for email and removing the delay in communication. This would also allow the external team to see who is currently working and enable direct messaging and notifications for faster responses to feedback and more.

 

Work Backlog:

The team entered the project with work remaining on previous projects. This left each team member essentially working on at least two projects at once. Having the team’s’ attention divided didn’t help Project 3 and led to the team running out of time, therefore forcing them to stop working on the project before it was able to be completed

The reason why this happened varies. Each team member might have different reasons for having work left over from projects. At the very least, Project 2 still had work that was left for Strike Teams to complete and each member of this team was in a least one Strike Team.

What I can learn from this is that people will have their own work to do outside of projects that they work on and, if need be, that work should be considered into the planning of the current project.

Project 2 – Post-Mortem

For the past few weeks I have been working on a board game with three other people. As of this week, the major portion of this project has been completed. All that is left for my team and I to do is some minor tweaking to gameplay. Other elements, such as card design, token creation, filming crises, etc, will become the responsibility of the Graphic Design Team and the Film Team. There will, of course, be communication between all teams, but it is closely approaching the date where, after which, no more changes can be made because production would have already started or be near completion.

 

What is this project?

This project involved a class of fifteen students who created a board game that would operate as a common base. These fifteen students were then broken up into four teams, with each team required to make a different scenario that would introduce their own additional rules to the base game.

 

What went right:

Communication:

The team used Discord as their main method of communication. During the planning phase of the project, everyone in the team contributed and shared their ideas. Then, throughout the rest of the project, the team was willing and able to cross-check their work with each other.

The team’s success in this area relied on all members being frequently available and open to discussion. There was never a need for emergency contact because team members promptly replied to messages and were always available for online group meetings.

 

Organisation:

Tasks were created and distributed amongst the team members. The team utilised Hack n Plan after every meeting. On Monday and Wednesday, during our in-person meetings, the team created a list of tasks that must be completed before the next meeting. Each task was broken up into smaller, more manageable tasks that could shifted between members of the team if required.

The reason why the team was successful in this aspect is because of competent task breakdown and distribution. Each team member was in charge of a certain aspect of development and would have all tasks that related to that aspect assigned to them. However, the workload of some aspects varied throughout development so, in order to get the most out of every member, people with little to no work to do had tasks from the other aspects of development delegated to them.

 

What went wrong:

Delivery:

The team rarely had all our prototype cards ready for playtesting on-time. While the team had created all the cards, they were not printed. Therefore the team had to spend time printing and cutting all of the cards before they were capable of playtesting. This means that, instead of being able to run two playtesting sessions, there was only time to run one.

What caused this was the date that the tasks were completed. While the team did well in allocating tasks amongst team members, most tasks were worked on and completed over the weekend. This mean’t that the cards and other items that the team had created were typically printed out the next day. Unfortunately, more often than not, this mean’t that the team’s intention was to print the cards before the meeting and arrive to the meeting with all the prerequisites ready. However, there was always a problem and everyone would arrive with none, or very few, of the prerequisites required for the game.

Setting deadlines for each task and/or having ‘Printing’ as a task, in the Hack n Plan, would of helped to mitigate the problem and would have allowed for a smooth transition between group meeting and playtesting.

Project 1 – Post-Mortem

Project 1 involved each student receiving an artist to research. Each student must then adapt the game Berzerk (Atari) to their given artists’ style. I was given Harriet Powers, an African-American woman who made quilts depicting biblical stories in the late 19th century. I decided to adapt Berzerk by using the panels of Powers’ quilts as levels in the game. I used Unity to create this project.

This was the first project of Studio 1, which started development in early February and ended in late February. While I was supposed to submit the project at the end of February, I held off on submitting it in hopes of being able to continue work on it later. Unfortunately I didn’t have much free time over the trimester to work on this project, so not much progress was made.

 

What Went Right:

Art Assets:

For this project I decided to create all of the assets by myself. I managed to make all the art assets that I needed and I even added some animations to the player and to the enemies. It felt great to branch out and expand my skillset. I learned how to use Pyxel Edit for sprite work and sprite animation work.

The reason why this happened was because, over the holidays, I took an interest in a certain aspect of streaming culture. That aspect being fan-art. A streamer that I was watching had 2-3 people in their chat that would occasionally draw quick pieces of fan-art. I saw it as an interesting way to improve skills as well as contribute to a community. So that inspired me to find programs that I could use. By the time uni came around I was excited to use those programs for my projects.

What I can take away from this is that finding a passion outside of profession can positively impact my work, especially if that passion could be used in my profession. Also, I am typically very lazy after coming back to uni after the holidays. However, since I found something productive to do over the holidays, I maintained the working mindset while still enjoying myself.

 

What Went Wrong:

Prioritization:

I spent a lot of time creating all the art assets and, unfortunately, I didn’t leave enough time for the rest of the game. So, when the time came to move on to the next project, I was left with 11 levels but little gameplay. What’s worse, because of how I set up the levels, when I came back to the project it was hard to add the work that I had done to the first level to the rest.

The reason why this happened is because I didn’t have any planning or management properly set up and let my eagerness to create assets supersede the other aspects of game development. Since there was no plan in place, it was hard to estimate just how long it would take to make all the assets. When all the assets were done, I was left with very little time and not much else to go on.

What I can take away from this is that I always need to set up a plan before working, regardless of the amount of work that I need to do. It will help me remember what needs to be done as well as prioritise work by its importance.