hello.

I want to make my game using Unity, i do not know programming well so i will hire programmers to do the job.

I am going to hire people but problem is that they won't work more then a few weeks. After they will write certain game features they may leave (they will work part time and for few weeks).

So i want to know if i can work in such conditions when programmer arrives writes for few weeks and then leaves. Can i connect all codes written by different programmers? I know little bit of programming but have no experience. Can you share your experience on that topic?

Thank you in advance

Can't you hire them as contractors and have the contracts specify the time period so that leaving before a set date would be a breach of contract?

I also think you should ask yourself why they are/would be leaving after a few weeks?

To answer your question, if the game is somewhat technically challenging it will be difficult for you to “connect” (actually called integrate) the code. Even experienced programmers struggle when asked to integrate code form a bunch of different programmers that didn't talk to each other and set up sensible APIs.

GiorgiDev said:
Can i connect all codes written by different programmers? I know little bit of programming but have no experience.

Without enough experience to do it yourself, you need to hire a CTO to connect up the code - but it's unlikely to work out well.

The matter of hiring and personnel loss is a matter of Production And Management. You can ask about how to manage personnel better in the Production And Management forum. Also, I assume you use the word “hire” in the traditional sense (you pay your people with real money, not a promise of potential sales revenue sharing).

GiorgiDev said:
So i want to know if i can work in such conditions when programmer arrives writes for few weeks and then leaves. Can i connect all codes written by different programmers? I know little bit of programming but have no experience. Can you share your experience on that topic?

Possibly but would advice against it without experience, and even then It's more trouble than it's worth in your case.

Design the Project Tasks so they can get completed by 1 person quickly. I understand this a lot of breaking down features and Tasks into small easily completable 1 day chunks. But they can then integrate the changes them selves daily. So when someone leaves and a new person arrives, everything is already integrated to that point. But that's more of an Organisational topic.

The model you suggest won't work because of scaling costs.

The bigger the game gets, the more code is already there for the developer to familiarize themselves with, before they can make a good next improvement. If they don't spend that time, they will duplicate a bunch of work, or they will clash with some other code that they don't know is there and don't particularly know to test for.

Even if you use a standard game engine, there are many different ways that each task is done inside those engines, and what particular method was chosen by whomever initially set up that part, needs to be understood by anyone working in that part. For example: Playing sounds needs to be correctly controlled by sound and localization controls, which in turn go both to the “storage” module and the “gui” module and maybe the “localization” module, too, in addition to being a feature used by both physics, and interfaces, and the magic system, and …

Find someone who can stay across many tasks, and figure out how to make them WANT to stay.

If it’s properly object-oriented, then the new programmer can treat it as a black box, already unit tested.

but what’s with the employee turnover? Not even McDonald’s has a turnover rate like that.

taby said:
If it’s properly object-oriented, then the new programmer can treat it as a black box

Won't work. The problem with OOP is: Despite the ambitious goal to have a nice hierarchy of abstractions over functionality, in practice you have no idea about the state of the data in all your classes.
To get this idea you have to dig through all the code regardless of using OOP, which is actually easier if you're not using OOP.
This, plus the fact that a tree shaped hierarchy is hard to design, if what you really want is a flexible (but unordered) graph, are the big reasons games moved from OOP to ECS. (If it makes sense to compare those.)

Til yet there is no general agreement over what's the best programming paradigm, language, etc. So a new programmer has to learn whatever custom solutions and hacks the new code base has piled up.

Let me tell you that, in my experience, your expectations are unrealistic, programmers won't code for free, so first thing first , try to get some budget, second, why are you preventing they will leave ? third hire a tech lead and / or a project manager. You do not have exp in programming , but maybe you have a silent talent in project management ? give it a try , if this is your first game, do not expect to create a masterpiece, try to get as much experience as you can, a leader with no experience in anything won't be much impressive, and employees (sp??) need a ‘father’ figure

I'm not clear why you expect to hire programmers for such a short time? That is unusual. What is your reason for doing so? It would make more sense to hire the same programmer(s) to do work over a longer period. Since you lack technical knowledge it will be important to hire a lead programmer to work with any other programmers and help structure the project and integrate the work from the other programmers as well as assess how technically feasible and/or difficult the code is, and work to develop reasonable time estimates.