What exactly is a "game engine"?

Hi there I’m trying to get something clarified. What exactly is a game engine? I have heard people say that Unity and Game Maker and Unreal are all engines, but i was under the impression that a game engine is a whole bunch of code and what not that you import into a program like Unity or Game Maker that essentially creates things like controlling the character and gravity for you so you can hit the ground running with your game and dont have to do a lot of the coding yourself.

Also, is it common practice to use engines like this, where you dont have to do a lot of the coding yourself and can focus more on the art, atmosphere, story and what not?

An engine is a tool that takes care of the bits of code that are common to multiple games. Pretty much every game needs a render pipeline, so engines take care of that. Many games use physics… And so on.

1 Like

Game engine is a program that displays everything you see while playing a game and responds to your input/interactions.

That’s pretty much the whole definition.

Using stock engines is currently a better idea than writing your own.

1 Like

Importing code into an engine / ide would better be described as a library. Or a package. Or a module.

2 Likes

So what do you think of importing code into Unity to make lets say a 2D game (character control, gravity, etc) so you can begin working on artwork, story and what not, as opposed to coding it from the ground up? I’m torn between two thoughts. 1 : should I use Unity and code everything from the start ( the control of the player, the gravity, everything basically ), or should I use an existing engine or “library” so I can hit the ground running and not worry about a lot of the coding for things like that?

I’m new to this clearly so I appreciate any help on the subject

A game engine is basically an all-in-one environment that comes with premade solutions for everything from importing your assets to working with them (slicing sprite frames, animating things) resulting in the format required by the underlying graphics engine and other systems to readily use, support for doing a lot of common functionality is just built-in and accessible even from within the core piece (which is basically called The Editor).

I look at it like game development on tracks. In a sense it is a system of not only the underlying bits but also the workflows.

In contrast, you can get much of the benefit by simply using existing APIs. For example if you used C++ you may choose Urtho3D or Ogre3D or whatever as your means of working with 3D objects. Then you may use OpenAL or another audio library and perhaps a tracker lib for your music.

The difference is basically in the one approach one clear workflow and development approach has already been established / chosen for you. In the other approach you decide which libraries and things to use and you deal with getting them to play nice together.

In practice these things can cross over somewhat. For example, you may find some game library that includes everything you need to deal with everything from graphics, audio, input and even physics. And you may find assets created for a game engine that provide alternate ways of doing things and extending the base functionality in the process. However, with the second option everything is always still built upon the existing core framework of the game engine. You won’t find an asset that completely replaces the graphics engine or audio engine. You’ll find another layer built on top of the existing functionality that gives you a different behavior and / or workflow.

So if you find a game engine that really clicks for you and you like the way it does things you can save a lot of time by using it. If not then you either use the GE at its most basic fundamental level and build on top of it or piece together / build your own components into your own custom game engine. Which way is best just depends on you and your experience. What you are used to working with.

The definition of engine can be a little blurry sometimes, and is often confused with libraries which are not the same thing.

A library is usually a collection of functions designed for a very specific purpose. For example, Bullet is a library for simulating rigid body physics, but nothing else.

An engine is a more complete, integrated system. It covers all aspects of game development, including rendering, physics, file system, audio and so on. It will also contain hooks for gameplay logic so you can write your own. The fact that each aspect is integrated into one solution is what distinguishes it from a collection of libraries.

Some game engines will have toolsets built-in, but not always. Modern, general-purpose engines almost always will though to ease adoption and encourage people to stick with it.

That is pretty much all there is to it. The first engines were basically code reuse. They slowly became more refined and formalized. In some cases the engines became more critical than the games. Torque, for example, grew out Tribes 2. Whenever we needed broad features for a game, they would first go by the engine team to see it was prudent to add the feature at an engine level instead of a game level. It kept growing the engine in a meaningful way. Unity is one of the first engines that actually was built as an engine and not as practical code/tools reuse.

1 Like

? My understanding was Unity grew out of a failed game project. The devs decided to salvage what they had and make it an engine. I could be wrong on this.

I heard that the Unity Engine was actually unearthed in a digsite in Egypt and it took them 50 years to decipher its true meaning.

1 Like

Aliens

1 Like

I’m going to complicate things a bit. As @Neoptolemus alluded to, some engines have a lot of toolsets that are built into the engine, like Unity, UE4, and Game Maker. This actually classifies them as Game Authoring Tools. However, what sets Unity and UE4 apart from something like GameMaker is that you don’t actually have to use those tools to make the game with the engine, although it makes game development a lot more efficient and timely.

Hmmm maybe. I thought the story was they failed at building games in general, so just focused on the tech. In either case, typical engines growth is driven by needs of specific games (or rather that was the way). Unity was kinda the first that grew as engine for its own sake.

1 Like

Fixed

1 Like

Do whatever gets the job done with the least time/cost/risk.

Using pre-built engines, libraries and assets is great because it means you get to take advantage of work already done instead of doing it again yourself. It has down sides - you may lose some performance or flexibility, and you may be reliant on the developer for some things - but in many cases they’re easily eclipsed by the time/cost/risk saving.

That said, if you want to develop games then it’s also important that you spend some time investing in your own skills. If you just get everything off the shelf you won’t learn nearly as much as if you’re building things for yourself. Plus, the more development skills you have of your own the more you’ll be able to get out of those off-the-shelf packages by extending them, modifying them or building on top of them.

Almost all of my projects use a lot of both approaches. Anything unique to my game I’m building myself on top of whatever engine I’m using (typically Unity these days). Anything not unique I’ll try to base on something existing, because that gives me more time for the things that are unique - and the unique parts of my game are the sole reason people will be interested in playing it.

Anyway, my advice to newbies is to put separate time into both learning Unity and learning programming (or your field of choice). This is because “game programming” isn’t a subset of programming, it’s a specialisation. With the tools available today there’s no reason you can’t jump straight in and start making stuff, but if you care about your skills then you’ll want to put some deliberate practice into learning and honing them, ensuring that you’ve grasped the fundamentals. If you skip this you’ll pay for it later, generally by making life far harder than it had to be.

2 Likes

The story I remember kind of fits both of these. I don’t know if it was a “failed” game as such, but they were definitely making something and decided that the tools were far better than the project itself, so they switched focus to that.

1 Like

Thanks for the input everyone. I would definitely like to learn to program everything myself, but i would also like to start making a sidescroller as well, and at the moment, if i were to code everything myself, it would be a long time before i could see any result. Does anyone have any suggestions on the best way to learn coding with either unity or game maker. I find when i watch tutorials on youtube that im basically just copying what theyre doing, and when i go to do it by myself i cant remember any of it

1 Like

I know this sounds as boring as all heck, but I’d suggest getting one of those “Teah yourself C#” type books and doing a chapter each night.

Once you’re comfortable writing code, then jump into Unity and apply what you’ve learned there.

Alternatively, if you want to jump right into the “code in Unity” part, check out the scripting tutorials in the Learn section, linked at the top of the page.

Edit: Also, I should mention, there are courses for this stuff.

At one point that was my understanding too but I’m not positive now. Some quick searching, related mostly to another thread, indicates that GooBall may have assisted with the early funding of the company. Additionally the game seems to consistently score an 8 out of 10 for every review I’ve found.

https://www.wpi.edu/Pubs/E-project/Available/E-project-030614-143124/unrestricted/Haas_IQP_Final.pdf (top of page 8)

2 Likes