after reading to much about game engine architecture I’m totally puzzled right now…
As I started working with Unity (not too long ago) I was expecting the editor to be what is called a game engine. After reading a lot of theory I think my former expectation is complete rubbish and I would appreciate if someone would tell me if my new view is closer to reality than my naiv former mindset…
From what I understand: Unity Engine is the runtime engine with subsystems such as a input module, scripting system, physics engine, renderer and so on. Unity Editor is a visual interface through which
subsystems can be tweaked (i.e. adjusting the physics-tick through the editor),
gameobjects can be made up, organized and used to assemble a scene / level
the engine’s tool suite can be used (i.e. scripted behaviour can be attached to gameobjects, animations can be created, models can be imported, profiler can be used) and
the current status of the game can be evaluated by starting game-mode what actually sets the runtime engine “alive”.
I hope it’s not too stupid to ask you guys for your opinion. I’m just trying to understand things…
Thx, Billy. By writing “pretty much correct”, do you mean I’m oversimplifying the complexity of the system constituted by the engine and editor or that I’m missing some major aspects?
Well you’re pretty much spot on. To put it quite simply, the engine consists of some input, physics and lighting algorithms that process the code that you write and the assets that you put in your game, in order to output the result (state of the game at time t) on the screen.
The thing is, the editor can also modify the engine itself, so it is not always used simply to set up the game.
I have a feeling you’re chasing terms here, rather than simply trying to gain an intuitive understanding of the process. The term ‘engine’ often is used to encompass the editor as well.
This is what I meant with “tweaking the subsystems of the engine with the editor”. I thought that changing fixedTimestep is a good example as it is a modification affecting the physics-engine or at least the engine’s main loop (execution order of event functions).
Yeah, you got me there… From my profession I’m used to standardized terms as those are really helpful to avoid misunderstanding. When it comes to game development I noticed that there are quite a few terms that are widely used but there’s no common consensus about their meaning. I think breaking up larger systems into smaller modules with explicit names and trying to figure out how this modules work together is my way of gaining a intuitive understanding of a process.
You’ll probably find quite a few mis-uses of ambiguous terms around here (not least of all the term ‘AAA’). I think the best thing is to jump into the engine and start using it, that way you’ll learn very fast. If you want to know about something specific, Unity’s documentation is pretty stellar so i’d suggest checking that out as well.
Games, and software development in general, have a lot of similar tasks and requirements that virtually every game uses. An engine is simply a large collection of those elements assembled in a way to speed up the process and make it more efficient. Unity (or any game engine) does nothing that you can’t do yourself with text editor, time and knowledge. But it doesn’t make a lot sense to write all those parts if there are already well-written abstract libraries available, that you can leverage through an API. Unity has probably thousands of these elements, and the Unity Editor provides an even more efficient way to use many of these, in a visual way.
A bicycle and a car will both get you from point A to point B. A car has an engine that provides energy that will let you do it faster, with air conditioning and a sound system.
While I do have a decent appreciation of how Unity works, there is a lot to be said for using it as a black box. The point of using an engine is so there is no need to understand all of the intricacies.
Until something unpleasant happens and you don’t know why …
It may not be for everybody, but I’ve found that for extending the editor - which I think is extremely underrated in terms of optimising game development - it’s very useful to understand not only how the engine works but the editor as well.
At the beginning, Unity always seemed to me to be a sealed off black box with a nice and friendly interface, and I always assumed there was some need to “have the source codes” before I could do any substantial modification, but after you poke around suddenly you realize how much of it is not only fairly simple in terms of scope, but very accessible for modification. And that for me is very very useful to know. I would never have realized that I could do what I know I can do now, if I hadn’t tried to see what was inside, or find out how the editor was handling information.
I disagree… the point is that you don’t have to implement them, since implementing all of the stuff a decent engine does would take a heck of a lot of time. Understanding them is still really beneficial.
Don’t get me wrong. I’m not advocating never understanding the tech. Just that understanding it from the start isn’t needed.
As you use Unity to make games, your understanding of the tech will grow. On the other hand focusing on the theory before you open the editor and do anything is often a waste of time.
It’s also possible that I’m misreading the OP. But it sounded to me a lot like “I really need to understand the symantics of the tech before I can start using it”.
