Last year, we used GitHub for version control, but this caused several problems for us, the most pressing of which was that a distributed model doesn't work well for the non-mergable binary assets that constitute the bulk of a Blueprint-based UE4 project. In the Spring, I learned and deployed Perforce Helix with my studio course, and I decided to go ahead and use that for this semester's game programming course as well. It was a little choppy to get started as I had become rusty with some of the core configuration. My first pass involved making one depot per team, but I my conceptual model of workspace mapping was wrong.
When I spent several hours trying to rebuild my understanding of Perforce Helix and how to integrate it with the course, I realized that I could get away with one structured depot. This depot was called
CS315Depot, and I wrote up instructions and recorded a private YouTube video explaining how to set up the mapping. One of the crucial steps that I had forgotten was not to use the graphical mapping tool in P4V. Instead, we used the text-based mapping specification, so that if I was working on a Project 1 ("P1"), then I would make a workspace called PaulGestwicki_Laptop_P1 and use my UE4 project as the project root. Then, I use a mapping to the depot like this://CS315Depot/P1/PaulGestwicki/... //PaulGestwicki_Laptop_P1/...What this does is map all the files in my local workspace to the folder
P1/PaulGestwicki on the depot. The real magic, then, is that when I want to grade the first project, I can make myself a new workspace, something like PaulGestwicki_Laptop_GradingP1 and map it to the whole P1 directory://CS315Depot/P1/... //PaulGestwicki_Laptop_GradingP1/...In one action, I can grab all the student projects into my workspace and then batch-grade them, without having to make N trips to the depot or create N different workspaces. Also, I could easily set up one group (CS315) for all the students and give that group write access to the shared depot and read access to my depot of demos. Note that this does mean that students can check out each others' projects, which I am happy to support; it also means that they can accidentally destroy each others' work, but that's why we have version control in the first place.
One of the common errors I saw with several students was that they forgot the last slash in the mapping, which ended up with them dumping their Content, Config, and .uproject files into the root of the P1 directory, prepending their usernames to each file. Some students recognized the problem, and I was able to just obliterate their old files so they could try again. Because it was so easy to recognize the error by glancing at the depot, I was also able to email students and point out where they had unwittingly made a configuration error.
Perhaps this idea will be useful to you, dear reader. In any case, I hope it will be useful to future-me in case I forget how to do such a thing in the future! I offer my public gratitude to Perforce for their academic licensing that allows my students to use their software, and of course, gratitude to Epic for the very generous licensing of Unreal Engine.
UPDATE: When I went to adjust some grades the other morning, half the projects were gone. I looked at the changelog history, and I found one that looked suspicious. It touched every file in the depot, which makes me think they had a mapping wrong. What was really strange to me was how this affected the tools themselves: when I viewed the project in p4admin, I could see all the files I expected; when I viewed in p4v, half the student folders were gone and could not be mapped. I am still quite perplexed about what could cause this. However, the good news is that after I backed out that changelog, everything ended up back where it was supposed to be. Version control for the win!
No comments:
Post a Comment