Best practices for multiple developers on the same project?

[Andy_K]

Looking for some info on the best way to do this.

Currently, if each developer is working on their own code branch (standard development practice for most software) then with only one development instance of a game playable it means only one developer can test their changes at a time, which is not ideal. What are the best ways of managing this within BGA studio framework? Is there any option which will allow both (or more!) developers to test their own changes simultaneously?

Creating my own 'dummy' game as a development branch would seem like a sensible option, but since projects must have unique names & these names determine the expected filenames and classes within the project, I would have to rename all the appropriate files/classes/variables/paths from the original versions to make this work. This would also be a pain for source control/merging, and as far as I know there isn't a definitive list of what changes would need to be made either.

Is there any way to include external js/php files within a project? If the bulk of the game logic could be done in these, they could share the same name and largely mitigate the difficulty in getting one developers changes from e.g someGame.php into someGameSecondInstance.php

Any other ideas?

[Rudolf]

Each Guy can manage a State in PHP ... you do it under a version control app (GIT, ...).
he does it on a copy of the version.
There is a central guy who is in charge of managing/verifying running version and allow someone to test a part.
There is a tester that is in charge to test the function according to a sheet given by central guy.
...
like in video games.

[Andy_K]

Sure, I understand version control and branching etc, giving each person their own copy of the code is easy enough. But under the current setup, only one copy of the code can be executed at a time since only one local version can exist on BGA. Your suggestion, unless I'm missing something, is 'have 1 tester and 1 developer', but developers still need to test & run the app too in any case. I cannot see any way to have more than one person run different copies of code at the same time, which is a massive barrier to concurrent development.

[Rudolf]

No.. it's not what I mean exactly
You've got one central manager (which links dev to testers)
You can have more than one testers... and as many dev that you want.
You just have to make a planning for tests for each developper...and when it's his turn, you connect his code...
For example: a dave write the Code in a function TargetCardSubcode().... The cuurent TargetCard funciton only send a Console.log or a notifyallplayers ("TargetCard Function not ready");
When TargetCardSubcode is ready... he says to you or you planed to give him a range of time to test... In TargetCard you uncomment the call of TargetSubcode ... and test begins...
If it crash, you recomment call in TargetCard, report the crash to your Dev, plan a new test range and wait next step, according to other dev tests.

[pikiou]

There is no way to include an external tpl file within an active table, and it would require an ugly workaround to do the same for the main php file (basically, you'd run a different code depending on who is at the table).

The best solution I can think of is the 'dummy' project you talked about. Have one for each dev and a main one to check from and commit to. Then write some script to rename the whole project and check / commit.

[Een]

Hi,

Indeed, the use case we had in mind when creating the studio was one game / one developer at one point in time. The possibility to share a project is mostly so that the work of someone can be transferred to another for completion if one developer cannot continue.

There have been some requests for team coding possibilities, but in fact not so much as most games are not projects so huge that they need to be broken in pieces and assigned multiple developers to get done in a reasonable amount of time.

So for actual studio projects with multiple developers, you either have to manage time frames (such as defining a locking comment in one file such has 'X started working at <time>' and a releasing comment such as 'and finished at <time>' so that others developers know if they can start or not) or to adopt the separate/consolidate approach mentioned above.

Best,
Een

[Andy_K]

Thanks for the responses, I figured the studio had been created with solo development in mind.

The option we've gone for - since it's just two - is to alternate who gets to use the BGA instance for testing. This works okay as we're in different time zones anyway. Then we're using an external repository to manage branches/merging.