how to start

1. the quickest way to make a game is: well.. to make one! Making a top-down 2D game such as a shoot ‘em up (shmup) is the best way that I know how to learn. Every game engine should have a top-down 2D tutorial to get you started. Use that as the base, then go from there, adding cool projectiles, player movement, etc. I suggest starting with one of the much-loved simpler 2D-centric game engines (see much loved first game engines). After that

2. try the Unity or Godot tutorial and make a shmup yet again to quickly get familiar with the editor-style workflow and api, but this time, after that’s complete, make it one more time, in 3D! :O Even if you don’t like it, it’s worth trying the editor-entity-component style for a week or two, or at least a weekend game jam! Then

3. the choice between a simple code-only near-complete 2D game engine, a complete game-making graphical interface, or a more bare-bones framework will become more clear, depending on the project needs.

I’d suggest sticking to the modern language route, particularly C#, or Haxe for the smaller community vibe. Note: the communities behind Unity and MonoGame are huge, tons of activity on the forums and discord servers.

a quick note about the engines i listed:

much of it is merely out of personal personal taste and gut feeling, yet, there are some underlying reasons: game engines that are either written in C (not C++), or can interop with C and have a fast interpreter (Lua, Wren), or can compile to C or C++ (all can?), are chosen because they enable the engine to have the potential to be cross-platform, since most hardware devices use C, and thus the most popular and most performant open-source low-level libraries, SDL and GLFW are written in C. I also favored languages that are fast, performing at near-C speeds (update: as it turns out, the GPU code is probably the most important, and it doesn’t really matter what language sends the GPU instructions, because those instructions are the same?). Thus, there are no engines listed that use pop "scripting" languages such as python (pygame), javascript (i loathe web dev and it’s entire trajectory), and ruby, because initially they all had slow interpreters (maybe have better compiler implementations using C now tho). Also, i just don’t care about super duper engines with a complexity of Unreal, as i am but a mere mortal. Furthermore, libraries written in C can always have language bindings, making them the most flexible, in addition to being amongst the most performant.

a snippet of text from Spitko

"3d stuff in particular needs engine integration to work properly, else you have to do a bunch of duplicated work around shaders, internal formats, etc. If you want more generic editors, they do exit to a degree, but similar to Tiled they're generic to a point where you're fairly limited with how deeply you can integrate, and often end up with awkward toolchains."

a list of video game engines

https://www.vulkan.org/tools

• todo: go through this list?

main editor-based engines

• Unity(3D), Mono, C#, custom UnityScript, 3d emphasis along with solid 2D (even with mobile devices—it has a bajillion optimizations), the best cross-platform solution—truly one-click!!, the titan of all game engines for individuals, although closed-source the C# code is available for “reference” on github (the C++ code is not); although it doesn’t reek of immoral people, it has the stench of bloated-ness, advertising, and an asset store deeply trenched in capitalism (though nowhere near as immoral or awful as Roblox); yet, if you stay sane, you can make anything with it as it provides you with a complete engine, likely without ever touching the asset store
  • Spitko said, "If I wanted to make a serious 3d project I'd probably look towards Unity. The 3d stuff I typically do is a lot more simple so heaps is fine; though I have some 3d toolchain work to look at for a prototype I want to build. Need to finish my world, material, and model editors first though, and that has further dependencies on fixing the rotted bullet bindings. way too much to get done before LD."
• Godot, 2D/3D, C/C++ core, custom scripting language, custom(?) visual scripting language, community-maintained bindings to several languages including C# (quality not guaranteed), 2d emphasis along with great 3d, open-source, small 20mb standalone size, the C/C++ core makes it a really really cool way to get handle of C++, using it as leaping stone to more DIY-style modular engines, yet also retaining all of the programming power higher-level languages through bindings, has a much better indie/gamer vibe as it’s the only open-source non-commercial engine among it’s competition of engines with an editor
  • Spitko said, "I've used Godot. It's fine for 2d stuff, but I extremely dislike GDScript, and the workflow for native is unpleasant vs heaps/hl"
• Unreal, C++, 3D, mainly 3D and it sounds like you’d be hacking into it in order to do 2D, although it seems like you need a very advanced team to use it, many people have made stuff at game james with it, reeks of shit “AAA” games and human-labor-abusing companies, yet, the Unreal Engine people themselves (Epic?) seem alright, giving back with grants ‘n stuff... maybe..?
• Luxe, C/Wren, 2D, well-designed stuff by the snowkit collective’s ruby0x1, stuck in closed-beta for a long long time, but appears to be the game engine of my dreams, the original one was much loved for it’s design, it is all made by one person(!!!) and so an individual's soul was truly put into it, and you can feel it! but because there's only one person (also got with a few helpers) mainly working on it, one just cannot expect as much as Godot or non-editor game engines; it's potential will rely hav to rely on the community it attracts
  • follow https://luxeengine.com/

programming-only first game engines people have fond memories of <3 <3:

these make good first engines for programmers, as the engine size is tolerable, readable, and simple, providing helper classes ‘n functions, yet abstracting the low-level stuff away from youthful eyes

