6 ms·

Honest question: What does the dev process actually look like for AAA games? - Do they create levels/scenes without a visual tool to set the positions of every

Honest question: What does the dev process actually look like for AAA games? - Do they create levels/scenes without a visual tool to set the positions of everything? - Or, if AAA studios tend to use some kind of visual tool, is it not a WYSIWYG tool? How does it differ? I'm not a game developer, but I've tried gamedev as a regular developer, trying to do everything in code. Laying out the positions of objects in code, rather than visually, is a huge time sink. So I'm really curious how this could be done quickly at a large scale without some kind of visual tool.

badsectoracula 7y ago
Visual tools are used all the time, take a look at UE4 or Unity, most AAA engines look pretty much like that. Not all engines are as polished as these two (since those are products by themselves so they have to look shiny and do a lot of stuff to cater to a large demographic) and not all engines use the monolithic approach where the editor and the engine are one and the same (AFAIK Sony released a framework of theirs a few years ago for C#/WinForms that they used for internal tools which were completely separate from the engines - a programmer i know who has worked on something similar also told me that the tools even had their own separate renderer). But visual tools are involved in one way or another, especially when it comes to inherently visual stuff (e.g. like you wouldn't manually put pixels in an image and use an image editor instead, you wouldn't put the objects manually but use a scene editor). How much they go towards visual vs non-visual is largely a matter of engine and tool design. In UE4 everything is done visually, including scripting. In Unity most behavior and scripting is done via C# but the rest are done visually (though there are addons for visual coding and/or behavior too). In a company i worked at some years ago everything outside of scripting was done visually using a combination of in-engine and external (but still custom) tools. In a company i worked more recently almost everything outside of level design was done via text files and there was no scripting at all, all game logic was in C++ and driven via text files (however the editor had a very flexible parametric prefab system which allowed a lot of modularity so you could still have some simple form of logic through reusable components). In my own engine and editor (you can see both in action here[0]) i have them totally separated - in fact i started wroting the editor three years before the engine and i used it for different stuff (e.g. this little creepy[1] game i made for an old Ludum Dare in Java/LWJGL which i lated used as a base for this Descent-like demo[2] and later in this[3] demo i made to learn C#/XNA). Outside of world editing, everything else is handled via scripts (actually even inside the editor you can 'attach' script code to entities, it is just that the editor doesn't know about them, they are just passed as strings to the engine which handles them as scripts). These scripts are mostly edited by hand[4] or generated by other tools (e.g. the model editor generates scripts that define animation details through scripts) or scripts. Though recently i'm thinking on scrapping everything and making a more unified monolithic engine. Architecturally i believe it is better to have everything separate (especially the engine from the tools, but also the tools individually) but in practice it is much more convenient when i can reuse existing code - as things are right now, even though i do share code between the tools, i still have to reimplement a lot of stuff that a more monolithic approach wouldn't require. Nobody else except me is going to use that code anyway :-P. In any case, if you are curious about how tools are used in a game, even if a tiny game made in two days for a gamejam, you can see the two-days-compressed-to-one-hour video i made for the She Loves you game in [5]. [0] https://www.youtube.com/watch?v=8gnDdM_PC54 https://www.youtube.com/watch?v=8gnDdM_PC54 [1] https://www.youtube.com/watch?v=LeIIt5Wydyw https://www.youtube.com/watch?v=LeIIt5Wydyw [2] https://www.youtube.com/watch?v=5WrV4By94pQ https://www.youtube.com/watch?v=5WrV4By94pQ [3] https://www.youtube.com/watch?v=GP9kTbYxIqY https://www.youtube.com/watch?v=GP9kTbYxIqY [4] https://i.imgur.com/tCd64Wh.png https://i.imgur.com/tCd64Wh.png [5] https://www.youtube.com/watch?v=YXIDzwUMnIg https://www.youtube.com/watch?v=YXIDzwUMnIg
xsmasher 7y ago
Professional game teams use visual tools. Visual tools allow non-programmers to do work / prep files / iterate on ideas / create animations without an engineer being involved. An individual indie dev doesn't care about that, so having hardcoded data may be a faster workflow. In the studios I've worked UI artists work on the UI files and then pass them off to engineers to connect to the code. Tuning data comes from spreadsheets, and art/animation comes from artists, and they generally have a one-button import process that doesn't involve an engineer.

badsectoracula 7y ago

Visual tools are used all the time, take a look at UE4 or Unity, most AAA engines look pretty much like that. Not all engines are as polished as these two (since those are products by themselves so they have to look shiny and do a lot of stuff to cater to a large demographic) and not all engines use the monolithic approach where the editor and the engine are one and the same (AFAIK Sony released a framework of theirs a few years ago for C#/WinForms that they used for internal tools which were completely separate from the engines - a programmer i know who has worked on something similar also told me that the tools even had their own separate renderer). But visual tools are involved in one way or another, especially when it comes to inherently visual stuff (e.g. like you wouldn't manually put pixels in an image and use an image editor instead, you wouldn't put the objects manually but use a scene editor). How much they go towards visual vs non-visual is largely a matter of engine and tool design. In UE4 everything is done visually, including scripting. In Unity most behavior and scripting is done via C# but the rest are done visually (though there are addons for visual coding and/or behavior too). In a company i worked at some years ago everything outside of scripting was done visually using a combination of in-engine and external (but still custom) tools. In a company i worked more recently almost everything outside of level design was done via text files and there was no scripting at all, all game logic was in C++ and driven via text files (however the editor had a very flexible parametric prefab system which allowed a lot of modularity so you could still have some simple form of logic through reusable components). In my own engine and editor (you can see both in action here[0]) i have them totally separated - in fact i started wroting the editor three years before the engine and i used it for different stuff (e.g. this little creepy[1] game i made for an old Ludum Dare in Java/LWJGL which i lated used as a base for this Descent-like demo[2] and later in this[3] demo i made to learn C#/XNA). Outside of world editing, everything else is handled via scripts (actually even inside the editor you can 'attach' script code to entities, it is just that the editor doesn't know about them, they are just passed as strings to the engine which handles them as scripts). These scripts are mostly edited by hand[4] or generated by other tools (e.g. the model editor generates scripts that define animation details through scripts) or scripts. Though recently i'm thinking on scrapping everything and making a more unified monolithic engine. Architecturally i believe it is better to have everything separate (especially the engine from the tools, but also the tools individually) but in practice it is much more convenient when i can reuse existing code - as things are right now, even though i do share code between the tools, i still have to reimplement a lot of stuff that a more monolithic approach wouldn't require. Nobody else except me is going to use that code anyway :-P. In any case, if you are curious about how tools are used in a game, even if a tiny game made in two days for a gamejam, you can see the two-days-compressed-to-one-hour video i made for the She Loves you game in [5]. [0] https://www.youtube.com/watch?v=8gnDdM_PC54 https://www.youtube.com/watch?v=8gnDdM_PC54 [1] https://www.youtube.com/watch?v=LeIIt5Wydyw https://www.youtube.com/watch?v=LeIIt5Wydyw [2] https://www.youtube.com/watch?v=5WrV4By94pQ https://www.youtube.com/watch?v=5WrV4By94pQ [3] https://www.youtube.com/watch?v=GP9kTbYxIqY https://www.youtube.com/watch?v=GP9kTbYxIqY [4] https://i.imgur.com/tCd64Wh.png https://i.imgur.com/tCd64Wh.png [5] https://www.youtube.com/watch?v=YXIDzwUMnIg https://www.youtube.com/watch?v=YXIDzwUMnIg

xsmasher 7y ago

Professional game teams use visual tools. Visual tools allow non-programmers to do work / prep files / iterate on ideas / create animations without an engineer being involved. An individual indie dev doesn't care about that, so having hardcoded data may be a faster workflow. In the studios I've worked UI artists work on the UI files and then pass them off to engineers to connect to the code. Tuning data comes from spreadsheets, and art/animation comes from artists, and they generally have a one-button import process that doesn't involve an engineer.