What I want to do is as follows, what is the recommended way?
- Manage code and asset with version management system. To achieve safe code/asset edit.
- Debug quickly. Edit code with PlayCanvas editor or local editor and run the edited code immediately.
- Use PlayCanvas editor for scene setup and other entity tree related action.
I expect our toolsets will be Chrome/FF/IE/Edge, Git, Visual Studio, intelliJ IDEA, Blender, Adobe tools and other asset edit tools.
Thanks in advance!
Having a group of developers requires management. You can’t just get a group of friends together to work on your game, you have to actively plan how they’re going to interact as a group.If you all have separate role (eg one is a modeller, one is software development, one is concept art, etc.) then it’s easy enough, people know their roles.
If they’re all going to help with software, things are rapidly going to become, well, interesting.
Here is my advice:
- Make sure people understand how the game fits together. Draw diagrams showing module inheritance, plan the structure of your game. You may think ‘it’s object oriented, every object is independant’ but I can tell you: it’s not. Modules and objects will depend on each other and knowing how they will is important
- Make sure people understand how the engine works. This was my big problem when starting my playcanvas project. I did not understand the ideology behind the engine and as a result I took some false steps and my code is not as great as it could be.
- Use a versioning system. Definitely do. If you aren’t already, do it now. I use a VCS for every one of my projects and have never regretted it.
- If it’s a larger project, make sure you have a central location for information such as a wiki. This is something my current company (unrelated to playcanvas) lacks at the moment and it has a detremental effect on motivation and productivity. It also means that when a person leaves, they take all their knowledge with them.
- Use a bug/issue tracking system
- Make sure team members can communicate with each other, not just with you.
- Make sure you know what you are making. The fastest killer of team game projects is feature bloat. People think of cool ideas, implement them and the game never gets to a finished state. Good planning of exactly what the game actually is goes a long way to keeping the project on track. Yes, there will be good ideas, yes, you can add them and it may make the game better, but knowing what the core game is is very important.
- Make sure people don’t break the build. There is nothing worse about working as a team to find that before going home for the night, someone wlse made a minor tweak to their code and it broke the whole game.
- If possible, convince people to do unit testing on their code. This is something someone needs to convince me to get in the habit of…
- If you have more than 4 people, dedicate one to be the leader who spends all his time managing the project. If you have more than 8, split them into two teams.
- Paper is your friend. Things written with ink on paper do not vanish mysteriously or change suddely. Having your game plan on paper is a huge bonus.
- Make sure people know who’s in charge (you?) and that they will respect your decisions.
I’m an engine-only user, and can reccomend it. It means you can control the game loop as you want, so things like updating control don’t need to be in-game objects. It means the whole project is under version control (and because the assets are json, this can work suprisingly well). If your project is bigger than a single level/scene, you’ll find that engine-only has some massive advantages. (<-- based on my experience with a different engine/editor). If you’re team members are proficient coders they will (probably) get frustrated with the editor after several weeks. (<-- based on my experience with every editor I’ve ever tried).
Even with fantastic collaberation tools built into the editor, there is no diff tool for 3D scenes. This makes version control hard. Also people tend to break things other people are working on.
Consider reading some management textbooks or taking a couse in management. Consider your work experience as a software engineer, what has worked and what hasn’t.
A post was merged into an existing topic: Textures for game