3 ms·

I never managed to like unity or godot because they remove freedom from the developer. Your code becomes a second class citizen. Apparently level design people

by jokoon 7y ago

I never managed to like unity or godot because they remove freedom from the developer. Your code becomes a second class citizen. Apparently level design people and artists like it, which makes sense, of course, since indie gamedevs and small teams who are full of ideas and content, want to work as quickly as possible. But as a developer, I just loathe those tools. They sort of make sense for non-developers who want to make a prototype game and "tweak" things by writing as little code as possible while getting bleeding edge graphics. In reality it just enables unambitious projects so that "anybody can make games". It's like comparing LEGO to mechanical engineering. Of course, if you're pedantic, a LEGO car fits the definition of a car. You can sell a lego car, and then you realize how twisted the indie video game market is right now. But if you want to make a game, those WYSIWYG things are horrible. They're viable, but if you have some issue or limitation with the tool, you're really stuck. If there's a performance problem, it becomes more difficult. If you want to release on console, there are additional steps and work to do. You cannot "use what you want", because it's a huge generic blob of things that you cannot really understand how it's made. I watched a video about the internals of godot and was not convinced at all. Of course it's open source but it's a giant mess. Unity is not even open source. I will always show this video each time those WYSIWYG tools are talked about: https://www.youtube.com/watch?v=tInaI3pU19Y https://www.youtube.com/watch?v=tInaI3pU19Y It's the 40 years old debate "should I use this feature rich framework to make the website of my grandma?". The answer is "you either care about your ability to write code, or you don't.". Simple as that. Another result is a large bubble in the video game market. There are just too many games. In a way, it helps people gaining experience, but even many of the great games are often very short lived. I think it will give a bad reputation to platforms like Steam etc.

prophesi 7y ago
These visual editors are a godsend when developing a videogame. Even with ThreeJS, which is still an abstraction of OpenGL, I've had a lot of issues with really simple visual problems, like getting my models placed at correct locations at correct scales with the correct rotation. Trigger box placement. Enemy spawn locations. Their visual fields. I ended up having to essentially script my own visual editor to debug these issues. God forbid I have to implement any sort of networked multiplayer. And yes, there are a _lot_ of games. Steam is already suffering from the lack of quality assurance. But allowing creativity to flourish like this is good for society in the end. Personally, I think UE4 has the right idea. You can have your first-class citizen code (C++ components) which you can hand off to be used by the more design-oriented team members (Blueprint scripting + visual editor).
quacker 7y ago
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
meheleventyone 7y ago
One of the main benefits to opening up development of games to the slightly less tech savvy is the gems that come out of it. The fact everyman and his dog tries to sell their first hobby game and stores do nothing to differentiate between quality products and crapware isn’t the fault of modern game engines. Rather blame the commercial culture around game development and the storefronts themselves. Also if you think Unity etc. are bad you should see the rock bottom quality of internal tools people used to put up with!
reificator 7y ago
> They sort of make sense for non-developers who want to make a prototype game and "tweak" things by writing as little code as possible I'm a programmer for life and I am always looking for opportunities to turn code into data. The editor is just a way to edit some of that data. You can take this take this too far though. The inner platform effect is real and I'm not personally a fan of visual scripting languages most of the time. But even that has nuance, because writing shaders visually in Unreal where you get an image preview at each step of the transformation is incredible. Note that I'm not a game developer by day and when I do dip into Unity/Unreal I tend to also avoid the editor, but looking at it as a spectrum from developer to illiterate is a fallacy.
pjmlp 7y ago
On professional games, your code is a second class citizen, is is only a tool to bring the level design, the game story to life and that is not made by programmers. Programmers on game studios are akin to SFX and film processing processing on movie industry, that is not what a movie is all about. In many studios they are even writing game engine plugins for several games ongoing at the same time.

by jokoon 7y ago

prophesi 7y ago

These visual editors are a godsend when developing a videogame. Even with ThreeJS, which is still an abstraction of OpenGL, I've had a lot of issues with really simple visual problems, like getting my models placed at correct locations at correct scales with the correct rotation. Trigger box placement. Enemy spawn locations. Their visual fields. I ended up having to essentially script my own visual editor to debug these issues. God forbid I have to implement any sort of networked multiplayer. And yes, there are a _lot_ of games. Steam is already suffering from the lack of quality assurance. But allowing creativity to flourish like this is good for society in the end. Personally, I think UE4 has the right idea. You can have your first-class citizen code (C++ components) which you can hand off to be used by the more design-oriented team members (Blueprint scripting + visual editor).

quacker 7y ago

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

meheleventyone 7y ago

One of the main benefits to opening up development of games to the slightly less tech savvy is the gems that come out of it. The fact everyman and his dog tries to sell their first hobby game and stores do nothing to differentiate between quality products and crapware isn’t the fault of modern game engines. Rather blame the commercial culture around game development and the storefronts themselves. Also if you think Unity etc. are bad you should see the rock bottom quality of internal tools people used to put up with!

reificator 7y ago

> They sort of make sense for non-developers who want to make a prototype game and "tweak" things by writing as little code as possible I'm a programmer for life and I am always looking for opportunities to turn code into data. The editor is just a way to edit some of that data. You can take this take this too far though. The inner platform effect is real and I'm not personally a fan of visual scripting languages most of the time. But even that has nuance, because writing shaders visually in Unreal where you get an image preview at each step of the transformation is incredible. Note that I'm not a game developer by day and when I do dip into Unity/Unreal I tend to also avoid the editor, but looking at it as a spectrum from developer to illiterate is a fallacy.

pjmlp 7y ago

On professional games, your code is a second class citizen, is is only a tool to bring the level design, the game story to life and that is not made by programmers. Programmers on game studios are akin to SFX and film processing processing on movie industry, that is not what a movie is all about. In many studios they are even writing game engine plugins for several games ongoing at the same time.