Shared Projects - Survey

[Victoria_La]

When I joined originally, I read on bga wiki that you "start a new project or join existing project".
Coming from open source community I though joining is a good idea, but later I realised that
its not really possible with bga studio, for multiple reasons. Lately I asked Een about what can we do to make it possible,
but solutions seems to be very technically involved and may be not justifiable. So the question
for activate developers, do we need such feature? Or games are really so small that another persons "help"
would be anti-productive? And if studio would support shared code developer what is the most important thing to have?

[Morgalad]

Hi,
I've been thinking about this and it would be quite easy to work together in a project if the control pannel would allow to pull a github project automatically.
This is: both developers work in the Github project and any of them commit to that (so we can have commits, branches, rollbacks, etc)

Then from the control pannel you could automatically download new versions.

(this is how I normally develop but with some intermediate steps to download from github to my computer and upload via ftp)

[Victoria_La]

Code sharing is not a problem, problem is staging sharing (the code in studio that runs), unless you work in different time zones.
How the other person would test their changes? If you share the project and both syncing at the same time it won't be good.
My question was about if anybody felt they really need to work together on a project and if it would benefit.

[Morgalad]

I see what you mean, to test and debug the project name overlaps and you have to use separate branches.
I work in a software company with hunreds of devs. They use branches and pull requests. The main branch stays untouched until the master merges the pull requests from the devs.

Each dev works in his own branch and once his part is working he notifies the master to merge it. With 2 devs this method should not be a problem.

You only would need a quite simple script to format the projectid before merging it to the main.

[Victoria_La]

But its not about branches, your developers working on different stuff don't run it on production server I assume, you run your own server to test.
We cannot do it.

I see what you mean, to test and debug the project name overlaps and you have to use separate branches.
I work in a software company with hunreds of devs. They use branches and pull requests. The main branch stays untouched until the master merges the pull requests from the devs.

Each dev works in his own branch and once his part is working he notifies the master to merge it. With 2 devs this method should not be a problem.

You only would need a quite simple script to format the projectid before merging it to the main.

[docthib]

I never worked in team on a BGA game but I might soon. The thing is, I will have to share my SFTP logins and my studio account..
Even if it sounds not practical it's not the end of the world.

One solution could be to have a SFTP per game and not per account, and change the way to manage/play games in studio.
But such changes would implies lot of work I guess :s

[fafa-fr]

Hi,

So the question for activate developers, do we need such feature?

I'm a "not very active developer", but I'll answer:
Short version : I never really needed it, but I could have, and I might need it some day.

Long version:
- in the past and present: I joined a project because I wanted to offer my help, if needed, to develop a game (not a small game) that I love. Since it could have led to problems to upload new code without knowing if the other dev was also uploading at the same time, we agreed that I would give my code to the admin, who would upload it. So the only ways to easily test the code would have been to create a second project for this game, for my tests only, or to agree on the time periods each one of us could use to upload and test. We never actually needed this because the original dev didn't have time anymore (and still doesn't have) to work on BGA, so I've worked alone on this project.

- in the future: on this game, this dev might come back some day, anf if he does, it will not be very convenient. But since I'm not very active, we'll be able to deal with this, I think. For other games: I like big games with direct interaction (I mean fighting ), which are almost not present on BGA, so my dream is to code one, if some time I'm able to spend more time on coding than now. In this case, I haven't decided yet if I'd be willing to work on it with other devs. It could be easier if we are 2 (or 3?), but on the other hand I'm not sure that I'd be ready to work with people I really don't know on a project that's important for me. If things turn bad because of different points of view about the implementation, I'd be really disappointed.

[tarini]

I speak as developer. I deployed a complete game (Florenza, if you want to try) and now I'm developing 1969 (https://boardgamegeek.com/boardgame/121409/1969).

In my opinion, here on bga, the main needs for a developer is "structure" more then "code". As all we know, working with a single backend file and a single frontend file (excluding in-fact-empty file as tpl, views, materials....) is very difficult and messy.

My first game developing process was a mess. I had to completely change my way to work (as professional developer I like to have a lot of file, organized in folders, splitted by their purpose (models, services, repositories, helpers...)) to adhere to BGA file structure.

Developing my second game, I tried to give my a common way to develop functionality, I tried to create different "layers" inside game.php and game.js. These layers are similar to standard layers, for example "actions" (prefixed with ac) or "status" (prefixed with st).

I created a set of "db" function, prefixed with db, that are the only ones allowed to run queries (similar to a data repository layer), a set of "validation" function, prefixed with val that validate args and parameters and eventually throw a BGAException.

To better understand I share some PHP snippet:

Here is a "db" layer function

Code: Select all

    public function dbGetMoney($playerId)
    {
        $player = $this->getObjectFromDB("SELECT player_money money FROM player WHERE player_id='$playerId'");
        return $player['money'];
    }

and here a "val" layer function:

Code: Select all

    public function valUserHasMoney($playerId, $requiredMoney, $exception = true)
    {
        $money    = $this->dbGetMoney($playerId);
        $hasMoney = $money >= $requiredMoney;
        if ($exception && !$hasMoney) {
            throw new BgaUserException(self::_("You have not enough money to take this action"));
        }
        return $hasMoney;
    }

I forced myself to follow this set of rules in order to improve readability and to have a common "framework" to follow for my future developments. JS file follows as much I can this pattern.


What do you think?

[Victoria_La]

We tentatively agreed (with Een) to allow more includes files, I will start another thread about "structure", since this one more about sharing problems.

In my opinion, here on bga, the main needs for a developer is "structure" more then "code". As all we know, working with a single backend file and a single frontend file (excluding in-fact-empty file as tpl, views, materials....) is very difficult and messy.

[Andy_K]

Code sharing is not a problem, problem is staging sharing (the code in studio that runs), unless you work in different time zones.
How the other person would test their changes? If you share the project and both syncing at the same time it won't be good.
My question was about if anybody felt they really need to work together on a project and if it would benefit.

I've had the same thoughts. When I first started here I wanted to work on a shared project, but quickly ran into the same problems. I started a thread about It at the time, probably a couple years or so ago now. As you've said, the main problem is that there is only one active build at any time. Two developers can't simultaneously test their own code.

I'd really like to see this feature added. For one thing, shared development leads to more collaboration and a faster learning process for new and veteran developers alike. I'm sure it would be of great benefit to the general quality of code being produced here.