To understand what a game engine is, we must first understand what a framework is.
A software framework is an abstraction in which a software provides generic functionality that can be
selectively changed by additional user written code.
Frameworks allow a user to easily write code for a specific application. The reason for using a framework
is that writing functionality from scratch is very cumbersome.
Some common software frameworks:
HTML Frameworks: helps you create websites
CSS Frameworks: helps you make prettier websites
A.I. Frameworks: helps you write artificial intelligence
Game Frameworks: helps you make games
So why is the Godot Game Engine called a game engine rather than a game framework?
A game engine can arguably be stated as a multiple frameworks being combined in order to create a higher level
Basically a game engine will do more than a stand alone game framework. It’s not uncommon for programmers
to use multiple frameworks when creating a game, but with a game engine you will only need a single game
engine in order to have multiple functionality.
For example, if you were to use a game framework, you’d have to handle and manage game performance yourself.
With a popular game engine, game performance is handled for you.
Pros of a game engine
When using a game engine, the benefits always outweigh the cons.
In this case the benefits of using a game engine is that you will never have to worry about lower level
Cons of a game engine
The negatives of using a game engine is that you sacrifice flexibility of the underlying algorithms being used
to run your game application.
This is a higher level decision, that you will most likely never have to worry about unless you are creating a
game at the level of a triple A studio.
Hello and welcome to another episode in the Godot basics tutorial series. In this episode, we will be taking a look at game engines. To understand what a game engine is, we need to first understand what a framework is. A software framework is an abstraction. A software provides generic functionality that can be selectively changed by additional user-written code, thus providing application specific software. That basically means that a framework makes it easier to write code for a specific application.
In general, it's cumbersome to write applications from scratch now though doing so is quite rewarding. Take, for example, each HTML framework. HTML frameworks help you make web sites. CSS frameworks help you make prettier Web sites. AI frameworks help you write artificial intelligence, and game frameworks help you write games.
Now that's a curious thing.
Why are we calling Godot a game engine rather than a game framework? Well, a game engine is a higher level framework. One way to think about it is that a game engine does more than a game framework. Let's look at this example. If you were to create a game with a game framework, you would have to manage game performance yourself. You would have to manually write code to manage game performance, such as memory management with a game engine. However, game performance is handled for you. Let's go ahead and take a look at a game framework called Mono games. Mono Game is a game framework.
If you have one hundred objects on the screen, your game performance is the same. Even if your camera does not have all objects in view, you, the programmer, have to implement a technique called culling. You have to do all of this manually. So in a sense, game frameworks give you the freedom to program your own game performance. Now in Godot, Unity, and other game engines, the game engines will help you improve performance under the hood. So if you were to have the same amount of objects, in this case one hundred objects, a game engine will help you improve performance because under the hood, the culling technique is done for you.
Now just so we're on the same page. Culling is a technique where you only send objects that the player can see on the screen to be rendered by the GPU. Culling is out of topic for this series and this course. The pros of game engines are that you get to focus more on your game instead of the underlying programming functionality that makes your game run. For example, you do not need to worry about implementing your own culling algorithm. You don't need to implement memory management features. You do not need to implement much of anything because game engines do everything and most things for you.
Now obviously, there are negatives to game engines, for one thing. You have less or no control of the under-the-hood functionalities that get your game up and running, such as the culling algorithm. That's why some programmers choose to write their own game engine, or instead, they make their own custom game framework.
And that's ok. That is an option.
Most of the time, a game engine will provide you with all the things you need. You never have to worry about lower-level programming. However, one thing to keep in mind is that you may need more features as your game evolves. More things that the game engine cannot provide for you. And that's when you know when you've outgrown your game engine and to start looking at either a game framework or creating your own game framework. Now let's take a look at game engines—first programming languages. Now a programming language is not tied to game engines. Most programming languages are general-purpose languages.
This means that they can be used to run anything. This includes scripts for your game engine. Let's take a look at C# as an example.
C# can be used in Unity game engine.
It can be used in mono game framework, and it can even be used in the .NET Web site framework if you wanted to make Web sites using C#. In this case since C# is a general-purpose programming language you are quite flexible in what you can program for, and with now, GDScript is a special case. GDScript is a programming language that is true but it is a domain-specific programming language. What that means is that it is built to be used by an application so any domain-specific language means that it has to be used with an application.
In this case, GDscript can only run with the Godot application. There are pros to this. Obviously, the benefits are that GDScript is built with game making in mind. It is a master of one, unlike general-purpose languages, which are built to be a jack of all trades. For example, a jack of all trades means that they do okay in everything; maybe they excel in one or two areas. Because of this, GDScript is just a master at one because it's built with game making in mind. This means that GDScript is easier to learn and use when programming games.
Now the negatives of using a domain-specific language, in this case, GDScript, is that you will lack underlying features you may find in general-purpose languages; for example, GDScript does not come with the necessary tools that you need to create your own Singleton's or your own private and protected keywords. However, the two things I listed are widespread in other languages, such as C#.
That's all I have for you in this episode. I hope you learned a lot. Thank you for joining me.
I look forward to seeing you in the next episode. Have an amazing day