It all depends on what you mean by “game engine”. A “game engine” is an “engine” for making a game of some kind. That’s it. What is involved in that depends on the type of game it is. You could write an engine that plays chess, using the “curses” text API for output. That would be a game engine. I wrote a big chunk of a game engine for interactive fiction games using JavaScript.

And then there are 2D and 3D graphical engines which, for performance reasons, are usually written in a highly performant language like C++. And a whole slew more. As many types of game engines as there are games.

So the first thing to work out is what type of game engine are you looking to write: what type of games. Then look at what is required to make those sorts of games playable and enjoyable (which includes things like deployability and performance). Then you can worry about which language fulfills the criteria you have established.

Until then, the question has no real answer.

I liked the pygame games that I used to build at the time, it was a nice approach to the software development career that I looked into.

You should be aware that the game engine that you will choose will be much more helpful than pygame, many of the things that you will have to define and deal with in your pygame program will happen behind the scenes of the engine without any intervention from you.

Today I use unreal engine (which doesn't make you use C++ but uses blueprint. You only need your programming skills to make your game) but I can also recommend the Godot engine (which also alow using C#) and if you want to develop in unity that is totally fine (although I do recommend you to keep being updated with any changes from the developing company, after the last fiasco, many users have left the engine)

With the xmake build system and Raylib graphics (and general games development) library, C++ is a much more viable option to getting started than it has been for the last 20 years.

When I first started, my only options were QBasic, C++ and assembler.

C++ was much simpler back then (shortly before the C++98 standard), and you worked more directly with the operating system and 2D graphics card.

As an example, this is a xmake cross-platform C++ file using rpclib, Raylib and sol2 (for seamless C++ bindings for lua, which also pulls in a Lua implementation):

add_requires("rpclib", "raylib", "sol2") 
target("project_name", function() 
    set_languages("c++20") 
    set_kind("binary") 
    add_files("src/*.cpp") 
    add_packages("rpclib", "raylib", "sol2") 
    add_headerfiles("src/*.hpp") 
 
    -- Copy lua scripts and assets when running via `xmake r` 
    before_run(function(target) 
        local targetdir = path.directory(target:targetfile()) 
        os.cp("$(scriptdir)/lua_scripts/*.lua", targetdir) 
        os.cp("$(scriptdir)/assets/*.*", targetdir) 
    end) 
end) 

I also found sol2 bindings for Raylib, which allows me to write the entire thing in Lua if I want.

2D games have fewer needs for an engine and are more likely to see them getting in the way.

The systems and libraries in them can be beneficial, but beyond collision libraries, I’d be hard-pressed to identify any genre or type of 2D game that called for a game engine.

Here are a few you could use:

1. Defold — Lua, HaXe
1. Lightweight. Fast performance and small download size on HTML5.
2. Support for Switch and Playstation.
3. It is a simple engine with only the tools you’ll need to make any game you want.
4. Brilliant 2D support (but is fully 3D).
2. Godot — GDScript (like Python), C#
1. Powerful node system.
2. Flexible enough to make full programs with the game engine.
3. Brilliant 2D and 3D support.
4. Custom Python-like script language designed for the game engine.
3. Unreal — Blueprint (visual scripting), C++
1. Industry standard.
2. No-code scripting (if that’s your thing).
3. Live coding in C++.
4. You can create a shader to give a convincing 2D pixel art effect for faster development of animations.
4. Phaser — JavaScript
1. First-class support for HTML5.
2. Small download footprint.
3. Good enough.

It doesn’t matter which one you choose. Just pick one and run with it. Everything is better than you need it to be.

• This is what Quora AI came up with.

A2A: Certainly. It’s a general-purpose programming language. There are several good GUI frameworks for it, frameworks that can facilitate the process. (I have used Python to make a simulator for the MegaMinx puzzle and generalizations of the Rubik’s Cube Puzzle to higher dimensions.) Both can be operated by mouse clicks or by gestures on a touch screen. Here’s a screen shot of the MegaMinx program:

(Tkinter is the GUI framework I used.)

Back in my day, we used to walk 20 miles through 10 feet of snow uphill both ways just to laugh at people who programmed in Python. Now, however, many universities are using it as an introduction to game design and even coding in general. Normally, I would discount this and suggest learning C, or C++. Fortunately for those not inclined towards actually coding, game building has become easier than ever before, with the advent of visual programming in game engines. With only a modicum of coding knowledge, one is able to create a complete, satisfactory game.

Since it is your first game project, and you already possess some familiarity with Python, then yes, I suggest you go with what you know. It will make the process a bit easier on you and give you some practical experience. If you plan to make more complicated games, then I would recommend moving to a proper engine and learning more of its coding/programming process after your first game is complete.

One of the projects i was working on when i had time (= between jobs :d) was a very classic, old-school low level 2d sprite-based game engine, suitable for platformers and the like. Just because.

It's actually a pretty fun thing to tackle, writing your own 2d engine, it's small enough that you can make it work by yourself within a few months rather than years, so it's not like a big 3d engine where it's a pie in the sky project where you never get to make a game with it.
It's still quite reasonable if a bit anachronistic to roll your own 2d engine.

Mostly my game engine (written in C++, on top of plain Win32) consisted of:
- graphics class (a low level canvas where you can draw lines, polygons or raw pixels)
- sprite class, for drawing animations and sprites by combining pieces from an image, as well as drawing bitmapped text
- tileset class, for managing tileset backgrounds
- a UI class hierarchy with simple components (buttons, panels, listbox, etc..)
- a simple physics engine (nothing fancy, just something that allows you to move objects around with some speed and trigger collision with other objects and the scenery)
- a simple sound class
- the main game loop / game state machine that tied all of this together, sent mouse and keyboard messages around, sent events to the UI objects, rendered all the sprites, updated all the physics objects, etc.. it's basically the "heart" of the game.
If you want to understand how basic games (and implicitly game engines) work, focus on this area, managing game state, game events and the main update/draw loop.
- the platform dependent Win32 drawing code in just a small file

I also wrote some file converters, a tileset editor and an animation editor using .NET / C++/CLI to go with them.
Really most of the work was in writing the sprite and physics classes, as well as the sprite editor.

🐍I Created A RAPID MATHS QUIZ game🐍

This Game or Code ask you 10 rapid Maths calculative questions.

The Game Consist of 3 Difficulty Levels i.e. 1,2,3.

Level 1 - Ask you addition of any two random integers between 0 -9.

Level 2 - Ask you addition of any two random integers between 10 -99.

Level 3 - Ask you addition of any two random integers between 100 -999.

Yes, of course.

Actually my very first video game with graphics was a 2D one written in Java, using a small engine based on JavaFX. It was a pretty good experience.

However, unless you really want to write your tiny 2D games on top of your tiny small 2D engine, I would suggest you to consider writing the engine in C, Rust or C++ and binding it through Java Native, leaving the Java part only for the scripting. Game engines get big and complex real fast. Of course you would learn a lot from the experience, but probably you would end up being limited by the language real fast. It would be wiser to learn the basic C++ (even in “Java Style”), at least then you won’t need to rewrite the whole thing if you run into limitations or if the project grows up much more than you originally expected.

I’d be surprised if there was nothing out there in the way of game engines for Python - but to be honest nobody writes significant games in Python.

It’s just too slow - and pauses for garbage collection are a pain to have to deal with.

Most games (and their engines) are written in C++.

Some game engines (and Unity3D comes to mind) are “scripted” using other languages (C# in that case) - but these systems presume that the vast proportion of the work is being done by the game engine itself (which, is in C++) for speed - and very little is done in the scripting language.

This does put limits on what can be done with that kind of game engine.

Honestly - if you’re serious about writing games - don’t use Python.

Learn C++ - it’s what very nearly 100% of games are using on desktops, laptops and game consoles.

Things are a little different in the world of cellphone games - but even then Python is not the choice people seem to be making.

I am trying to create a very minimal "flyweight" game engine.
So far it is running something that looks like Asteroids.
There really is not a lot of lines of code in this micro engine. And the game code itself is really just one short file.

A lot of developers use object oriented inheritance to specify the behaviour for each item in the game. This works but leads to complexity and duplication. (see the video below)

I have adopted what has become a standard design pattern for games.
You create standardised entities to represent all game objects. Everything is an entity. There are no subclasses. The space ship, the asteroids, the bullets etc. all entities stored in an array.

An entity is just an array of components. Components are simple objects which hold state information and respond to "update" events each game tick.

One component might handle the movement of items in the 2d word. In asteroids, all the moving entites have an unique instance of the same move component. The component is a class which provides the power of movement.

So the asteroid entity has a move&collide component and a draw component.

The ship has move&collide, draw, and input components. We build the player spaceship, by simply adding three standard components to the entity item.

final class PlayerShip:Entity 
{     
    init(position:Vector2) 
    { 
        super.init() 
        addComponent(Move2dComponent(position:position , velocity:Vector2(0,0), orientation:Angle(degrees: 90))) 
        addComponent(InputComponent()) 
        addComponent(Draw2dComponent(name:"Ship", submesh: LineSubmesh.spaceShip.asMtlSubmesh())) 
    } 
} 

and so on.

Done right, the entire logic for a simple game ends-up as a surprisingly short file.

If you are mad enough to try writing a game engine from scratch. I really recommend this design pattern.

Well first off, if you are asking that question you probably shouldn't. Building a game engine is similar to something like writing an encryption algorithm. You can do it, but it will take you a long time and not work as well as preexisting tools that have decades of work and experience behind them.

That out of the way I would point you to the videos of The Cherno on YouTube. He is a game engine programmer and he is building an engine on his channel so he will cover all the steps.

Essentially though it depends on what you want your engine to support. You will most likely need a render pipeline for drawing graphics, a entity manager, a bunch of game objects(like the camera), support for a scripting language, and depending on. The game a physics engine, particle system, a ui for building games, sound effect system, and so on.

Most people I've watched build them tend to start with the render pipeline because it is nice to start seeing things drawn to the screen early on. Helps to stave off the giving up.

I can say, I am about 70 percent a Unity expert or more, but I cannot move a simple 2D image in Unity, but I can make 10 3D vehicles to move around, collide with each other, react to collision, predict or animate reactions to collisions, change color and more. What is the point, Will. I have a 110 percent will to make 3D games but no interest on 2D games. It wouldn’t take me up to 2 days to learn 2D game creation in Unity, as Unity is already my expertise and Platform for game development, codes and functions in 2D are usually variants of codes in 3D, there are exceptions, though.

To answer your question directly, Unity is the most documented engine to make 2D and 3D games. This answer comes from my research online which puts Unity above others even Unreal when it comes to documentation. The two most advanced will be Unity and Unreal Engine, there are others too.

The pictures below are from my new car racing game, The Rider, which will be released on most devices and systems this year. http://Ameritel.co/games.html

In the picture directly above, I am writing codes than turn on and off the headlights, the traffigator lights and the brake lights of this car, a Bentley Continental. The little bulbs or circles in the lower left sub Window are materials, which are used to paint my lights or add texture, to get the correct colour and feel of car lights. Currently, the headlights of the car are on. I am using C# and Unity, here.

Here, I use Blender to pose (create different human positions) and animate my 3D characters, which I created in another Software. I am yet to name them. These are some of the characters or drivers in my new game, The Rider, which is in development by me.

It depends on the game you want to make, which platforms you want to support, and what you mean by “a game engine” which I find many people use in different ways.

You will need some way to get sprites on the screen.

If you want to support more than one platform then you will at least need a library like SDL or SFML or OpenGL + GLFW. I consider such libraries “hardware abstraction layers”; however, not game engines. You could also roll your own hardware abstraction layer by putting graphics calls in per-platform .cpp files providing definitions for declarations made in platform independent .h files; however, I see no real benefit to doing this yourself rather than just using one of SDL et. al.

If you want to support multiple platforms and the multiple platforms include mobile devices, I’d consider using cocos2d-x — which I would call “a framework” not an engine.

You can use Godot with C++ in a couple of ways but honestly if you are going to use Godot I wouldn’t bother with C++: just use Godot’s scripting language. I’d consider Godot if I needed features that Godot makes easier. Maybe, complex skeletal animation, for example. Calling into Godot from C++ just feels like you are dead set on using C++ but do not really understand what Godot is all about.

I’d only consider any of the real 3D engines for a 2D game if the game needed extensive custom 3D effects, but in which case it is not really a 2D game.

Simple is better. If I was pressed for time and working solo/very small group then I'd make a text-based rogue like. Because I know I have the art skills needed to use ASCII characters to make a game.

So can pygame work for some random game idea you may or may not have but haven't shared. Probably.

Its generally a better idea to have the kernel of your game idea and gameplay figured out and THEN figure out the tools that will let you prototype that in the shortest time/with the least effort. For something like this (6 month contest where you will be working part time and likely sporadically) then speed and simplicity matters most.

Single player, MP local, MP networked?
Type of camera?
Scrolling/roaming world or constrained to the screen?
Do you need skinned mesh animation?
Gamepad support?
Mobile device support?

Figure out your requirements first.

Game maker studio

I can't say it's the best game engine of all since it's the only one I used but personally I liked it.

It has a nice user interface where your resources(sprites,sounds etc) are organised into folders already created for you.

It has a sprite editor which provides many good functionalities like mirror transform, or rotation and more. Loading sprites is really easy. Animation of a sprite is divided sub images, it makes it really easy to manipulate when coding and stiff

It also has level editor. It creates levels called rooms in it. You can very easily do mapping in it by loading your tileset for topdown -rpg or use background for platformers. It also has inbuilt collision system(precise and symmetrical shapes collision though use of precise isnt generally recommended)

It has a feature called timelines(which I haven't used a lot personally) but it's useful in creating patterns of enemies in a manner you want that appear after a interval thus you can control the gameplay better in a easy way.

It uses objects that would form the basis of interaction between player and game, stores code in one place and basically is the main thing that you will focus a lot on.

It features ready-made code in form of drag and drop and actions, you can literally design a movement system from scratch in minutes(albeit a simple one)

Since you want to code you can start using game maker language to do a bit more advanced things though granted it won't take you to the level of what language like c++ would plus it has a lot of inbuilt functions which makes many things really easy, but still starting here is starting somewhere and some of its tools aren't perfect so you would need to think real hard to solve some problems so it would definitely increase your problem solving skills. plus it has a debugger and a nice editor that instantly shows syntax errors etc.trust me debugging will take a lot of your time since your new so the experience it will give will definitely be useful

You can also store the code in scripts to better organize your code and allow reuse of it.

It has many more features like views, shader,etc but I find game maker studio to be good for 2d.

Game maker studio 2 is out, and there are plenty of tutorials..

A text based game in Python is absolutely doable - it hardly needs an engine (an engine is normally a set of libraries that do complex things like co-ordinating sound, graphics, physics, etc). In a text based RPG you have no need for anything complex, the design of the actual ‘game’ (in other words which rooms lead to which other rooms, what is in each room, what the monster do) - that part of the design is a lot more complex than the code needed to move between rooms etc.

The base of a simple RPG in Python can be implemented as dictionaries (one for the rooms, one for the items, and one for the monsters maybe), and as few as 100 lines of code.

Now, in response to Christopher Dumas’ claim to python’s failure, I rebuke that. Python is a great place to get started with coding, even though you do need to do a little reading on classes and functions (and different data methods) before you get started. (Make sure you read about their types!!) Generally, Pygame is the one of choice. PyGame Game Creation - This is my Blog Post - Unfortunately, I'm at the stage you’re at with making games. My Problem is not how hard, its how the program reacts to multiple functions operating on it at the same time. (The Window in Particular)

Otherwise, if you were willing to consider learning sudo-code in gamemaker, another great 2D game engine; I would recommend you start there before moving to this more advanced field of study.

After Python; I would Suggest Java or Java-script for Object-Oriented-Programming to really sink in. Java (programming language) , JavaScript (programming language) , GameMaker , Python (programming language) , PyGame Game Creation

Congrats on setting yourself on one of the more complex tasks in development.

To start with, let’s break down video games to as simple a system as possible: At its most basic, all game engines do three things: Draw output, handle input, and simulate. The order of these things can get quite complicated, but the most basic game engine is just an infinite loop:

while True: 
    inputs = handle_input() 
    draw_objects = simulate(inputs) 
    draw(draw_objects) 

This is super basic, but would actually let you run a number of simple games just by defining these functions. Text based games survive well with a loop this simple.

As you continue to make games, you’ll realize there’s other features you want. You want clocks for timing in game actions. You want message passing of some sort (so objects can talk to each other without needing to know the exact objects floating around. You might end up wanting fixed step simulation.

All of these complicate our simple loop. Say you want a basic clock.

from time import monotonic 
 
last_frame = monotonic() 
 
while True: 
    inputs = handle_input() 
    now = monotonic() 
    time_delta = now - last_frame 
    draw_objects = simulate(inputs, time_delta) 
    last_frame = now 
    draw(draw_objects) 

Notice that just adding a simple time delta doubled the length of our main loop.

Eventually, adding new features to this simple main loop is going to get a lot harder. After all, every feature needs to insert itself at given places in the event loop. You’ll eventually want to decide on a way to compose your main loop based on the features you want.

For previous art, consider pursuedpybear: The main loop is about 15 lines of code, but because we use a heartbeat event at the core, every subsystem and feature can determine it’s own important timings, which the engine itself doesn’t need to know about.

The reality is: building an engine is a task that is almost never complete. You can build simple ones as you need them, but if you’re looking to build a general purpose engine you probably don’t want to spend 5–10 years on the project.

Summary:

Start with the simplest possible engine, a loop that handles inputs, simulates, and draws in that order. Add to it as you need new features. Save building a general purpose engine for once you’ve developed enough opinions about the engines that you have access to determine if you need something new.