Game Engines
On the debate of engines (not one I'm trying to solve) a bunch of hobbyist gamedevs at my company got together to discuss why we chose the engines we prefer working in. GameMaker: Studio showed quite a lot of promise for flexing the game design muscle in being able to prototype 2D games quite quickly without having to get down into the engineering side - something that I get bogged down in way too easily seeing as I do software development professionally. I've been tinkering in Unity for the past 3 years so my exposure to the Unreal engine is quite limited.
What really cooked my noodle was how different Unreal and Unity were though. It seems that from a scripting standpoint the two engines take what seems to be vastly different approaches, but the short discussion we had still left me wanting to know more. Coming from immersing myself quite a bit into the ECS work Unity's been doing over the past few months I'm getting very stuck understanding exactly what approach Unreal uses. I understand the idea of Blueprints and that it is essentially just C++ code that gets scaffolded for you (scaffolded maybe not quite being the best choice of words), but I'm not sure I completely understand how one would "debug" a game from a designer's perspective. Unity kind of forces you to put everything in the hierarchy and that makes it quite accessible to have relatively easy access to your game's current state, but I'm not sure if I understand how one would look at and understand what's going on in Unreal.
I'm not even sure if I'm wording my what I'm misunderstanding correctly, but my intention is to just understand the workflows a little better.
What really cooked my noodle was how different Unreal and Unity were though. It seems that from a scripting standpoint the two engines take what seems to be vastly different approaches, but the short discussion we had still left me wanting to know more. Coming from immersing myself quite a bit into the ECS work Unity's been doing over the past few months I'm getting very stuck understanding exactly what approach Unreal uses. I understand the idea of Blueprints and that it is essentially just C++ code that gets scaffolded for you (scaffolded maybe not quite being the best choice of words), but I'm not sure I completely understand how one would "debug" a game from a designer's perspective. Unity kind of forces you to put everything in the hierarchy and that makes it quite accessible to have relatively easy access to your game's current state, but I'm not sure if I understand how one would look at and understand what's going on in Unreal.
I'm not even sure if I'm wording my what I'm misunderstanding correctly, but my intention is to just understand the workflows a little better.
Comments
So I can't speak to Unreal, having had no experience, but it's always fascinated me how Unreal Engine had this hardcore ceiling with its C++ base, and then tries to be "super accessible" at its ground floor with Blueprints. I've always found graphical programming to be a huge black hole that takes a ton of time - whether less so or more so than typing code that I might have to research a lot more, I don't know. I'm actually guessing that if you go into Unreal from Blueprints, you'll eventually need to level up or you'll hit some limitation, much like I did with GMS, and then you'll have to pick up C++....... Which I feel completely intimidated by.
That said, I feel that text IDEs are much more mature, with auto-complete, auto-format, and lots of other ways to type code very quickly. Blueprints don't really have auto-formatting and cleaning them up feels like time that shouldn't have to be spent, and certain things (like loops and maths) are a pain compared to code. Your only real advantage is afaik not having to recompile/reopen the editor to make small changes... and you already get that with Unity's C#, with all of the advantages of a text IDE.