Week 8: Intellectual Property

This week, I spent all my time reviewing the codebase, organising what we had produced, revisiting the CI/CD pipeline, adding new assets and creating new items for the game. On teamwork, we had some friction over the description and status of the activities. 

Group contributions: combat reviewed, scene structure and many assets

This week, the first contribution that I made was to organise the codebase so Dan and I could work together. In this direction, we opted to maintain the structure clean and having only a root structure in the Asset folder with a separation of Scenes, Assets, Models and a particular folder named _thirdParty that contained the external assets used. 

Related to the third party assets, I also included an external library that contained a lot of low poly models to be used at the scene composition. I believed that having different assets would make Dan’s life easier when designing the first game scene. 

In our agreement, I would be focusing on building the internal logic for the gameplay. Inventory system, weapons, items, menus and controllers would be my responsibility, and Dan would work on designing the game’s first scene.

I don’t know if it was somewhere this week or the previous week that I suggested that Luke works with 3D models since he was more comfortable with this art style, and we also started to receive those models. This decision was challenging to me because I don’t have much experience working with 3D models. 

Despite all the work executed, I wasn’t moving my tickets at the Jira board, and at the beginning of one of ours team sessions, Nural emphatically complained about that. He was frustrated by the lack of vision of the activities progress. I attempted to explain where we were and proposed some action points. However, this was not a good session, and I felt frustrated with the misalignment of communication or how we dealt with this communication. 

Some of the action points were reviewing the opened tickets, and I did it to maintain them as clean as possible. I also finished a central review of the Game Design Document session on Confluence. However, I was not too fond of the result. My perception is that document was used only by Dan and me. I thought this was the result of my previous focus only on Machine Learning research.

Linda was finishing the menus and UI components for the game interface. And we started to apply more effort to the story construction.

Personal development: game feel and feedbacks

Over Unity, we were using an additional layer of code focused on top-down shooters. It gave us a lot of resources to explore and build our game over it and consequently gave me some homework to study it. I found some best practices of organisation and separation of code. In particular, the folder structure got my attention to hold some symptomatic problems in commercial software development, explicitly screaming architectures. The organisation of the folders structure was reflected much more the content than the goal or purpose. As a small vertical of a game project, I believe it will not incite any problem, but it is curious to see some aspects of different worlds reflected.

Besides the code organisation and review of best practices, I got motivated to add a reaction to each player action. So I started reviewing the feedback related to the shoot: camera shaking, sounds, and particles became a playground. The Game Feel book influenced me, so I reduced the intensity of the original feedbacks that we implemented less ambitiously.

Conclusion: moving on

Document and maintain my activities is a challenge. I felt that I was getting used, but I left a lot of bullet points to fill later. It implied a lot of effort and lost content. I shared the same frustration with Nural about the vision of progress. However, I’m much more concerned to learn as much as I can than focusing on what I should or not display to the rest of the team. This difference of goals might be harmful, and I don’t want to be an offence to the team progress. This friction might be a problem; from a personal perspective, I will do whatever I can to help produce the game, but I will not invest any energy to please any team member.

I had some work with the code base, the understanding of the best practices and how to organise the code took much more time than I expected, but I made possible the teamwork.

I’m not comfortable using Git as the version control system. The LFS deals with files managed as binaries and don’t have internal version control when working with them appropriately. I chose not to work in the same scene as Dan to avoid conflict, and we still missed some temporary files in the “.gitignore” file. For the following projects, I’ll give a chance to a different versioning system.

And finally, despite the usage of third party content in the production of the game, I had some difficulty finding it helpful at the week’s content. I know their importance, but I question myself if it makes sense their protection for a low-sized game IP. So instead, I rather invest a small budget in producing some asset that will positively impact the gameplay experience or awareness than necessarily protect them.

References

‘7 Ways to Keep Unity Project Organized: Unity3d Best Practices – Blog’ (2021) Juego Studio, 21 January. Available at: https://www.juegostudio.com/blog/7-ways-to-keep-unity-project-organized-unity3d-best-practices (Accessed: 13 October 2021).

Clean Coder Blog (no date). Available at: https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html (Accessed: 13 October 2021).

‘Game Feel’ (no date). Available at: http://www.game-feel.com/ (Accessed: 13 October 2021).

Prabhu, S. (2018) ‘Unity3D Best Practices: Folder structure & Source Control’, ARreverie Technology, 3 June. Available at: http://www.arreverie.com/blogs/unity3d-best-practices-folder-structure-source-control/ (Accessed: 13 October 2021).

Technologies, U. (no date) Unity – Manual: Best practice guides. Available at: https://docs.unity3d.com/2018.4/Documentation/Manual/BestPracticeGuides.html (Accessed: 13 October 2021).

‘Unity3D Best Practices | Glen Stevens’ Thoughts’ (no date). Available at: http://www.glenstevens.ca/unity3d-best-practices/ (Accessed: 13 October 2021).

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s