131–140 of 257 posts
Earlier quoted context omitted.
Not OP, but this is Noel Berry, one of the creators of Celeste, a very successful and incredible indie game.
Didn't know that ... silly me. In any case, I think the question still relevant - is the secret just "if you build it, they will come?" I suspect it isn't since the competition is fierce, there has to be something beyond making a good game
> I genuinely believe making games without a big "do everything" engine can be easier, more fun, and often less overhead. I am not making a "do everything" game and I do not need 90% of the features these engines provide. At that point, of course, you don't need the engine. Having said that, every time I've really deep-dived into some particular feature of an engine - such as inverse kinematics and animation blending…
> inverse kinematics and animation blending Either this is a central feature of your game, and writing it is worth it. Or it’s a technical boondoggle, and you don’t need it.
After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textu…
Then we added "State machines as Lua exported from Excel". Rows are states, columns are events, cells are code to execute given a state+event combo. I've done this a few times. It makes huge state machines manageable.
Our games were very stats-heavy and our designers liked Excel. So, a new thing we added as "Dynamic data sources as grids of Lua exported from Excel". So, fill out Excel sheets like normal. But, instead of Excel script, every cell is evaluable Lua code. Strings, numbers, bools, functions are all values in Lua. So, a cell might contain a number. Or, it might contain a function checking the contents of two other cells and optionally triggering an event on some other object.
We shipped multiple games on a single executable using this system. Artists could lay out 3D scenes and 2D UIs with hooks for the Lua to control it. And, the designers could populate scenes and UIs from Excel dynamically according to the state of the game. The programmers mostly worked on game-agnostic features in C++, and the heavier side of scripting in Lua for game-specific features.
Aside: Lua is being so dynamically typed makes it not great for large-scale software engineering. But, https://teal-language.org/ might be a good TypeScript-For-Lua. I haven't tried it. Also, are there any Lua debuggers newer than the ancient https://github.com/unknownworlds/decoda that require zero integration? Decoda just need a pdb of your executable and it can automatically debug any scripts passing through the Lua library.
Eventually, we switched to Unity for corporate reasons. As a primary implementer of our custom engine, I think the switch was overall a good thing. Our games had started to outgrow what our little engine team could deliver. The artists reported they felt slightly less productive working in Unity's editor. I switched roles to finding and working around the undocumented bugs in Unity that we ran into. Then later finding which bugs had been fixed without being mentioned in the release notes so I could delete my work-arounds. It was a very boring couple of years until the company burned to the ground because of the same corporate reasons that lead us to switch to Unity :P
> I genuinely believe making games without a big "do everything" engine can be easier, more fun, and often less overhead. I am not making a "do everything" game and I do not need 90% of the features these engines provide. At that point, of course, you don't need the engine. Having said that, every time I've really deep-dived into some particular feature of an engine - such as inverse kinematics and animation blending…
> inverse kinematics and animation blending Either this is a central feature of your game, and writing it is worth it. Or it’s a technical boondoggle, and you don’t need it.
After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textu…
> The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: I wonder if there'd be any value in someone making a FOSS engine-agnostic editor designed to be as easy and powerful to adapt to any other engine/framework/etc as possible.
For example for 2d games it is possible to use Tiled as a level editor if you build your game (or some tool) to parse out tiled's file format and turn it into in-game levels.
A more general purpose editor in line with Unity or Godot's that includes the ability to attach functionality to everything would be much harder since the specifics of that will be much more engine specific.
I agree with a lot of this, and am similarily working on my own code-only C# game framework meant as a spiritual successfor to XNA/Monogame (using Sokol instead of SDL): https://zinc.graphics/ In OP's post as well he brings up some of the main factors that make modern C# incredible: - Cross platform development (and runtime). - NativeAOT Compiling (great for consoles, provided you have backend headers). - Native Hot-…
I am familiar with low-level game engine stuff in C/C++, but always discarded C# as not being viable for cross-platform projects (as in game consoles). Guess I was wrong. :)
For anything I have ever tried to make, I always find myself fighting the engine. Whether it is Godot, Unity or Unreal. They all feel like a ready made game that you add assets and mod. The problem for me is that I mostly don't want to make that game. An analogy that comes to mind from the web dev world, it feels like the engines are like wordpress. Prebaked and ready to show content, but the moment your objective do…
And if you open Steam games and go to the newest, you see that nearly half of the releases is some version of a generic Unity/Unreal template game in a slightly altered "skin":
https://store.steampowered.com/app/2488370/Cash_Cleaner_Simu...
https://store.steampowered.com/app/2073910/A_Webbing_Journey...
https://store.steampowered.com/app/3498270/Better_Mart/
https://store.steampowered.com/app/2625420/Drive_Beyond_Hori...
https://store.steampowered.com/app/3163790/Toy_Shop_Simulato...
https://store.steampowered.com/app/3023600/Horse_Farm_Simula...
https://store.steampowered.com/app/3124550/Liquor_Store_Simu...
After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textu…
> The real meat & potatoes is all the tooling and content and asset pipelines around the engine.
When people talk about engines they often include the asset pipelines and editors by default. Engines today are not just a main loop + 3D API calls. Very few devs will say we're going to use Unity but only for its rendering code.
(Of course I'm not implying as long as you use Unity/Unreal you'll never need to write your own asset tools.)
there is a minor mistake in this.." their minds jump to what it looked like circa 2003 - a closed source, interpreted, verbose...", C# was never interpreted. From the beginning, C# code has always been compiled to Intermediate Language (IL), which is then JIT-compiled by the .NET CLR at runtime.
After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textu…
Already the biggest market is small games on tablets/phones
Now making those games is becoming exponentially faster and easier
Roblox, allowing people to quickly create their own games, was already a huge hit. Now that experience is getting supercharged with AI