HOME
SEMESTER 1
SEMESTER 2
TO BE CONTINUED...

Project Reflection: Team Communication, AI Use and Responsibility

Firstly, I believe the final outcome of this project was successful. Although there were several communication and collaboration issues during development, the game received mostly positive feedback during the playtest. Players were able to understand the core mechanics and responded positively to the atmosphere, interaction design, character presentation, and overall level of completion. From the final result, our team successfully produced a complete and playable game.

I also believe that every team member contributed to the project. Whether through visual assets, character design, scene content, gameplay systems, testing, or final adjustments, everyone’s work helped the game gradually take shape. Therefore, my intention is not to dismiss anyone’s effort. This reflection is not about proving who did more work, but about discussing the communication issues, responsibility boundaries, and my own immature handling of the situation.

The main conflict came from my use of artificial intelligence to generate and adjust temporary narrative content. I acknowledge that this was not appropriate. Using AI to edit another team member’s writing without clear permission, even for testing purposes, was not an ideal way to handle the situation. In a group project, each member should have basic control over their own creative work. Even if I believed the text needed to be adjusted, I should have communicated with the original author first, rather than using AI to change or replace it directly. This is something I need to take responsibility for.

However, I also need to explain my motivation at the time. My intention was not to replace the member responsible for narrative, nor was it to take credit for the narrative work. In fact, it was not that we had received no story content at all. The issue was that the story text we received was clearly disconnected from the actual game. It functioned more like an independent piece of writing, rather than content that matched the player’s route, task flow, item collection, NPC interactions, and trigger conditions.

This directly affected system testing. Our dialogue system was not simply a text display feature. It also needed to show dialogue options correctly based on player choices, and connect with task progress, item detection, NPC states, and interaction conditions. If the text was not structured according to the game logic, or if the dialogue options could not be displayed and triggered correctly, many systems could not be properly tested. Therefore, I temporarily used AI to fill and adjust the text needed for system testing. My main purpose was to keep the dialogue, task, and interaction systems moving forward, rather than to replace someone else’s narrative creation.

In fact, I had already provided clear direction and materials during the early stage of the project. The member responsible for the narrative had also recorded in the memo that the story needed to cover specific task content, which later became the Berry task and the Map task that we actually developed. Therefore, the new dialogue should not have functioned as a separate piece of storytelling. It needed to have a clear logic that guided the player towards these two task points and helped trigger the related minigames.

On 3 March, I provided a storyboard script for the opening forced dialogue, as well as the related voice-over text. The purpose was for the member responsible for narrative to continue developing the storyboard script and narration based on these materials. However, after that, I did not receive any substantial outcome. By the time of the playtest on 19 March, we still did not have content that could be directly used. Since the opening forced dialogue had also become overly long and would require a large amount of development, integration, and testing time, we eventually decided to cut this section down.

After the playtest on 19 March, I provided another test script for the opening forced dialogue. This was used to demonstrate how the text should be structured and connected to the game logic. The purpose of this script was not to replace the narrative member’s work, but to show how the dialogue needed to work with the task flow, trigger conditions, and system structure. The member responsible for narrative also responded at the time that revisions would be made. However, after that, we still did not receive any genuinely usable update for a long period of time. It was not until 27 April, when I could no longer wait and had to ask again in the group chat about the narrative progress, that he began working on the script.

I did give feedback and direction. I explained what content was needed, pointed out that the writing needed to connect more clearly with the game system, and created detailed documentation to explain the existing structure of the game. The member responsible for narrative also promised to make changes. However, after that, a long period passed without me receiving any truly usable update. The final text that could actually be used was only delivered three days before the playtest, and even then, it was only handed over after I chased for it. Before that point, the text could not be properly connected to the game system.

Therefore, the issue was not that I had never communicated, nor that I suddenly wanted to interfere with the narrative work. I had provided direction, examples, and a testing structure, and I had waited for revisions. However, the relevant content was not progressed on time for a long period, which left system testing and later integration in a passive position. My use of AI was a mistake in terms of how I handled the situation, but it also reflected a longer-term issue around communication and delivery within the project.

This also revealed a deeper issue: the member responsible for narrative had almost never actually opened the Unity project or used the engine to understand the real state of the game. As a result, he lacked direct awareness of the interaction flow, task structure, inventory system, item detection, and newly added content. For game narrative, this is not a minor issue. Narrative is not writing that exists separately from the system. It needs to connect closely with player behaviour, NPC responses, task triggers, and in-game items. If the person responsible for narrative does not engage with the project itself, it becomes difficult for them to judge whether their writing can actually be used in the game.

Another issue also reflected unclear communication around responsibility. After the final playtest had already ended, the member responsible for narrative stated that the descriptions for the item icons should originally have been his responsibility, and questioned why the team had not assigned this task to him. However, by that point, the relevant items, icons, interaction logic, and description text had already been organised and integrated into the game for testing and final presentation. Therefore, raising the issue of responsibility only after the work had already been completed did not meaningfully help the project move forward.

