I am new to the playcanvas community and am coming from a team that has been using Unity to develop mobile games. We are considering PlayCanvas for a potential project and my first question is how best to structure the project team and associated tools to work best with PlayCanvas (and the online Editor).
I will have artists, designers, producers and engineers all needing to collaborate on the project and we currently rely on versioning, local build capability and an offline editor (Unity). At our studio everyone has a version of Unity locally installed and maintains their own branch of the project where they can work on specific tasks related to their discipline. Local changes are recognized by git and branches can be merged, code reviewed, etc.
I see after doing some initial research that we need to rethink how we would manage a team developing on PlayCanvas (given the online editor, no version control, etc)… so my question, is if someone who has worked on a large scale playcanvas project and/or has come from a Unity/Unreal development environment can help us understand how teams using Unity might change their tools/workflows/habits to work best with PlayCanvas? Any advice would be greatly appreciated! Thanks!
PlayCanvas are in the process making it a lot easier to work in larger teams. I don’t know when it will be finished but it may be worth emailing them since you have a large project planned.
Right now, it’s pretty ideal for smaller teams (1 developer, 1 or so artists etc) and doesn’t scale easily. Only whydoidoit has engineered a way unofficially working in a developer’s traditional workflow. I don’t know if it still works: TEMPLATE: ES6 | Version Control | NPM | PlayCanvas
Several ways I can advise with:
- Don’t use the editor beyond converting and exporting models, materials and textures. Use the engine directly without the editor and write your own scene editor/parser.
- Or go heavy on the communication. Have a trunk project on the PlayCanvas service that no-one works directly on, fork it when working on features, once the feature is done, ‘lock’ (via communication) the trunk and clone the changes to it. Keep the changes as small as possible and ‘merge’ often. Effectively abuse the fork.
- In terms of version control, if you have the ORG plan, I’ve used the REST API to export the project and commit to source control. I’ve got a Python script that does both the export and the build and gets it ready to commit.
None of this is ideal and at best are workarounds.
How big is the team and the purposed project?
Thanks so much for the quick reply and helpful info! Bullet #1 seemed like a solution to us as well, but not ideal and Bullet #2 is something we have also been considering - building “heavy communication” into workflows/process. We will definitely use the ORG plan so its good to know you can export the project and commit to source control that way (we also would probably write scripts to facilitate that). I did have a chance to read through whydoidoit’s unofficial solution and its probably something we would test out initially (while understanding it would not be officially supported so we’d probably have to maintain our own implementation or deal with the risk associated with using it)
The team will be about 12 contributors across art, eng and design and the project scope and requirements are still being discussed (so nothing definitive there).
I will see if I can email playcanvas to get more into about how they plan to make it work better for larger projects/teams.
Thanks again for the info!
Eep. 12 people on the same project is going to be ‘interesting’.
Pair programming/working will help a bit here if it’s something that the team is comfortable with. It’s really only the coding side of things where there’s problems scaling due to the nature of ‘Google Docs’ style workflow.
I’ve done the ‘fork’ method and manually merge into the main project once I’m done on projects as an individual if I need to tinker with a project or investigate an issue without screwing the main build.