Game Tools Development
Since the tools programmer should not be required to have a completely clear view of the exact details of the game engine it would only be logical that the engine programmers would create the wrapper, letting the tool programmer write a wrapper would be rather counter-productive if he/she still needs to find out how exactly the engine internals work
I hate metaphors.... anyway, so the game engine guy makes the wrapper(hope so) . Sorry if I don't understand you right....
My point was that it really depends on the restaurant you're in. It also depends on the salad.
In some teams, it makes sense for the tools guys to consume the engine as a service, and the engine guys don't touch the tools layer at all. I'd say this is actually the "better" way to do it.
In other places, the engine guys don't provide a clean interface onto their code for whatever reason, so deeper integration is necessary. In this situation, the engine guys build the wrapper.
True, this is ideal for tools like asset editors and such, but when it comes to scene editing I could see it become a real pain to separate the editor from the actual scene view, or am I not considering something?
You're not missing anything, what you say may very well be the case. This really depends on your game. For some games, having in-game tools might be very important. For others it might be a hindrance, or at least an unnecessary complication.
Author
Since the tools programmer should not be required to have a completely clear view of the exact details of the game engine it would only be logical that the engine programmers would create the wrapper, letting the tool programmer write a wrapper would be rather counter-productive if he/she still needs to find out how exactly the engine internals work
hm.... of course! you're right....
Author
[quote name='Mauricio Cinelli' timestamp='1311634551' post='4840240']
I hate metaphors.... anyway, so the game engine guy makes the wrapper(hope so) . Sorry if I don't understand you right....
My point was that it really depends on the restaurant you're in. It also depends on the salad.
In some teams, it makes sense for the tools guys to consume the engine as a service, and the engine guys don't touch the tools layer at all. I'd say this is actually the "better" way to do it.
In other places, the engine guys don't provide a clean interface onto their code for whatever reason, so deeper integration is necessary. In this situation, the engine guys build the wrapper.
[/quote]
That's what cause my confusion.... because it depends, but most likely, the game engine guys would do it. Thanks ApochPiQ
[quote name='Radikalizm' timestamp='1311633276' post='4840228']
True, this is ideal for tools like asset editors and such, but when it comes to scene editing I could see it become a real pain to separate the editor from the actual scene view, or am I not considering something?
You're not missing anything, what you say may very well be the case. This really depends on your game. For some games, having in-game tools might be very important. For others it might be a hindrance, or at least an unnecessary complication.
[/quote]
Totally agreed. Also, making separate tools depend on what you're doing. For an example, a animation format converter doesn't need to be in the editor, although it helps..
That's what cause my confusion.... because it depends, but most likely, the game engine guys would do it. Thanks ApochPiQ
On the contrary, that's the exact opposite of what should happen.
In a well-structured project, the engine provides its services via an easily used API, and the tools build on this. In that case, the tools guys write the tools, the engine guys write the engine, everyone is happy.
When the engine guys are writing parts of your tools, it's a sign of a flaw in the architecture.
Author
[quote name='Mauricio Cinelli' timestamp='1311635778' post='4840250']
That's what cause my confusion.... because it depends, but most likely, the game engine guys would do it. Thanks ApochPiQ
On the contrary, that's the exact opposite of what should happen.
In a well-structured project, the engine provides its services via an easily used API, and the tools build on this. In that case, the tools guys write the tools, the engine guys write the engine, everyone is happy.
When the engine guys are writing parts of your tools, it's a sign of a flaw in the architecture.
[/quote]
The API that you mentioned is what i was reffering to wrapper: something that i can interface with the engine itself.... I really need to improve my communication skills.
hahah
Ahh, fair enough. I was reading too much into your focus on C++/CLI; in my mind I understood you to be referring to a dedicated C++/CLI layer. My argument is that the C++/CLI layer should be talking to a native engine API, and that the C++/CLI bit itself should be the domain of the tools team rather than the engine team.
Ahh, fair enough. I was reading too much into your focus on C++/CLI; in my mind I understood you to be referring to a dedicated C++/CLI layer. My argument is that the C++/CLI layer should be talking to a native engine API, and that the C++/CLI bit itself should be the domain of the tools team rather than the engine team.
This is turning out to be an interesting discussion
Intuitively I would say that the C++/CLI interface would actually be the engine team's responsibility since they should have the best knowledge of the native interface and therefore should be most qualified to write the interface for the tools developers (note that a wrapper could be useful for other things beside tool development)
Of course, I'm talking about an ideal situation where a decent workflow is maintained for both teams so the actual main work (the engine development itself) does not suffer
I can perfectly see where you're coming from though, it'd be interesting to hear about an actual case where this issue has occured
If the engine team produces an API so opaque that the tools team cannot consume it efficiently, the engine team fucked up.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