• Raylib, 2D/3D, single-header-style C, GLFW, this is probably the best step into making games, it already has language bindings for 50+ languages(!!!)—although, i’m not so sure about bindings for external libraries such as it’s gui, it seems more similar to “creative frameworks” such as OpenFrameworks wherein all of the functions you need are in easy reach but because this is in C it's goes to the extreme of putting it all in one giant class(!), so that all you have to do is include raylib.h and call DrawCircle, DrawButton, LoadTexture, and you’re good to go! I’m not sure if it actually provides game-specific libs such as scene handling, 2d scene tree, etc... but it does have several libs ‘n tools, such as one for an immediate gui—this makes it even compelling for making creative tool apps with! :o
  • although C may be enough for simple n creative apps, i'd imagine you'll eventually want a language that allows object oriented programming paradigm (but who knows??)
• HaxePunk, 2D, Haxe, OpenFL & Lime “back-end” libs, abandoned, FlashPunk was my first and favorite engine but it never seemed to stay alive, though, it seems to have transcended with the users, as people made their own engines resembling FlashPunk. i think many of the original Punks initially ran to XNA/MonoGame. although abandoned, it’s probably just fine, just some years of OpenFL updates, mobile targets however might require a bit of work... note: inactive since at least 2018, but it’s back-end OpenFL is still alive ‘n well, so, i believe it’d be easy to update
• Nez, 2D, C#, MonoGame back-end, this is a complete 2D game engine built on top of MonoGame providing everything you need (scene handling, entity, collisions?, etc.), maybe comparable to HaxePunk(?), and also a way to jump into MonoGame and make stuff without actually having to build your own engine as MonoGame is a very very bare framework, then after having enough experience working within MonoGame you can probably make your own engine, or just customize this one to your liking
• Love(2D), Lua, a small engine that many people seem to... love. Sounds like a great start to Lua too!
• HaxeFlixel, 2D, Haxe, OpenFL & Lime(?), all off the Flash programmers probably ran here, still active as of 2022!!!— that’s incredible really..., seems to even have kept up Switch support (via OpenFL)—one console is more than enough imo, Flixel has always been the rather popular big brother of HaxePunk, there’s no doubt that it’s the more beginner-friendly, with documentation written for beginners, a great debug console, etc. etc., but it also all comes with a feeling of bloatedness and often just bad design: not modular, inheritance problems, tons of unnecessary vars, etc., making it feel more like a 2d platformer engine (as it started as) rather than a general one
• Gideros(Mobile), Lua, 2D, mobile-focused, comparable to Corona / Cocos2D (without the IDE), but with a tiny non-commercial-backed community, apparently the code is so stable that games made in 2012 still work, yet it is still being updated as of 2022!, also the android support and exe size are excellent, i’ve rarely heard about this one, but who knows??

second “engine”-frameworks, coding-first-style / non-game-editor:

these are more programmer-oriented, more freedom—the ability to make anything without constraints, but at the cost of game engine features, and i mean features!!! Instead, they are more modular-oriented, so, instead of providing you with an entity/object system, collision system, tweening system, a physics system, etc., you will have to integrate (or make) these libs yourself. It’s a sort of assemble your own engine approach... Unlike the big 2D-only engines and most of the “first-love” 2d game engines, these make for better jumps to 3D, and, well, to the path of becoming a true game and game engine programmer. With these there really are no limitations, you have access to everything and are in control of everything too,.. it’ll just take quite a bit of time to figure out the framework and assemble your engine. If you’ve got a big project, then these are the way to go, as these frameworks will never constrain nor limit the scope of your project. If you just want to quickly prototype something that uses commonly used game features, then these are not the way to go: use either the editor-based game engines or the first love engines. However, if your prototype requires some low-level access, specific libraries (rendering, physics, etc.), then these are the way to go. Note: Raylib is rather exceptional in that it also is like a framework in that it has nearly no constraint nor limits, providing you with low-level access to everything.

• MonoGame, 2D/3D, C#, Mono framework (open-source version of .NET) an indie darling all the way back to Fez, to Stardew Valley, Bastion/Hades/etc., and up-to Celeste. started as an open-source port of Microsoft Xbox’s XNA framework, but be warned: it’s barely even an io framework*. still alive: updated to .NET 5 in the beginning of 2022, 4.0 will be the last version compatible with XNA, so it'll finally break free and be it's own revision; still perhaps the main alternative to the game-editor-based engines; people find this to be very similar to LibGDX, and many engine-makers are inspired by XNA's work-flow
  • MonoGame Extended, you’ll need this, or something like this for the actual game-part of framework (at the least it’s entity system, scene system, and collision system)
  • FNA, open-source XNA 4.0(?), rock stable frozen version kept for porting and longevity
• Heaps, 2D/3D separate engine modules, Haxe (then to C or bytecode via HashLink(?)), made by the maker of the Haxe programming language, contains a framework who’s 2D module resembles HaxePunk’s core without it’s features (no collision/“masks”, no entity, no tween lib, etc.) and without it’s extra helper functions. It however does include essential features such as scene handling and a scene tree, placing it’s features-set somewhere between MonoGame and MonoGame Extended (for both 2D and 3D) or confusingly along-side the other Haxe frameworks NME and OpenGL, still never constraining or limiting the maker.
• This would have been my personal choice, but, unfortunately, there is almost no community, the documentation is spartan, and it seems everyone wastes time looking for the right functions in the right class, and trial and error (this is partly due to everything having public functions, in order to make everything accessible / modifiable). It is used as an in-house engine for a game company, and it feels that way. Having said that, it’s still an amazing framework, very well-written, written for modularity, and you have access to anything, probably all the way down to the SDL wrapper, and you can modify anything as it’s open-source. This is the best alternative to MonoGame (with Extended libs) i know of. Of note: there’s a heaps-specific integration to haxe-ui, making it a very compelling case to make experimental / creative apps with too (i mean, a UI widget is just a sprite, isn't it? :) ). Examples: Dead Cells, Northgard
• custom game engines, worth mentioning: i’m guessing most great games (of my generation) had engines built specifically for the game and even specifically for the target console (those poor souls!!), but that has changed as these open-source engines get better ‘n better :)

