Connecting codes written by different people together.

First, you must not put it all together yourself without having created the code yourself after all there is so much in programming a game that it would be almost impossible to have the entire thing created separately without all programmers knowing what the others are doing. Secondly, just have the programmers work on the same project, meaning that every programmer can see what the other programmers are doing at all times, use GitHub for that.

There really aren't any rules that you have to follow, but it is best to see what the programmer can and can't do, what they are willing to do, and what they are not willing to do, except for those you are the one that makes the rules.

I should say that I am not really good with these things, while I am a programmer, I just don't do freelance, as I am the owner/founder of a company that is in the entertainment business. I will wish you some good luck with getting some more info on this, as I don't know much about how freelancers think and what they want in a client.

GiorgiDev, how complex of a game/product are we talking about?

What role do you see yourself in? Are you an artist? Project manager? Writer? Musician?

As a non-engineer, I would first and foremost partner with an engineer whom you trust to manage the development efforts. That person will be able to guide you on the rules, methods, phases, etc.

@azherdev I am not programmer and have no experience in that. I am just going to find a programmer and hire him. As beginner i am going to work about more like casual game with no complex codes and graphics. I would just like to know if i could break game into pieces like UI, levels, physics, advertisement, character movement and develop them separately with programmers and then connect them together.

@Officer_Erik_K It is not necessary freelancers i could find a programmer so i can view that as an option as well. I just would like to know if i could break game into pieces like UI, levels, physics, advertisement, character movement and develop them separately with programmers and then connect them together. I can even hire another programmer to view all those work and connect them if that requires knowledge of language.

Make a code architecture design(make it with the help of your hired).

GiorgiDev said:
I just would like to know if i could break game into pieces like UI, levels, physics, advertisement, character movement and develop them separately with programmers and then connect them together.

Yes, that's how it's usually done.

Our engine does that already. Check out our OO web game engine.

https://www.otakhi.com/​

https://www.otakhi.com/public/document​

We allow users to wrap lower level code, scripts, and GUI components into Objects that can be shared online.

All objects, once published, are stored in a central repository, anyone can grab what he needs to assemble/connect them into an end product.

Our approach is top-down using UML which is more natual since object design requirement comes from end users not developers. ECS approach means the behavior of the root class is fixed and dictated by the developer, while our approach does not suffer from this rigidity. For those programming nerds, this is partially due to our use of OBJECT COMPOSITON rather than INHERITANCE.

View a sample object here: https://www.otakhi.com/detail/16622

I dont think its good idea to hire tons of programmers to begin with. Probably one for writing the 3d engine, and one for implementing the game logic itself is enough. If they need more people, they will guide you how to hire more people and who to hire.

Geri said:
one for writing the 3d engine

You do not, under any circumstances, want to write your own 3D engine for the first game you develop.

A 3D engine doesn't just come with some support for “shaders and geometry,” but also needs an art pipeline, visual effects support, physics integration, some way to edit levels, and so on. Using any existing 3D engine is better than writing your own. Pick one that comes with source code, like Godot or Unreal Engine or perhaps the C4 engine, which will let you figure out how it works on the inside, which will help you build a faster, better game, and learn more, for your next time around. Or, if you absolutely need C#, pick Unity, and live with the fact that you can't necessarily know/control what happens on the inside.

GiorgiDev said:
can there be any problems with connecting them into one entire game?

Yes, if there's not a shared understanding of how they go together, then integration will be its own special work, essentially being just as big a task as the separate development tasks. It's better to start with an existing “empty game” project in an existing engine, and then follow the conventions from that engine to develop the game, where each developer does their thing and communicates with the other developers, and shares intermediate progress through source control so that all the other programmers can interact with those bits as they come along.

GiorgiDev said:
should i give them some rules to follow for me to be able to connect their work together?

If you are a beginner programmer, trying to do the work of “the integrator” is going to be tough, because the integrator needs to know what all the different pieces of the game requires, not just their individual specialty like graphics, physics, gameplay, or such. Much better to start with an empty game, and saying “This doesn't load a level – why don't Alice build a mock-up of the first level and Bob write the code for that? Also, we don't have a ”start game" menu – Charly can start building the main menu." Then keep iterating together. That way, integration is not as much of a problem.

This is a terrible idea. If you don't know how to develop a game yourself but are adamant to develop it by paying some programmer, you should let them code the game the way they see fit (and preferably you should only hire one individual or a group that work well together already). Now, chances are you will end with some game (that may or may not be to spec) where you have no idea how it works or how it was put together. Realistically I would say the only way to eventually develop a good game would be to learn how to do most of the things yourself even if you only know how to solve the problems in a non-optimal way. That might take you years but at least you won't completely be at the mercy of other people who's work you don't comprehend.

The requirements are in the form of Semantics… the interfaces of an object. Let's say you want to create a class of mailbox, You requirement would be PutMail, RetrieveMail, ExaminMail, DeleteMail, SecureMailBox… etc. These are defined by your mailman and how the consumers of the mailbox service expect it to work. The developer has the freedom to implement it however he see fit but limited by the technology he choose to use from below and must abide by the semantics given by the integrator.

