That would indeed be pointless because I was originally replying to a single UI interaction, where it doesn't really make a huge impact whether it happened in 2 or 5 frames.
You're trying to bring in continuous changing of frames here which is obviously perceived differently.
This is an impressive project and hopefully it will allow more programming beginners to get into multiplayer programming. Huge congrats. However, I am wondering: if your programming language is aimed at complete beginners, why make your language untyped and include undefined? Those are both fully loaded foot cannons. Sure, the language looks more inviting and probably gives the impression of faster development, but I'm not sure it's worth the amount of bugs that will be introduced eventually.
Yes, in the end I just made this decision pragmatically and it's not a grand statement about how I think programming languages should work. I felt that it would be possible to add gradual typing to Easel eventually, and so chose to prioritise other programming language features.
One of the original "agitators" which caused me to make Easel was because I was so surprised at how popular the modding tools for my previous game were with first-time coders. The modding tools used JSON, which might sound primitive, but if you look past the JSON it was actually defining a hierarchical declarative language for defining game behaviour. I have many theories for why first-time coders could just pick it up, but one of them is I think the hierarchical shape meant everything could be written inline, without indirection or jumping around. This format allowed all these gamers to just accidentally fall into coding and it was quite impressive how far they got without any help.
But those old modding tools were quite limited really, and that limited how much coding people could learn. So for years I just kept wondering what would happen if someone made that magic hierarchical declarative shape unlimited by merging it with a traditional imperative programming language. Would it allow gamers to accidentally fall into learning actual coding? It took me about 2 years to squash together these two seemingly-opposed paradigms and make the Easel programming language. Doing this required slimming down on the other language features in order to iterate quickly on this big problem, so that's how we ended up not having strong typing, amongst other things. But I don't regret what I chose to prioritise, and I hope to address this in the coming years!
"(a) scripting, pacing, combat, economy: have an NPC brief the player on how to find the level exit, then place a ranged enemy turret, valuable item, and side-quest destination near the level exit"
Seems like this option should really be 2 different options. An NPC briefing the players about the exit is lazy and signals to the player that they are regarded as stupid. The rest is great.
Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor of rolling your own, from a time-spent perspective.
The more unique and niche your game is, the more true this is. Stumbling around Unreal's horrid UI for 3 months just to realize that the thing you want to do is barely even possible due to how general and off-the-shelf the engine is, is not a good experience. On the other hand, if you want to make a hyper-realistic, open-world RPG, then rolling your own is probably not a good idea.
I also believe that even if it's not always the most efficient thing to do, placing limitations on yourself by using a custom-made specialized engine makes the creativity really flow, and your game, even if not the most advanced, will be a lot more unique as a result of that.
>Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor of rolling your own, from a time-spent perspective
I once experimented with creating my own game engine. It took me about a year of building and learning along the way (through trial and error, with many dead ends initially). It featured lots of things you'd typically find in a game (3D rendering with all the bells and whistles, an adaptive UI framework inspired by flexbox, skeletal animation, a save file format, a smart object system, path finding, a scripting language, audio, physics, et cetera, et cetera)
Specifically, I tried to recreate Braid's system (without knowing it existed), where you can rewind your game to any point in time. It required support from all the engine's subsystems - to rewind scripts, physics, etc.
Knowing every little detail about your game engine was certainly a plus. After the engine was more-less complete, adding a feature, however ambitious it was, took about a couple of hours at most. When something didn't work, I knew exactly what was going on.
However, after a year of building, I was somewhat exhausted, and all my motivation to continue disappeared :)
> Specifically, I tried to recreate Braid's system (without knowing it existed), where you can rewind your game to any point in time. It required support from all the engine's subsystems - to rewind scripts, physics, etc.
Not necessarily.
You can write your own "snapshotable allocator" that allows you to rewind back in time anything, even the state of unmodified 3rd party libraries and interpreters (as long as you can configure them to use your allocator).
Feels like fiddling with snapshotting raw C++ memory is a can of worms (you listed some of the pitfalls yourself). Most of my snapshotting happened at the scripting runtime level, where everything is well-defined and well-understood: I manually snapshotted the VM's heap memory, the green threads' stack memory, the current instruction pointer of every green thread etc. I could safely validate those snapshots without segfaulting on a corrupted savefile, because it was a well-defined file format. The same code worked both as a time-travel snapshotter and as a general savefile format.
I think this is dangerous and can lead to remote execution attacks:
>The snapshot could even be exchanged over the network, assuming the receiving side has the same endianness, the same pointer size, is running the same binary, and can mmap the same memory location.
For physics, I needed to restore all those remembered motion vectors; for audio - current playback time, etc. Same as yours:
>The rest of the memory (the textures, the 3D models, the audio, the UI, etc...) should be allocated by your usual non-snapshotting allocator"
> It featured lots of things you'd typically find in a game (3D rendering with all the bells and whistles, an adaptive UI framework inspired by flexbox, skeletal animation, a save file format, a smart object system, path finding, a scripting language, audio, physics, et cetera, et cetera)
I am not familiar with Unreal, but Unity is much faster than programming from scratch, easily 10x or more.
One obvious example is physics behavior, which you can add to your game in under a minute, but with your own engine you'd need a day or two to properly integrate an external library. All the internal state visualization that Noel's showing off here is already built in by default in Unity. It has nice tools to draw and modify bounding boxes, and in the rare cases where the engine's behavior isn't enough, it's highly extensible (using ImGui or Unity's Yoga-based CSS engine, which I prefer). Unity has countless features like this: a sophisticated particle editor, a high-level "write once, run anywhere" shader language with enormous amounts of complexity abstracted away, systems for streaming and keeping track of modular data, and much, much more.
In an ideal world, I'd want to write these things myself, but time ticks away and unfortunately I'd prefer to prioritize finishing games more quickly.
At this point using any engine instead of unity is better. Unity has demonstrated time and again that they cannot be trusted and that you cannot build a game (or business) around them.
Sometimes you have to do business with counterparties you don't trust. It's not mature or practical to take an "all-or-nothing" approach while the engine has virtually no competition for many classes of games.
I mean I’ve been using Unity since 2008. I do trust them to be around more than most other tooling/saas companies? Even if they have mode some unsound business decisions
Do you have any developer retrospectives around this? Plenty of my favorite games ever made were made with Unity, I wouldn't call those games failures by any means (Cities: Skylines, Overcooked are immediate examples)
The tech is fine, it's more that the last few years has shown some instability over retroactive license changes, questionable acquisitions, and general sentiments over years of seemingly abandoned support in key subsystems.
At least as far as platformers go, physics feel is a crucial part of the whole experience, and outsourcing to an engine has a good chance of making your game feel cookie-cutter.
> I am not familiar with Unreal, but Unity is much faster than programming from scratch, easily 10x or more.
With the caveat that the editor for Unreal is massive and getting it running requires more resources than Unity, Unreal's Blueprint is a great way of writing gameplay logic. It's accessible to people who don't know C++ or C#, and is a really nice abstraction for async/event driven code. It's a really good place to start with IMO.
>On the other hand, if you want to make a hyper-realistic, open-world RPG, then rolling your own is probably not a good idea.
I would say its the exact opposite to that. For that genre, its best to roll your own engine, or pick something open-source. The list of problems that i firsthand experienced:
There are lots of features and options in the engines, but they are not all usable at the same time. One feature disables the other. You look at the list of all the nice things the engine can do, but then at some point you figure it can't do (or can't efficiently do) what you absolutely need. All those awesome looking graphics are not practically usable, simply not performant or not compatible to be usable.
There are features that only work in "baked" mode. You "bake" it in the engine editor, and there is no way of changing that at game run time. Unreal is the most limited in this, but Unity is not much better. Some game developers reverse-engineer Unity internal asset formats with a hex-editor, so that they can change feature behavior at runtime. At that point, rolling your own engine makes more sense. One example i saw was a developer reverse engineering the light probe group asset file, so that he could add a new light probe group at runtime.
Engine API's change drastically from version to version. All the code and scripts need refactoring, all the time. You run into a breaking bug, and the only solution is upgrading, but upgrading means breaking your whole codebase.
You need to go trough the engine's abstractions, and bad luck if that can't be done efficiently. An example of this: Unity HDRP applies screen-space ambient occlusion (among other effects). It applies the effect over the whole screen. If there is a third-person view of the character from close or first-person hands/weapons rendered, then even over that. That results in a white halo around the first-person hands/weapon, looks bad. In a custom engine, the solution is simple, apply the full-screen effect before the first-person hands are rendered, then render the hands without the effect. Its a matter of switching the order of a couple of lines of code.
The solution is github and the BSD/MIT/Apache licensed game engines and libraries.
I think you'd probably want a different render layer with different post effect settings so your weapons can have post-processing as well. I think you can do this in the editor with gui configs instead of changing code.
I'm pretty sure all of SRP is in C# and is "open source" as in source available and editable.
The problem with GUI settings is that the result is not apparent, and there might be side effects. I do not find spending half day on trying out setting combinations as productive work.
I have looked into SRP and i do still consider that as an option, and also replacing the shaders. But i have doubts regarding the SRP, for example i have looked at the code that sorts lights in Forward+. The individual light calculations are not much, but its still done trough the job system. I imagine if there are hundreds of lights, then that would make sense, but for 2-5 lights, it seems like a waste. So it might be optimised to scale, but not for my case.
Is the effort of replacing the SRP worth it, and is the performance comparable to putting together/reusing an engine in C++? It is also a bigger commitment, as it needs to be coded on a different level and in a way very specific to the engine. Better than having to reverse asset file formats, but still very specific to the engine.
> Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction?
You've asked two different questions - how long does it take to properly learn Unreal or Unity, and how long does it take so you can have an idea and turn it into a game without friction? If you gave me a half baked idea we could be playing it in a few hours with both tools. Unity requires programming up front, but Unreal you can get well into "I can almost ship a game" (particularly if it's a single player game) with just blueprint.
Here [0] is a 10 minute video where someone prototypes a super hexagon style game in 10 minutes. Obviously, this isn't feasible without knowing exactly what you're building, but I think this shows just how powerful these tools are for building out these game ideas. There's very little unity specific stuff in there, other than components. Everything else is stuff that I would classify as "gamedev agnostic" - input handling, update vs fixedUpdate, vector math, sprites, etc. The prefab for the spawner is about the only unity-specific thing in that video and it takes up about 15 seconds of the 10 minute video. I'm a game developer (Unreal) and I'd wager I could put together a similar prototype in about an hour in Unity, give or take
Obviously understanding what `GameObject.Instantiate(myPrefab, Vector3.zero)` takes several orders of magnitude less than implementing all that is required to properly perform that, even for such a basic operation.
Imagine when it comes to 2D/3D physics, shaders, platform support, etc.
If your goal is to build an engine, build an engine. If your goal is to actually deliver a game, build a game.
Games like Antichamber do non-euclidean space and rendering in Unreal (3). Enera (an upcoming action game) manages time rewinding (a la braid), in Unreal. Superhot is Unity, etc.
The best tool is the one you know, even if your vision is weird or niche. At the end of the day, you can always ignore all the bits and pieces unity gives to you and just write custom logic in your MonoBehaviour scripts and use it as a platform toolkit, input handler, content pipeline, scriptable editor, and renderer. There's a lot to be said for the features you get from that especially in the long term as you said.
I think my point was more that if your vision diverges heavily from the "normal" flow of those engines, sometimes it's just less friction to build your own
I think there’s a misconception due to the large overlap between games, graphics, and physics engines.
Graphics are anything from rendering 2d, 3d, shaders, scene graph, animation.
Physics and related interact with the scene graph.
The game part allows for dynamic behavior and of course the game logic/triggers.
Add some ui, and resource management, abs lastly of course ai.
Creating your own engine with different architectures is indeed the best way to learn how/why an engine works. But alll the details that come with it. That’s really a lot and probably way too much for one person. You’d be surprised how much is in there (in unreal engine)
There's a lot of nice things you get for free in a big engine that are a hassle doing it yourself. Esp with the unity store etc.
I love LibGDX for personal projects but for serious development where deadlines matter having stuff like dialog trees, UI, etc. that just work out of the box and have the edge cases polished is Very Nice.
And ofc, cross platform with consoles is way harder rolling your own and that's often a big deal.
That sorta thing is why Slay the Spire switched to Unity/Godot for the sequel
From a starting point of having dabbled in making 2D games in the past it took me a few days of working through tutorials and documentation for producing assets to be the bottleneck in building a game in Unreal. In Godot I was at the point of being able to make terrible games within a few hours. The amount of lifting that modern game engines do for you is phenomenal, and I think anyone claiming they can write an engine from scratch quicker than they can implement a game with an existing engine is deluding themselves.
I can have an engine ready for you that allows you to render arbitrary 2D sprites, levels of them, etc. or whatever in a day. People gamejam more interesting and advanced stuff than you're talking about. The mechanics of just shoving together some 2D sprites is not some big undertaking even if you write your engine from scratch, it's making something actually fun and interesting from it that takes time and effort.
> The amount of lifting that modern game engines do for you is phenomenal, and I think anyone claiming they can write an engine from scratch quicker than they can implement a game with an existing engine is deluding themselves.
If the game fits a rather "standardized" template, this is likely true. But the more you move away from these "mainstream structures", the less true the second part of your claim becomes.
I think reaching for the delusion card without considering people's preferences, experiences, expertise and philosophy is completely disingenuous and shows that you don't look at game development holistically. Yes, existing engines do a lot of lifting, especially in 3D rendering and physics. But what about games that don't have physics? Or have completely different physics than you would expect? You mentioned assets being the bottleneck, but what about games that don't use any assets at all? It's nice to have 3D solved, but what if your game attempts to emulate 4D? What if you just hate GUI and it slows you down?
For a more concrete argument. You also said learning Unreal using tutorials took a few days, which is certainly not possible, unless we are talking only about a very basic understanding. In the same vein, it also takes a few days to make a very basic engine built on top of OpenGL.
Here's the thing: you try to counter someone arguing against a patently false statement about development speed with a bunch of preferences and what-abouts that do not necessarily make your stance true anyway - for instance if my game attempts to emulate 4D, my own engine STILL needs to do everything else too, we're not talking dev time for 4D in, say, Godot vs 4D in foo engine, we're talking 4D in Godot vs 4D and graphics and input and audio and physics and... in foo engine.
C# is definitely popular for game development, but saying no other language comes close does not seem to be true. Looking at the most popular game engines and frameworks, it seems to be about as represented as anything else.
Game engines:
Unreal - C++, Unity - C#, Godot - GDScript (Python) + second-class C# support
We don't know for sure what AAA companies rolling their own engines use, but the industry standard would be written in C++, exposing C++ for programmers and Lua for non-programmers/modders.