I do not think this issue can simply be understood as “why was this task not assigned to him”. In a team project, task allocation is not based only on what someone wants to do. It also depends on reliability, delivery, and project risk. If a member has not completed their original core responsibilities for a long period of time, and has not provided consistent progress updates, it becomes difficult for the team to continue assigning them tasks with a large impact and unpredictable outcomes. This is not about denying their ability, but about the need for stable delivery and timely communication in game development. Especially close to the testing stage, the team has to prioritise key tasks for members who are actively engaged with the project, care about the overall progress, and can update others clearly on their work.

From my perspective, if a certain area is genuinely part of someone’s responsibility, the more effective approach is to engage with the project earlier, understand the current state of the system, and actively suggest specific tasks they can take on. Teamwork should not rely on other people constantly assigning tasks, nor should responsibility only be claimed after the work has already been completed. A more constructive form of communication would be to ask earlier, “What does the project need now, and which part can I specifically help with?” rather than questioning why the task was not assigned only after the result had already been produced.

During the project, there were also repeated delays in the delivery of narrative content. Some work only started after we asked several times, or was promised for a certain date but still delivered late. The reason given was procrastination. I understand that everyone can struggle with time management or creative blocks. However, when procrastination happens repeatedly and begins to affect the development rhythm of other members, it is no longer just an individual issue. It becomes a teamwork issue. Especially in a group of only four people, one person’s delay can directly affect other members’ system integration, testing schedule, and revision time.

There were also new additions made later in the project without enough prior discussion. For example, close to the playtest, the dialogue text included new items and interaction ideas that were not part of the original plan. In game development, adding a new item is not just about writing one more line of dialogue. It can mean that task logic, interaction conditions, inventory checks, NPC dialogue triggers, and even art assets need to be adjusted. Because these additions appeared very late, other members had to create related assets quickly and integrate them into systems that were already mostly complete.

A similar issue happened with the multiple character portraits and expression states. Objectively, these portraits and expressions did improve the visual presentation of the game, and they made the dialogue system feel more complete and engaging. Once implemented, the result was effective, and I recognise that value. However, the problem was that these assets were added without enough prior discussion, while the more essential narrative text had still not been completed on time. In order for the multiple portrait states to actually work in the game, I had to spend extra time adjusting dialogue tags, character state switching, and UI display logic. This feature was not part of the original plan, but it became something that had to be integrated because the new assets had been added.

Therefore, the real issue I want to point out is not that I did extra work, nor is it to deny the value of these additions. The issue is that creative additions in a team project need to be based on completed core responsibilities and clear communication in advance. One person’s sudden idea can easily become extra work for the other three members. If the team does not discuss which systems will be affected, which assets are needed, and whether the change will reduce testing time, then even a good idea can disrupt the development priorities of the whole project.

This experience helped me understand the difference between “completion” and “effective contribution”. In a team project, submitting something on the final day and submitting it during the normal development period can both appear to count as completion, but their impact on the team is completely different. Game development is a continuous process. One person’s writing, assets, or systems often affect other people’s code, UI, task logic, testing, and final integration. If a piece of content only appears at the final stage, even if it is eventually included in the game, it may already have reduced the time available for other members to test and improve their work.

Therefore, I believe contribution in a group project should not only be judged by whether someone eventually submitted their work. More importantly, it should be judged by whether the work was delivered on time, whether it met the actual needs of the project at that stage, whether it could be used directly, and whether it reduced pressure for the team or increased integration costs for others. If a piece of work is delivered late, requires repeated reminders, and still needs others to spend a large amount of time fixing, completing, and integrating it, then it cannot simply be seen as a complete and effective contribution.

Of course, I also need to reflect seriously on my own mistakes. First, I should not have used AI to modify or replace another member’s narrative content without sufficient communication. Even though my motivation was to test the system and move the project forward, the method was still not appropriate. A better approach would have been to clearly explain that the existing text did not meet the needs of testing, and to discuss a solution directly with the member responsible for narrative.

Second, I should not have kept using my own extra time to compensate for work that had not been completed or communicated properly, simply because I felt uncomfortable raising the issue. Although doing this helped the project move forward in the short term and made the final result more complete, it blurred the boundaries of responsibility. On the surface, the problem was solved, but the real collaboration issue within the team was not addressed clearly enough.

This experience taught me that politeness in teamwork should not be based on silence and tolerance. Responsible communication is not about avoiding conflict. It is about making the situation clear before the problem begins to affect the whole project. In future projects, if I face a similar situation again, I will raise problems earlier, record more clearly which content cannot be used, which content has been delayed, and how these issues affect system integration and testing. I will also be more careful with the use of AI tools, making sure they do not cross the creative boundaries of other team members.

Overall, this project taught me more than how to complete a game. It also taught me how to communicate more clearly within a team, define responsibility boundaries, and manage development priorities. Creative expansion is valuable, but it should be based on completed core responsibilities, prior team communication, and a realistic understanding of the project’s capacity. A truly effective contribution is not simply “I finished it in the end”, but “I delivered usable work when the team needed it, and helped the project move forward.”

↑ BACK TO TOP

@ KEVIN LIU WSA GAMES DESIGN AND ART