The “integrator” doesn't need to know anything more beyond Object Semantics. Objects' expected input, output, and state machines after each interface call can be tested without tinkering with code.

This is the very problem software architects everywhere trying to solve for the better part of 90s. Visit https://www.uml.org/what-is-uml.htm​ to see how UML came about.

When one of your key developer got run over by a bus and your whole project is done…. You know that you are not following UML principle.

Develpers tend to told you otherwise, because, in this architecture, they become dispensable/replaceable.

mr.otakhi said:
The “integrator” doesn't need to know anything more beyond Object Semantics.

But this does not hold for performance critical realtime applications. You want to know at least time complexity of a function you call, and ideally about memory requirements and allocation, threading etc. as well.
Also, to get high performance, the guy under the bus may have done some things which are just hard to maintain. Does not mean he was not aware about the high ideals of software architecture. ; )

mr.otakhi said:

The requirements are in the form of Semantics… the interfaces of an object. Let's say you want to create a class of mailbox, You requirement would be PutMail, RetrieveMail, ExaminMail, DeleteMail, SecureMailBox… etc. These are defined by your mailman and how the consumers of the mailbox service expect it to work. The developer has the freedom to implement it however he see fit but limited by the technology he choose to use from below and must abide by the semantics given by the integrator.

The “integrator” doesn't need to know anything more beyond Object Semantics. Objects' expected input, output, and state machines after each interface call can be tested without tinkering with code.

This is the very problem software architects everywhere trying to solve for the better part of 90s. Visit https://www.uml.org/what-is-uml.htm​ to see how UML came about.

When one of your key developer got run over by a bus and your whole project is done…. You know that you are not following UML principle.

Develpers tend to told you otherwise, because, in this architecture, they become dispensable/replaceable.

What you are saying is mostly false. UML is a tool to visualize class dependencies. I've only seen it used extensively in one project so far (in the software development industry). I'm sure a lot of legacy systems still relies heavily on it since it was a big buzzword 20 years ago. As a visualization tool it can be great and it can be used to communicate an overarching architecture of an application. But it is not a tool by which you come up with an architecture of an entire application from the very start. That has to be done organically through finding better and better abstractions as you come to understand the system you are building. And the architect of any software project almost always seems to be a senior software engineer so you will have a hard time removing a dependency on software engineers no matter what way it is architected.

UML is merely a visualization tool because languages need be compiled back in the 80s and 90s. With today's advent of interpreted languages, UML can be used as a real-time code generation tool. What makes it compelling is its dynamic nature such as run-time class composition, not possible with any compiled language. Integrator says I want this and that, the tool will bring all the objects together, over the web, and give you an hybrid object that does what you want… at run time. Our platform does exactly that.

To address performance concern, WebAssembly is now approaching native speed. We've developed a general-purpose mutli-threaded/SIMD acceleration engine to boost Web App performance. We are seeing 30-fold performance increase in doing 3D vector-matrix calculations on a 4 core CPU.

UML code generation doesn't sound like a new idea. Javascript came out 1995 and Python 1991 so interpreted languages were not invented recently contrary to your claims. Many IDEs are capable of generating code snippets. I'm sure there are some people out there who would prefer UML code generation but to me it looks more like a visualization that would have its biggest use if it was generated from the code and not the other way around.

Like I said, no one does Run-Time Class Composition using UML, since most opt to use ECM Inheritance. And no one use UML to build application directly. Show me an example Like what we are doing here. Also, Please distinguish Build time and Run time. Anything we do in our editor can be achieved via script during runtime such as Nesting another class from the web to acquire new functions.

https://www.youtube.com/watch?v=rl5t3BNJyQ4​

https://www.youtube.com/watch?v=yUzTdXldTSE​

Getting back on topic…

This is not a topic about UML, nor about composition or other code. This is a question about business.

I very nearly moved it to the Business forums initially, but it is a For Beginners variant so I left it. Several of these questions are of the type where if you have to ask, you aren't ready.

Hiring workers and hiring freelancers is a business concern. Both of them require lawyers, both generally require business entities and tax forms. Both of them rely heavily on contracts.

Exactly how the systems interact with each other is important, and it is something you will have to manage. It is also something that absolutely must be in the legal agreements as part of the acceptance criteria.

If you're asking questions about how the systems interact with each other, you might be at the point where you're ready to hire someone who actually knows what they are doing. One step of forming a business is hiring people that will become team leads, project leads, tech leads, art leads, and those people will know the details of how all the parts interact. So if you have a comprehensive business plan and a lot of money to burn you might be at the point to start hiring those people. But it doesn't sound like it.

Since you asked for suggestions, it would be that I'd suggest you get far more experience in the industry before you consider hiring outsiders. You might collaborate with others — which means you'll likely need a lawyer to help with collaboration agreements, formalizing the terms of a business, rights assignments, allocation of money, and more — but you probably aren't ready to actually hire anybody at this point, neither as a worker nor as a freelancer.

Locking after additional off-topic replies and people reporting the topic. The For Beginners rules still apply.