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.