Post-Mortem: First workshop "Magic Doors"

[EloiStree]

For three weeks, we did a workshop with the Belgian students of Technocité call Magic Doors.

The workshop was a success, I am planning to re-iterate the experiment. This post is a postmortem to make a review of how it happens. And how to improve the next workshop.

[EloiStree]

What is Magic Door ?

https://youtu.be/KD47s4uWAIw (Not the last version)

[EloiStree]

What was produced at the end ?

https://youtu.be/K0l-NOrVU0c Downlaod the game:
https://eloistree.itch.io/magicdooratelierdegroupetechnocite

Video

[EloiStree]

What went well ?

• Git is more easy to understand for artist in the package manager that in a classic Unity project because they are alone in the git and they don't need to gitignore directly. Leading them to assimilate the complexity of git later on.

[EloiStree]

What when wrong ?

Sample scene

• If you don't delete the sample scene. Participants use this scene then move it in the package. But they have all the same id. Meaning that when you import the packages, only one is randomly accepted. Creating panic situation ;).

  Meta GUID duplication

• If you copy past or export a asset to an other package. They have the same GUID and it create bug and warning message in your project. Means that you need a tool change the GUID if you want to have this duplication or to avoid then.

  Workaholic

  If you are workaholic and you work after work or the weekend. You can work on the code of your team as you don't have permission to do so. Your only option is to fork the code of your friend. Remove his package and add yours.... Or to wait patiently. That can quickly lead to problems.

Licensing

Some participants did not understand that they could create dependency to paying asset on the store. Leading them to put some asset in the package that was public for the project. (We deleted the package immediately).

[EloiStree]

What do I tip you to avoid?

• Put the same shader in several pacakge

What do I tip you to do?

• Make "Pattern Package". A package that illustrate the pattern you want the team to respect for their package to work on. That can be folder structure, file names, color library...

[EloiStree]

What I learned ?

Always evolving

• Work with package manager means working with alway evolving tools:
  • Discipline is very very very important. And hard.
  • Use http://GitLink.git#commitid is very important to lock a version to share with the community because
  • As soon you have follower on your project you need a public/indevelopment branches and commits dependance links between packages.

You need plenty of tools

To reduce the time lost when you do the package or when you use the package, you need plenty fo tools. And that request a learning curved and some tools that don't bug. Else you start losing a lot lot lot of time.

80% Package 10% Project 10% Bridge Script

More you use the package, more you start truning your project in a link of package that are linked to the small part that is creating your project.

But the weak point of that is that you start to transform everything you do as a package. Lot's of bad stuffs happens with that (Explain later). Main weakness of that is that when you want to update a small part of the game. It takes 2-4x more time that your team need you to do it.

Pierre Gueran gave a good tips & trick about that: "Don't do a package directly in the project. Start by doing the code for your team. Next project you required the package. Start to schedule to package it."

Fork

How and why you should use the power of Fork in the project.

Correction

During the weekend, the participant are not available. So if you want to change the code, you have only one option.

• You fork the git package of the participant.
• Correct the code of the participant
• Create branch call "Correction..."
• Send the branch to the participant for him to validate it later
• Create a new branch on witch you continue to code in the waiting of the participant validating the code or refusing it.
• Use your fork instead of his code until he is available again. I don't know if it is the best solution. But at least it allows you to continue coding and to offer correction to the students code that may not work on it but is still interested for review of his code.

Risk of rage quit.

During the end of the project. I know it would not happens, but I was sitting on a new dilemma. "What would happen, if a student in the future set it project in private, move it, or remote it from the server ?" As soon as you update your project, you have error that would appear, the time you understand what is happening, you will probably lose the copy of the local code of the user and your project is screw...

So what do you do in this case ?

1. Try to understand it soon enough and copy the package in the temp folder.
2. Try to make a fork of the project and update it regularly just in case.
3. When you are sure that you won't update it in the future. Just stop using it as a package and import it as a tool in your asset folder.

I suppose there are other solution. But for the moment it is all I have in head.

[EloiStree]

Experiment

Google Sheet to synchronize the team work.

Group workspace: Google Sheet To be able to synchronized the group, we used a google sheet where people can comment the link of their assets. The project leader check some time to update the google sheet and refresh the page with comments.

[EloiStree]

The workshop

Before we start, the workshop scheduling was not to teach only the package manager but the virtual reality to participant that don't own virtual reality.

You can find in the following part, the scheduling given to participant durant the workshop. In future version, more space should be given to design and coder. And the workshop should be shuffle and not split as we did if we want to have a game and not a portfolio application. ;). That my bad. The workshop what not plan as a workshop group work at it before COVID construction.

Google Sheet: List >

Art

Day 1 - Day 2 - Day 3 - Day 4 - Day 5 - Day 6

• Workshop
• Hello Package Manager
• Magic Doors project

Code

Day 1 - Day 2 - Day 3 - Day 4

• Request 2 artist
• Proposition 2 Developer