the Haxe confusion

• NME, Haxe, GLFW, renderer-abstracted (now including Metal support), high-level flash-inspired api (graphics drawing, display list?) but not a port of Flash--it's more original, a very cool alternative to older C++/Java "creative frameworks" and MonoGame, using this as a base one can make nearly anything and target any device and yet still have the comfort of high-level and power of Haxe; this was/is always criminally unpopular because it's fork (OpenFL) captured all the attention of the pop Flash makers, and unfortunately has always been confused to understand the difference between the two, also it felt more abandoned because there are less commits and a tiny community (if any)
  • the person who wrote this, Hugh Sanders, also wrote hxcpp, the Haxe to C++ compiler, thus enabling Haxe to compile to iOS and most embedded targets (thus, i personally wouldn't doubt the quality of NME)
  • a little off-topic, but, i personally would use this as a base for normal non-game gui apps, if i don't care for getting a native look, otherwise, i'd have to use Flutter
• OpenFL, (todo: fetch text), Haxe, originally forked from NME (v4?), mirroring more closely to Flash it became the open-source port of the Flash api (like MonoGame or FNA does for XNA), thus carrying along with it the two then popular Flash game frameworks HaxeFlixel and HaxePunk; and thanks to Haxe's compiler options, making it a better and much faster solution than even Adobe's AIR; this was popular after Flash died, and still kept up-to-date as of 2022, along with HaxeFlixel. I personally don't know the actual differences between this and NME... but from here-say, Lime is a mess

/* // TODO: combine this with the second engine-frameworks

high-level io frameworks:

probably could also be used like a “creative” framework to make just about anything, but providing a more familiar game engine feel to it, making integrations of common game-related features much easier / common

• Beef’s corelib folder, just a wrapper over SDL? */

2D commercial engines

all of these reek of the nasty smell of degrading immoral mobile “game” companies, god-awful Facebook “games”, and gambling companies (in shady places like Russia and China); i think for that reason alone, i’ve avoided these

• Defold, 2D/slight 3D, Lua, became open source rather recently (2020?), great for mobile, modular building results in a tiny executable, great tutorials, easy to get started, no-autocomplete in the provided IDE’s code editor??, perhaps the best alternative to Godot (but must really research and decide if the company is truly evil: are their games evil? is their work culture evil? ..and so on)
• Cocos2D, C++, open-source, used to make shitty 2D mobile games for over a decade, now comes with a complete IDE (Cocos Creator), the Obj-c version was especially popular to make iOS games back in the day, i personally used this once for a local-networked iOS game, and after that, i stopped using a computer for a decade, how much of that was actually causal is a philosophical problem :D
• Solar2D (aka CoronaSDK, lol), open-source, C/Lua, also used to make shitty 2D mobile games for over a decade, no editor, maybe the next setup up from Love2D, i have a friend that used this to make simple mobile games at a company..

third engines, the next generation

most of these aim to be modular / dependency-free

experimental indie-made engines / the future

made with love by FlashPunk OGs

• all of these are kinda experimental, but they are written so simply and so well, i personally feel i can jump into any. :)
• Foster, super clean modern (.NET 5 or 6) C#, up-to-date as of 2022, basically just a giant interface for different backends (SDL, GLFW, Vulkan, etc.): a modern io framework, similar to MonoGame but written much more simply and far more flexible / future-proof, note: this is not a game engine and therefore does not contains any game engine features
• Rise, abandoned?, by the FlashPunk man himself, looks like a C#/SDL successor to FlashPunk
• blah, C++, up-to-date as of 2021?, maybe newer than Foster? or simultaneous? seems more experimental
• StrawberryBF, Beef programming language, up-to-date as of 2021?, also seems quite experimental, made by Maddy, an absolutely disgusting name tho, ew :/
  • the old tool-set: https://celestegame.tumblr.com/tools
    • their sound tool, FMOD, became a tutorial!
      • https://www.fmod.com/resources/documentation-studio?version=2.02&page=appendix-a-celeste.html
• Luxe, (see elsewhere)
• Monocle, C#, MonoGame back-end, abandoned or closed-source, a bit old than the rest of these, but it was used to make Celeste, a pre-cursor to Foster

made by everyone else

• Beef2D, beef, 2d, included in the main Beef language repo
• Pile, beef, more like Foster: has a modular renderer component
• Dinghy, C#, in development, very new as of 2021, built on top of Kinc (which makes it a little different from Foster, as Kinc does the job of handling and supporting io stuff)
  • https://dinghy.xyz/
  • he also made this JSON editing tool similar to Nicholas’s (of Haxe ‘n Heaps) CastleDB
    • https://github.com/afterschoolstudio/Depot
• Arcane, Haxe, on top of Kinc, Zeta's game engine
  • https://github.com/Apprentice-Alchemist/Arcane

the Rust world

• amethyst game libs, includes: an ECS with parallelism, another ECS, a build-your-own-engine toolkit, an asset pipeline tool, and more

• bevy, the current most popular game engine in Rust

  • https://github.com/amethyst

• macroquad, "raylib inspired", meant to be beginner-friendly, so that you don't really have to worry about the borrow-checker stuff, making it a very good entry point into Rust

  • https://github.com/not-fl3/macroquad

• Fyrox, aka rg3d, 3d, with an editor

  • https://github.com/FyroxEngine/Fyrox

• wgpu, follows webgpu standards

https://amethyst.rs/posts/amethyst--starting-fresh

• a good article, a post written for the end of the amethyst engine, listing many libs 'n engines that will move forward

experimental technical stuff

these just seem too technical for me, toward the modern C++ modular header-only trend. Many rely on pop C/C++ libs such as: SDL, GLFW (for OpenGL and Vulkan?), bgfx(?), openAL, imgui, etc. Have to be careful of these, as it gets easier to make game engines, programmer-personality people just seem to make them naturally, without much reason, and often lack any sort of vision or long-term mentality, often becoming abandoned school projects. It’s better to stick with indie game devs whom have a serious life-long passion motivating their works, or at-least some games they plan to keep forever.

• EntTT, C++, just an entity system??, used in Minecraft and the Diablo II remake
• nCine, Lua, more along the level of i/o engines like SFML i think
• nimGL, Nim, graphics layer?
• ?, Crystal, i think there was one in written in Crystal..??
• Halley, C++, inspired Foster
• Kha, Haxe, self-claimed to be low-level, this one is kinda esoteric, a very quirky man is behind it, lol, used in Armory

other 3D

i have no clue about these

• Urho3d, C++, inspired by Ogre3d (and sounds like an ogre’s name too! 👹)
• Armory(3d?), a game engine inside the industrial animation software Blender??, sounds very specific... like for making Ghibli-animation-level games?
• Panda3d, ??

non-programming interfaces:

• GameMaker, with and without programing—this allowed people who don’t know programming to learn in a very intuitive way and most importantly by following intrinsic passion, custom scripting language, the grand-daddy of all non-programming "game makers", examples: Rivals of Aether (Dan had to wait for the big GM2 update before releasing it on the Switch, and even then, it took 3 years to port), Hyper Light Drifter
• Construct, no programming, back in 2013 this thing worked like a dream, even on console!, I have no clue how it is now...
• GDevelop, a newer one worth looking at, open-source, i think scriptable too, maybe even C/C++!
• Stencyl, not sure if this one’s still alive... made in Haxe!, and maybe can even script with it!?!? that alone makes it a top pick for me! <3

specialized:

• Pico-8, a “fantasy console”, just from this page about the development of voxatron, full of little GIFs that display truly awesome little features, what’s there not to love?—well, for one, i’m not a pixel, and definitely not a voxel (vomit) lover :(. Beyond that though, this is truly a charming little world, possibly even a model for any game-maker community project

genre-specific stuff:

despite that limitation, these are quite popular in game jams, where content > programming-needed design

• M.U.G.E.N., fighting games!!!, but likely old and limiting :(
• RPG game maker
• adventure game maker
• ?, visual novel maker
• etc.

software frameworks

these can be used or combined to help you make your own game engine

media frameworks, media layers, foundational frameworks, io frameworks, back-ends, etc.

these provide access to the platform’s input and output (graphics, “contexts”, etc.), windowing, and often including audio and font rendering too not ordered

classics:

• SDL(2), C, the de facto library, usually used as a core library, then accessed through a higher-level language, serves as the base of most game engines*, written in straight C that can be difficult to understand, has a history of porting games to Linux (and therefore the beginning of games for Linux, often open-source), supported by Valve, there’s really no competition
• GLFW, like a SDL but only handles input and graphical output and windowing, no audio/font/etc., low-level people seem to really like this one
• SFML, C++, for object-oriented thinking people, more accessible for creative / DIY people who want to tinker really low-level stuff, but it seems no one likes it...
  • also, i'm not sure if it'd be easy to write bindings for this because it's C++...
• Allegro, Java?, ?

the new old:

• Kinc, “low-level game library and hardware abstraction”, used as the base of Kha
• LWJGL, Java, maybe the new LibGDX?, OpenGL/OpenAL/OpenCL
• Sokol, C stb style, this rides that minimal C wave but really does seem fantastic, metal/dx3d11/etc. new stuff

“creative” frameworks:

often used in new media art, installations, hardware devices, etc. Often in C/C++ to have direct access to hardware of embedded devices (i think otherwise you'd have to write a lot of interop code for Java). note: does not include more limited/constrained/specialized stuff such as Processing and Three.js

• LibGDX, Java, old, solid, much loved, sorta has a cult fan community like OpenFrameworks and MonoGame, but whereas OF is mostly used by a "creative" community, LibGDX seems to have attracted more game-making people, i don't know much about it but i'm guessing you can find libraries for anything for it and build a game engine on top of it, making it very hard to differentiate from MonoGame
• OpenFrameworks, C++, SFML, made for new media artists and thus beginner-friendly, far more diverse community, also has a New York base and community, used by Zack Gage to make iOS games back in the day including helping Vlambeer making Ridiculous Fishing; although i personally prefer garbage collected Java over messy C++, being that it is often used for "embedded" devices i/o (written in C) i think it (C++) makes sense for the seamless compilation with C
• Allegro, ?, ?
• Cinder, C++, ?
• PolyCode, Ivan’s stuff, abandoned?

Haxe “back-ends”, and Kha:

this needs it’s own section because this part of the Haxe world, unfortunately, is hella confusing and probably the main cause of deflecting people away from Haxe ;(

• NME, (see above), possibly the initial base of both OpenFL and Heaps! :o
• OpenFl, (see above), forked from NME
  • Lime, the back-end for OpenFL, uses SDL for native targets?, not renderer independent(??), maybe just the graphics component of OpenFL? (no input? not windowing?)
• snow, abandoned, was the back-end for the original luxe engine, probably a simple & clean layer over SDL as the maker of luxe is very neat
• Kha, high and low level apis, good performance but for some reason criminally unpopular, i personally am guessing it's because it's too "low-level" for most people, either that or the api is messy, also with 3 other Haxe frameworks to compete with there's just too few people, however it serves as the base of the Armory game engine

graphics back-ends

these provide abstractions to access various graphics apis (i have no clue what’s going on at the level)

• SDL, C, OpenGL, a standard for OpenGL renderer along with extra libs for windowing, audio, etc.
• GLFW, C?, OpenGL, a standard for OpenGL renderer along with windowing
• BGFX, C?, modular? (OpenGL, Vulkan, DirectX, etc.)
• Veldrid, C#, graphics-agnostic renderer, solely uses C#/.NET5, no dependencies?
• Diligent Engine, C++14
  • • “Diligent Engine Direct3D12, Vulkan and Metal, while supporting older platforms via Direct3D11, OpenGL and OpenGLES...uses HLSL as universal shading language on all platforms and rendering back-ends. Platform-specific shader representations (GLSL, DX bytecode or SPIRV) can be used with corresponding back-ends...”
• GLAD, this just generates bindings of various OpenGL or Vulkan for you, to several languages

renderers

i think each renderer has it's own api...

• OpenGL - cross-platform, standard
  • OpenGL ES, es stands for embedded systems, used in mobile devices
• Vulkan - the new standard?
• DirectX - windows only
• Metal - Mac only (or also iOS?)

an example of a bunch of independent libs used to make a simple game engine

from TidyEngine, a tiny engine made by college kid

• https://github.com/AntiSC2/TidyEngine

• CMake, used for building the project
• assimp, used for 3D mesh loading
• GLFW, used for handling windows and the input
• glad, used for OpenGL rendering. (glad is already included in this repository)
• glm, used for vectors and matrixes
• stb_image.h, used for bitmap loading
• OpenAL, used for audio
• libogg & libvorbis, used for loading sound samples
• LuaJIT, used for Lua scripting
• Freetype2, used for font loading and rendering

todo: Dome Engine also makes a good example of a minimal game engine

game engine “front-end”

this is the part you make!

top-down approach of learning: dive into the deep end, make some stuff, and then you just know

though you make this part yourself by simply adding what you need, it can help to look at other simple open-source engines to get an idea. I’d suggest looking at the following engines, ordered from simplest to most complex:

• FlashPunk/HaxePunk, 2d, simple flash-like api combined with a 2d engine: 2d scene graph, layers, entities, simple 2d collision, collision helper functions, math helper functions, camera, composition (minimal single-level inheritance, but no components)
• Nez, 2d, a 2d framework on top of MonoGame, provides you with everything you need: ecs, collision, optional physics system, etc.
• Monocle Engine, 2d, an indie alternative to Nez but with no guarantees or support or anything like that, a great FlashPunk user made this in MonoGame, there seems to be components for: graphics, collision, physics, etc.
• Luxe, 2d>3d, ecs, written really well, the original version was abandoned, but that doesn’t mean you can’t learn from it!
• Godot, 2d>3d, entity-component, with a game editor, although much smaller than Unity it’s already quite complex, so you can just imagine what Unity or Unreal is like...!
• Unity, 2d<3d, entity-component, with a game editor, although not open-source (? does that mean you can see the core code??), it’s worth trying the most complete free-to-use engine

So, start with a media framework in your favorite language, then build-up as you need from there.

bottom-up approach of learning; making from “scratch”

okay, well, not scratch scratch, but assembling a game engine is actually less crazy than i had first thought. Now with so many good, simple, open-source libraries, you can just throw a bunch together in your own favorite language and make an engine. This way, you aren’t burdened by a massive framework you didn’t write. Everything in it exists because you yourself wrote it, and you yourself can always change it. Hopefully you wrote it out of a specific need for it. It’s specific (to your needs) as opposed to general. Despite it being a possibility, i personally hope to never take this route.. Even if i did for some reason want to go down this low (level), i'd personally just use NME as a base, and go from there.

modular renderer

- **Pile**, inspired by Noel Berry’s Foster and Microsoft’s XNA framework, uses SDL for “system” stuff (i/o, window, etc.), contains a packager ‘n resource/asset loading and batching ‘n buffers like XNA, and built in a way to support multiple renderers like Foster (although, at the moment, only supports OpenGL)
  - https://github.com/EinScott/Pile

• Foster, by Noel Berry, is like SDL for C#, with the OpenGL renderer portion being optional / modular, and the goal being to maximize the use of C#/.NET as opposed to relying on SDL/C

the old SDL path

• SDL
  • although the main file is like 6000+ lines, it’s much simpler than it seems; just glance at the api docs, and you’ll be like, “oh yeah, right on right on..”
• Zach Barth’s “minimalist game framework” is barely more than a SDL wrapper for C#, which gives off a rather powerful feeling of freedom
  • https://github.com/zachbarth/minimalist-game-framework
• Beef’s corelib module/folder, contains a wrapper for SDL, and the SDL functions are used directly in the sample “Space Game” provided, which makes for an interesting “low-level” api through high-level language way of making
  • Beef’s Beef2D module/folder is the natural next step

languages

(todo: separate to 'programming languages.txt')

personally, languages don’t bother me too much. As long as it can at least do ActionScript3 did, I’m alright. Just not... objective-c. 😨 Otherwise, some features or traits i much prefer: static typing, object-oriented functionalities, general-purpose (so that you can use it to make anything, beyond games!), references by default but ability to use pointers ‘n references ‘n other stuff to control memory (“un-managed code”), game-oriented garbage collection choices (a list of scripting languages and GC implementation), somehow can interact with C and maybe C++ (interop and compile), don’t be too slow! (see a list of game scripting languages with their benchmark scores. See Beef’s design foreward.

the C/C++ world is a stable one, as the most crucial low-level cross-platform libraries SDL (and SFML) are written in C or C++, but, the engines made in purely C/C++ are often more geared toward code-only non-editor skilled game programmers that want to assemble or build their own engine

the C# world is supported by the big boys (Unity, Godot through bindings) and indies alike (MonoGame) and of course Microsoft, and it’s quite easy to write “interop” code for C/C++, in case you do need to use a C++ library or just a few functions, making it rather ideal for indies, hobbyists, and game-designers; also, .NET is just a super powerful language with a fuck-ton of features...

the Haxe world is a really cool alt to Microsoft’s massive C#, involving a rad little community of loner hobbyist hackers ‘n makers. With a community, and unlike C#, you can feel like you make a differences, as many of the things made in this world are made by people like yourself: an artist. Like C#, it’s very easy to write bindings for C/C++ or even just rewrite libraries completely, yet, it’s libraries (via package manager haxelibs) are rather lacking, so you might just have to DIY. Thankfully, it’s a very game-oriented world, thanks to the mass migration of people from the Flash world to OpenFl, the open-source cross-platform version of Flash, which is written in Haxe. Though a small community, there’s certainly nothing wrong with the code. It works. It works quite well too. The language itself is maintained fantastically by the Haxe foundation; OpenFl is maintained by another group; And Heaps is maintained by the maker of Haxe, who himself runs a game company, using his own engine, Heaps, with Haxe. The language magically transpiles into anything, has its own super optimized VM, and so on, much before Google’s Dart, and somehow far more performant than both Dart and C#. Whereas C# becomes a massive monster supporting everything, along the same path as Unity, Haxe is generally minimal, modular, dependency-free, written squeaky clean. Everything is written this way because we are humans, and we can only handle so much, therefore, the code must be simple enough for a hobbyist to understand. Having said that, the Haxe world is great for game programmers, but can be intimidating for people that rely on big game engines complete with an editor and all tools and libs that come together—with the exception of HaxeFlixel.

I don’t know much about the Java world. LibGDX seems to be exceptional though, loved by many. Where SDL may be meh, LibGDX may be a more creative alternative. Similar to Haxe it uses a VM, JVM, to transform the high-level code into hardware-level byte-code, thus making it cross-platform.

I also don’t have experience with Lua, but i at-least know it can embed into C (via “C api”). It’s also a tiny, extremely minimalistic language that performs extremely fast (through VM?), perhaps only Wren can compete, with Haxe perhaps not too far behind though. “It's widely considered to be one of the fastest dynamic language implementations.” says the LuaJIT.org site. It’s like the most general—no, meta— language that’s i know of. Like, “tables” are the main data structure, and with tables you can do anything, including making most of the language features found in more complex languages, such as classes and inheritance! This shit is crazy! (i wonder if this makes it difficult for auto-complete to work though...) It’s also dynamically typed, which probably makes debugging a pain?

Newer things like Wren (like a modern Lua), Crystal, Nim, or even game-specific Beef, Jai, are all in their infancy. But, given how modular common libraries have become, there’s no reason to be scared, as long as they are using SDL or something similar at it’s core, then it’s just as stable as any other engine! You just have to trust their makers. For example, I have high faith in in Ruby0x1 and Bob for their development of Wren, and Jon Blow for his development of Jai (i don’t know who made Beef...). I trust these individuals over most open-source project.

game-specific

these are worth looking at for long-term game-makers, as it’s quite an investment in time. Game-specific languages probably have these features: a memory management system that’s good for game-making, ways to express game-specific things, and debugging features for game-specific problems.

• jai, Jonathan Blow’s baby, built alongside it’s IDE and even alongside his next game, the IDE itself might be written in Jai(?), closed-source (while in dev at least..)
• beef, built with it’s IDE to provide debug features (at the cost of being less supportive of other pop IDEs?), the maker of it has habit of using horrible code conventions: mVariable for member variables and gVariable for global variables 🤮, open-source

general:

try to focus on languages that can communicate to C

https://github.com/learn-anything/programming-languages#multi-paradigm

newer small general languages:

in general, most of these languages are just a combination of the maker’s favorite languages mixed together. None are really innovative. Only only a few will catch on, become popular, have libraries, and live on... but that doesn’t mean they shouldn’t be used. Use whatever makes you happy! :) Anyway, it can be really cool making your own little world in your favorite language... As long as it works with C/C++, the worst case is you have to write some “interop” or otherwise “wrapper” code.

• nim, “statically-typed python syntax with perl expressiveness, aims for efficiency, then expressiveness, then elegance, has metaprogramming too, in that order;” sounds nice to me!
• crystal, for ruby lovers that want to be able to embed into C
• wren, “Think Smalltalk in a Lua-sized package with a dash of Erlang and wrapped up in a familiar, modern syntax.”, looks like a really cute alternative to Lua, in case Lua is too meta-level / minimal for you and you feel safer hiding behind classes ‘n object-oriented paradigms; used ‘n heavily contributed by the maker of the Luxe engine and made by the guy who wrote the game programming patterns book / site
  • dome engine, a very cool simple game engine! :)
    • https://github.com/domeengine/dome
    • domepunk, the punks never die! :p
      • https://github.com/NinjasCL/domepunk#project-explanation
• ring, seems like a pretty awesome flexible language: keywords can be changed, doesn’t enforce a coding style on you (doesn’t use neither tab nor braces!), something like Lua and Wren (20k loc interpreter ‘n VM), all containers are a “list”, already has bindings for RayLib, SDL, etc.
• odin, another cute scripting language for C, plus it parses emoticons!! 😮

newer pop or corporate-backed general languages

• rust, C++ without the problems of memory management(??) thanks to it’s “borrow-checker solution”; memory-safe, performant, and concurrent (for threading?); i personally have no clue if this is good for games or not... but what the programmer mass trend-seekers love often doesn’t align with what game devs need (examples: JavaScript and Python), so, can’t be sure..
• Dart, Google’s version of Haxe?, used in Flutter, one of the top cross-platform app frameworks
• ECMAscript?
• Kotlin, Google’s contemporary replacement for Java, used in Android devices
• Swift, Apple’s contemporary replacement for god-forsaken Objective-C, used in iOS devices (this is a massive improvement/upgrade, and of of the few places language actually matters to me)

resources:

wandering around github

people that make games

people in various game-making-related discord servers

games from scratch (youtube series and web-site)

itch.io game engines used list sorted by popularity

• a current list of game engines used by itch.io game jammers sorted by most used / popular. This is also a very good place to see source code of various simple games, before they become too large or too abstracted (often unnecessary refactoring of code); this is probably the quickest way to understand how a game is made. But beware, game jammers aren’t the best programmers, and so they’re going to focus on tools specifically made for jamming, such as genre-specific tools which require no programming at all!

https://thomasgervraud.com/best-2d-game-engine/

• a good starting point on making a list

https://gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74

• a pretty incredible list of custom engines started by the maker of RayLib

https://www.slant.co/topics/341/~best-2d-game-engines https://www.slant.co/topics/1495/~best-3d-game-engines

• pretty generic no life site, but it’s a list! and the pros and cons work!

https://notes.underscorediscovery.com/

• the blog of the maker of Luxe engine

https://srodrigo.me/choosing-my-game-development-tech/

• choosing between Unity, Godot, MonoGame

https://blog.kylekukshtel.com/csharp-game-engine-dotnet-5-kinc-monogame-xna-dinghy/

• talks about making an engine on top of Kinc, slightly different from Foster
• https://dinghy.xyz/posts/experts-and-beginners/
  • talks about the design of a simple framework, something very particular, yet, really pinpoints the differences between frameworks people love and people don’t

https://www.bayustudio.com/en/finding-the-perfect-2d-game-engine/

• more on the big 2d engines (godot, defold, cocos, corona/solar2d) https://www.bayustudio.com/en/godot-vs-defold-which-one-is-better-for-me/
• godot vs defold (very close ‘n comparable!)

https://love2d.org/forums/viewtopic.php?t=92556&p=246175

awesome cpp

• https://github.com/fffaraz/awesome-cpp#frameworks
• https://github.com/fffaraz/awesome-cpp#game-engine
• this is a pretty good place to keep track of “modern” C/C++ game engines, which is all the craze now
• otherwise, it’s just through searching github..

https://www.reddit.com/r/haxe/comments/4ojgtc/haxe_vs_c_syntax/

• the GPU is the fastest way to render objects, so an "objects per second" test is really more of a test of the GPU installed in the test machine. For the record, both C++ code and C# code run on the CPU, and they have the same options available for passing instructions to the GPU. This reduces the advantage of C++ code.

  But that isn't the whole story either. It's possible to use the GPU efficiently or inefficiently. A good library might be able to render many more objects than a bad one, so it depends how well-optimized Kha, OpenFL, and Monogame are.

http://forum.giderosmobile.com/discussion/7977/what-are-the-core-benefits-you-feel-gideros-delivers-better-than-other-development-systems

• just checking the forums...

https://groups.google.com/g/haxelang/c/JCQCGbLy0xc?pli=1

• to figure out wtf NME is

https://gamedev.net/forums/topic/673603-unity-or-monogame/

• the second post is a really good summary of what MonoGame is

https://community.monogame.net/t/future-of-monogame/12660

• from a MonoGame developer: "The idea of the 4.0 and 5.0 releases for MonoGame is that 4.0 release will be the last XNA compatible release, and with 5.0 release we will break a lot of APIs, as well as the namespace change (basically making MonoGame a spiritual XNA 5)."

https://steamcommunity.com/app/413150/discussions/0/365163686043643821/ 2. When XNA died there haven't been any stable and definitive alternatives. MonoGame and some other variations have just been born and were quite untested and not ready for production yet. If you browse around gamedev forums (for example https://www.reddit.com/r/gamedev ) and search for MonoGame you will also notice that MonoGame to a certain degress still has a bad reputation and there is a lot of discussion regarding its implementation and dev team. It used to be buggy and slow as hell for a long time (which caused frameworks like FNA and Ultraviolet to spawn... search for them on github if you want to have look).

Another thing that XNA still offers that MonoGame etc. were not offering for a long time: it tightly integrates in Visual Studio 2010 and makes developing games very easy. Need sound effects, some textures or shaders? Simply put them into your content project and leave the rest to XNA. XNA makes sure everything runs and you can concentrate on coding. MonoGame only recently got their own content pipeline into a stable state.

Long story short: MonoGame is a very good option for games now, but back in 2013 it was not in a usable state.

Note: MonoGame aims to be 100% compatible to XNA. Every tutorial, resource and book about XNA is still valid and works fine with MonoGame. The only difference is how to set up your project and the content pipeline. x

concerned ape 1

https://www.reddit.com/r/StardewValley/comments/4b8s7v/im_concernedape_developer_of_stardew_valley_ask/?sort=qa

I'd probably look into something like monogame next time. Maybe even GameMaker depending on what the game is.

Next time around I'm not going to try to "re-invent the wheel" like I did with Stardew, where I wrote almsot everything on my own from scratch. Yeah, it's cool for bragging rights, but is it worth months and months of extra time wasted and aggravation? No.

I'm going to constrain myself even more. Like... with Stardew I didn't stick to a color palette or anything. It was all very sloppy. For my next game I'm going to be a lot more deliberate with how I do things and stick within certain boundaries that I set for myself. x

It's all made using a piece of software called Propellerhead Reason. All the banjo and flute sounds are contained in the stock soundbanks. I think they actually record those instruments at all the different pitches, so you're actually hearing a real pan flute, not a synthesizer. Though there are some synths in the soundtrack as well.

Basically, this software gives you a bunch of instruments and effects, and you make songs by laying down one note at a time.

And thanks : ) x

I regret a lot of stuff about the development, but that's part of the learning process. One of the big ones is going with XNA (totally outdated now). I'm going to try and apply everything I learned to my next game! ... Start small, work on something you are passionate about, convince yourself that you are unstoppable, never stop learning and improving, and never ever give up! x

I always try to think about "How can I take this to the next level"... usually I hold back because that can lead to an endless amount of work. But I do enjoy adding those little touches, it's what makes a game special. I enjoy games that make me feel like a kid. x

on a normal day, though... I get up, eat breakfast, then get to work. I normally check my business emails first to see if there's anything pressing going on, then I'll go on social media/reddit for a while and answer people's questions, help them with problems, etc. Then I will work on the game for a while... By now it's probably dinner time. Then after dinner I usually get back to work until maybe 11:00pm, then I might watch an episode of star trek DS9 and go to sleep. repeat. x

Do you have a favorite Harvest Moon game? If so, which one? Back to Nature! x

I applied a few places, no one hired me. I felt both scared and depressed about going into the "workforce" anyway. I still felt like a kid, I wasn't ready to grow up. Most of the people in my social circle are "bohemian" types anyway, so I didn't feel a lot of social pressure to start a career, house and everything. So I guess I felt like I could get away with being a "struggling artist". My girlfriend was willing to support us until the game was done. The most risky thing was probably foregoing the experience and resume-building that most of my peers were getting in the industry, in case my game flopped and I had to get a normal job. I'd have to apply for an entry level job and I'd be much older than anyone else. So it would probably be even harder to get a job at that point. It may have been a foolish decision, but I am very fortunate that it worked out. x

Mostly just non-dev stuff:

Working all day but making no money The way people treat you if you don't have a "real job" (i.e. make no money) Feeling depressed and anxious that I had a CS degree but yet I was a part-time theater usher & had thrown all my eggs in one uncertain basket. Feeling pressure to release a monthly development update, with new and exciting information (maintaining hype) Actually developing the game itself is fun! Well, mostly... x

You have to be prepared to put your own enjoyment and entertainment on the back burner. You'll have to become a work maniac. My advice, if you are very serious about becoming a game developer... work a job just as much as you need to to survive. Be frugal. Spend the rest of your time either sleeping or working on your game dev career. Only allow entertainment and relaxation as is necessary to stay sane and productive. You need to be very disciplined. It helps if your friends/family have confidence in you and believe that you're going to be a success and support your efforts for that reason... x

concerned ape 2

https://vgkami.com/interview-a-peek-into-concernedapes-haunted-chocolatier/ EB: Both Stardew Valley and Haunted Chocolatier are written in C#. But for Stardew Valley, I used the XNA Framework, which is basically a set of tools to help make games (not an engine). For Haunted Chocolatier, I switched from XNA to Monogame. The reason is that Monogame is cross-platform, open-source, and has active developers and community. XNA is very old at this point and has been abandoned for a long time.

others:

EB: My favorite part of game development is after all the core elements are finished, and I get to just add fun things on top of it. The little surprises for players to discover. But that’s kind of the “spice” you sprinkle on at the very end. I’m not really there yet, still working on the core elements. But I’m looking forward to it and thinking of ideas all the time. x

EB: No, not really. Haunted Chocolatier started with me just messing around coding up an extremely simple “game” that was just one room and you could run around and swing a sword and fight some monsters. I just did that for fun, for some reason, I’m not sure. It all kind of evolved from there and I had these different ideas that came to me. x

EB: I don’t know, and I’d rather not worry about it. I just want to make a game that I’m happy with. x

https://github.com/ConcernedApe

• just MonoGame and MonoGame.Extended