Anyone here creating a game engine? Whats it like?
 Nothing Ever Happens Shirt $21.68 |
 DMT Has Friends For Me Shirt $21.68 |
Nothing Ever Happens Shirt $21.68 |
Anyone here creating a game engine? Whats it like?
Anyone here creating a game engine? Whats it like?
Nothing Ever Happens Shirt $21.68 |
DMT Has Friends For Me Shirt $21.68 |
Nothing Ever Happens Shirt $21.68 |
I'm doing this "fun" project with my friend creating a game engine in java from scratch.
Right now I'm trying to implement a method to generate infinite maps using wave function collapse. It's pretty interesting as the method is a relatively new thing.
The negative is all the more basic functionalities that needs to be implemented and requires just time, with nothing new to learn, understand or create.
I'll send the github later if u want
not OP but i'm interested. WFC is cool
>using wave function collapse to generate stuff
>new
why not help godot?
What do you mean?
you could skip the more tedious tasks and just work on a fork of godot except of course if you want to make a game engine specifically in java
I didn't even think about that. That's a good idea.
Thanks anon
because godot sux, all the big 3 engines suck.
I made a data oriented engine except instead of ECS automatically making tables for you, you get to define all the schemata yourself with an excel-like spreadsheet editor. You can define and fill tables with static or runtime computed data, write data flows and insert them into the game loop or run them when events trigger or even while editing. It has rich hypermedia support, so cells are not limited to numbers and text and can support any of the media types in the engine such as colors, images, videos, sounds and music, shaders, and references to other tables and rows. Everything is saved in a custom format that is exactly how it is loaded in memory, so loading a game or data is just a single memory mapping (uses offsets instead of pointers so no fixup). It's got a pretty rich asset pipeline. An artist making a game with it uses procreate on iPad so I added support for that file format and support for automatically reading the saved files from the attached iPad to shorten iteration times. Been working on it for about 5 years and I have serious autism so I got a lot done
All good game engine have already been created, prove me wrong
I don't think anyone is creating a game engine because it's needed.
It's more for shit and giggles
If you want to make a game relying on deterministic lockstep networking (for example, an RTS, or any other genre where the game state is too big to transmit every tick so you just transmit user inputs and everyone simulates locally) then you have to make your own game engine if you don't want to live in desync hell.
Nah, you can still write your own sim code in engines like Unity or Unreal
Good luck getting it to work. It would literally be faster just to write your own engine, because you'll be fighting the premade engine every step of the way.
You can write your own simulation backend and it can interact with typical game objects in the engine
I don't think that's an uncommon approach
No it won't be. You underestimate how much stuff a game engine has to take care of.
If you don't use built-in physics engine and don't write moronic code, you can easily accomplish determinism in any mainstream engine. You can even get it working with physics if it isn't responsible for some gameplay critical parts and you synchronize it right.
Sweeney's already come out and said that DLN for Unreal would be a no-go and they will never implement it as a stock engine feature because all the engine components fundamentally make it an absolute nightmare to implement, if it's even possible.
what's DLN?
Deterministic Lockstep Networking
Where the simulation is identical on all machines and the simulation can only advance to the next tick when it has user input from all users in the match for the previous tick. Standard in RTS games; very common in other strategy genres.
You can implement a deterministic simulation system yourself and then plug it into the Unreal engine so it interfaces with regular Unreal objects
That's something you implement yourself. There is no reason for making it part of the engine if only small number of games will use it. You just have to not be moronic.
>just build the bulk of the engine yourself
At that point why even use a bloated premade engine?
It's not "the bulk of the engine"
If you're making a strategy game, it is.
A game engine does a ton of different shit like rendering physics audio UI and you'll still save a ton of time using an off than shelf engine than writing it yourself
>rendering physics audio UI
These things don't require the bloat of an entire proprietary engine that forces you to code everything in it's way. You can simply use libraries like SDL2 , nuklear or raylib to do everything you just mentioned.
None of those libraries do all those things for you, nodev
>calling functions is too much work for unity and unreal toddlers
sad.
a game engine you made yourself by stitching together middleware will be as bloated as Unity or Unreal
So don't use bloated middleware? Do you really think SDL2 alone with bloat an engine to the level of Unity or Unreal?
mixing together lots of middleware is bloated by definition
to do all the things a game engine does, you're going to need a fair amount
you can't do much with SDL2 by itself
SDL2 does pretty much all IO for a 2D game. The only thing it doesn't do is your data structures, algorithms and networking. Raylib has simple 3D rendering support if you need that.
Yeah if you're just making a simple 2D game, you don't need an engine
So you now agree you can create an engine with just SDL2 , nuklear, raylib, and maybe bullet, without being
>as bloated as Unity or Unreal
?
all engines that are made by stitching together middleware will be bloated, probably not as much as Unity though
if you're just making a 2D game you don't need a lot of middleware, you don't need Bullet
You don't need a full blown unreal level engine for 3D either, you just need a renderer and maybe a premade physics engine depending on how complicated your physics is.
You kind of do, 3D is complicated, if you try to run with some lean and simple 3D engine you're going to be missing a lot of functionality
At least you won't be missing any of the bloat.
Very Ganker thing to say
Who cares if your engine doesn't do what it needs to do, at least it isn't bloated
But you don't need to do all of those things, unless you are making a unity/unreal replacement which is not going to be a small project anyway.
there's a ton of shit you need just to make a regular looking 3D game
Not anything close to what you have in Unreal/Unity.
yes but that's not the argument
making your own 3D game engine isn't easy
Nobody is arguing it is easy.
I'm responding to this.
> a game engine you made yourself by stitching together middleware will be as bloated as Unity or Unreal
If you're choosing the features you want to support, it can be nowhere near as large as these engines unless it's supposed to be a full replacement.
there's lots of ways to define bloated
full of features you don't need, inefficient workflows, poor performance
middleware frankensteins will have inefficient workflows and poor performance
You're just asserting that, your engine performance is going to depend on how it is designed, what it is optimized for and how it used.
It wouldn't be hard to make an engine with much better performance than Unity if you limit it's scope by a lot.
no shit
this is a complicated topic
the initial argument was that if you had to write your own deterministic simulation for an RTS, you might aswell make your own engine, because that's the bulk of the work
That assertion isn't true unless your game is some simple 2D game, because engines do a ton of other work
That's going to depend on your game, if you were making something similar to the first total annihilation or maybe starcraft but with support for gigantic maps then probably networking and simulation will be by far the most difficult part and the graphics/audio code you can just shit out pretty quick.
That's what I said
If it's a simple 2D game, you can make your own engine
It doesn't have to be 2d, but yes if you want a modern game with all the features then it's going to be massive work to make an engine for that.
Simple = 2D
3D is complicated unless you want to make some really retro stuff
Eh, you have an extra component to keep track of but you're still just wrangling euclidean geometry at the end of the day.
But yes, I'm assuming anyone writing their engine is trying to do something retro (but maybe scaled up), either that or they're doing something extremely experimental that mainstream engines don't support.
>Eh, you have an extra component to keep track of but you're still just wrangling euclidean geometry at the end of the day.
No, that's not what it's like at all
3D introduces so much extra complexity on all fronts
But certainly not insurmountable, people were building 3d games with very small teams in the 90s, and you'd have it easier today because hardware is so much better etc.
that's why I said "unless you want to make retro stuff"
but retro 3D is extremely limiting and tends to look pretty ugly, unlike retro 2D
Sure, but I don't think any random anon is making a modern AAA game engine on their own. Early iphone gaming had a lot of home brewed 3d engines, because that was pretty much the only way to do it for example.
The alternative to "retro" isnt "AAA", there's a whole graduation inbetween that
For most 3D games you are going to want a shadow and lighting system and an animation blending system and a physics system and other stuff which neccessitates doing a bit more than duct tape and elbow grease approach of the Quake engine
Yeah, but you can scale those down. If you go for fixed point lighting and pick what physics you're going to implement then your problem is a lot smaller than what a large game engine has to deal with. A guy at my uni built a rag doll system for his undergrad, another guy made a destructible terrain model for example. but you might not even need those.
>you can scale those down
Unless you are making something that's retro, the minimum amount of work you need to do is still very complicated
Go implement a basic 3D physics system for a game and find out, unless it's Minecraft and you can get away with only AABBs it's going to involve a fair bit of math
I'm working on the assumption that you can already understand math, and newton worked most of it out for you already.
You aren't going to be using any cutting edge features of new GPUs in your game engine.
It's incredibly naive to think that writing a physics engine for a game is just transcribing the laws of physics
What else would it be? I have some bodies and they interact in some way, so I figure out the PDEs and solve them with a numerical integrator.
That question is so ignorant I'm going to tell you to look into it yourself if you actually care
Look into what?
What game physics engines need to do
Like what?
I can't respond if you're going to be this vague
I'm not asking you to respond
You are ignorant on this topic but you're talking like "oh yeah it's easy"
"easy" is relative. But there's nothing especially crazy about implementing some physics.
You don't even understand what is required to implement game physics
Like what? I don't really understand what you're driving at here. It's just writing code that models something.
What I'm driving at is that you don't know how video game physics are implemented yet you think you can speak with authority on the topic, and that you are a fool
I mean, I'm looking at this
https://github.com/Ricku34/ODE.js/tree/master/ode-0.7/ode/src
And I can't see anything in there that doesn't look like a textbook algorithm.
that's because you're just looking at collision algorithms
There's more than just collisions in there, but you might not even need much more than collisions in your engine anyway.
Characters in video games do not operate under the ordinary laws of physics and are not simulated by objects in rigid body physics engines
A simple, bare-bones physics engine would not include any rigid body physics at all, it would be just the shit characters and bullets need to move around
Introducing rigid bodies makes things much more complicated. Your character controllers do not operate under the ordinary laws of physics, so you have to implement unnatural "video game" physics in a way that interacts with your rigid body physics system that you use for tumbling objects and ragdolls
Rigid body physics engines are also imprecise, and they require a lot of tweaking and modification to give you a stable result that does what you want, and even then, things are still going to spaz out and fall through the floor sometimes
What a fricking moron, it's just textbook algorithms.... and 10,000+ fricking lines of code you gotta sit down for months to write that shit out and make sure it doesn't have bugs. Please frick off you stupid frick.
That's because it's an entire general physics engine, you probably don't need most of it. Or you could just use that library or a different one, and you're still going to be much smaller than unreal.
>You aren't going to be using any cutting edge features of new GPUs in your game engine.
You don't need to use any cutting edge features. OpenGL didn't even reach 2.0 during 90s. If you think modern hardware is easier to use than the one 30 years ago then it's clear you never used Vulkan or modern OpenGL/DirectX.
Also it's much harder to setup pipelines, render passes, shaders, batching, etc, than to enable some "cutting edge" feature after you are done with the former. The GPUs didn't just got added some extra fancy features, the way they work is fundamentally different and more complex than in early days of computer graphics. And it can be quite a challenge to get just a triangle to render without relying on an rendering engine or a driver emulating old hardware.
I'm pretty sure it's not beyond the wit of man to throw some meshes on the screen with a modern GPU.
You have no idea.
Not just people, they were the geniuses of their era which is why virtually all of them are still recognized today.
that's half selection bias half you not know what the frick you're talking about
>people were building 3d games with very small teams in the 90s, and you'd have it easier today because hardware is so much better etc.
Lmao it's quite the opposite. Modern hardware is so much more complex than in the 90s. If you know what you are doing, you can write doom-like engine easily in a week to month time. But making an engine that is going to properly utilize modern hardware and techniques is orders of magnitude more complex.
I don't have the manpower to create something 1/1000th as bloated as unity or unreal.
>t. zero experience working on games professionally
You have no idea just how much stuff an engine does, even for a small modern game. Even if it's made purposefully for a single game.
>You have no idea just how much stuff an engine does, even for a small modern game
I obviously do, as I've made many small modern games and have named all the things I use to replace game engines when I make them. A lot of the stuff that Unity and unreal simply do not need to be done which is what makes it doable.
>as I've made many small modern games and have named all the things I use to replace game engines when I make them
unconvincing lie
Making simple 2D game for fun is not the same thing as making proper game that is going to work well and fast under many different hardware and possibly platforms, that will gracefully handle various input devices, different capabilities of GPUs, different supported graphics APIs, offer GUI that doesn't suck, encode all assets into formats and atlases that will be fast to load, properly batch various GPU operations, handle sound systems and filters, animation state machines, particle systems, and most importantly provide you with an interface that allows you to efficiently prototype and experiment without too much boilerplate getting into the way.
Unless you are literally making something like Undertale, an engine has to provide tons of stuff. Every day you spent refining your own ECS implementation is a day you could have used to improve your game's gameplay or add more assets.
>Sweeney
Who?
>Who?
The Demon Barber of Fleet Street
Looks like disney antagonist.
well the cellular automata game engine, which im developing should blow the roof of you spergs, proof in 8 days on steam
Ooh awesome! How are you handling modiying the grid, on the CPU or GPU? I'd assume GPU since the amount of parallel processing power there is unhinged compared to a multithreaded CPU algo.
What's the name of the game you're going to release? I'll check it out
i'd like to do one in rust
I do it in rust.
Check out Vulkano, egui and rapier. I'd say they are ready to be used for something like that.
I've made an engine with those. I can approve that egui and rapier are rock solid. I haven't tried out vulkano but I've heard that it has realy bad overhead.
One of the arguments made is that since vulkan is supposed to be "low-level" it wouldn't make sense to have a mid-level abstraction that does all validation for you. You, the developer is supposed to tune vulkan's features for your specific use case (hence why it's so low level)
Not sure what overhead are you talking about. It pretty much directly translate to some Vulkan functions, with some extra utilities like allocators and stuff. Maybe several years ago when everything was using random Vecs everywhere that added pointless allocations, but nowadays everything uses SmallVecs and they are stack allocated.
>One of the arguments made is that since vulkan is supposed to be "low-level" it wouldn't make sense to have a mid-level abstraction that does all validation for you.
Vulkano is not Vulkan. If you want just Vulkan experience, you can get ash. Vulkano on the other hand is a safe abstraction. Conceptually it stays close to vulkan, but offers an interface that is safe to use and checks for valid usage in compile time or in runtime. It also only adds what you'd need anyway or what is essential to ensure safety. It doesn't try to be a framework that simplifies Vulkan at cost of performance or features or something.
It totally makes sense to have such layer so you don't have to implement it yourself. It's tons of work to write a safe abstraction over something as complex as Vulkan, with hundreds of "valid use" rules for every function. You will either come up with something crippled and limited in capabilities or simply with something unsound. You do not want to write it yourself if you care about safety.
>You, the developer is supposed to tune vulkan's features for your specific use case (hence why it's so low level)
Vulkano doesn't tune Vulkan for you, it aims to offer full range of Vulkan's capabilities, and it's not hard to extend it.
Right yea. I personally did try Vulkano and it felt like a pretty good API. Though most people nowdays just opt for something like wgpu than vulkano. There's also a new abstraction that I'm contributing to that also abstract vulkan for you although it's not really well known.
>One of the arguments made is that since vulkan is supposed to be "low-level" it wouldn't make sense to have a mid-level abstraction that does all validation for you. You, the developer is supposed to tune vulkan's features for your specific use case (hence why it's so low level)
moron take
setup() {
createGameElements()
}
loop() {
deltaTime = milliseconds since last loop iteration
updateGameElements(deltaTime)
render()
}
Wala your game engine. Just call loop() in a while(true) or something
> Your shaders?
> Your entity component system?
> Your multithreading pipeline for processing events in a performant manner?
ngmi
Not that anon. Aside from the multi threading comment there's nothing wrong with what he said. That was the traditional way of building game engines well into the 2010's.
I made one in C before. So here are a few tips:
* Use SDL2 as much as possible, it will save you a lot of time and hassle.
* Study idtech game engines, they're open source and really high quality imo.
* Create an opengl render pipeline. It's a steep learning curve but worth it if you want to impliment cool graphical effects.
* Make an object management system, you also want to integrate an existing physics engine (avoid Bullet it's buggy and imprecise).
* Make a UI system, remember controller support (Figure out the render pipeline before worrying about this).
* Make a world/level loading system (Figure out your object management system first).
* Make good debug/development tools to speed up development.
* Optimization is very important. Slow code builds up and can make the game laggy and unresponsive.
* Impliment proper time scaling into your mainloop.
Some things i forgot:
* keyboard and mouse bind system.
* Impliment an interpreted language to your world system.
* Study polymorphism to dynamically load your game as a dll.
* Create server/client netcode even if your game is singleplayer.
These things will come in use in more ways than you think. You're basically creating a small operating system to handle any game you could possibly want to make.
>load your game as a dll.
that doesn't sound like a good idea
Thats how idtech games and source engine games do it. "hl2.exe" is basically just a loader for server.dll and client.dll in the bin/ folder.
Those engines are ancient
Loading your game in as a dll just create an un-neccessary engine / game barrier
I disagree. The barrior has to exist somewhere. Much more simple to compile seperate server/client dlls that control the engine. The alternative is making a seperate branch for every game or implimenting the games entirely in your scripting/world which Id argue better used for sub gamemodes.
>The alternative is making a seperate branch for every game
Yes, that's what normal people do, a game engine isn't a microservice
Thats so fricking dumb and obviously not what "normal people do"
Most game engines code libraries, loading the game in as a DLL isn't common
Fair enough. I just think my way is better 🙂
The game engine should act as a kernel that makes developing games around it easy. It comes particularly in handy with the client/server structure.
It's not "your" way, it's the id engine way
When you include the game engine as part of your code, you get compile and link time optimization
When you include your game as a DLL you get to compile your engine and game seperately, which isn't particularly useful
A gamedev studio who uses their own engines often customize the engine for every game. Only largest, general purpose engines are generic enough to support wide range of games out of the box.
A DLL stands for "dynamic link library". It's literally just a file with the compiled binaries for a library. Basically any windows application will ship with a whole pile of .dll files or use ones already on the system. A .exe is basically just a dll with a defined entry point.
I know that
ok, so I don't understand what the problem with using them is?
Barbie colluded with Poopenhaimer
Sort of. the game uses raylib for IO stuff but I am writing all the data structures and algorithms the game logic needs. It's sort of ECS like except hard coded for my particular use case.
I'm creating one.
I never planned on making one, I just wanted a framework for prototyping and doing ""research"", but slowly I kept adding more typical features like component system, render target management, entity life cycles, gui, Unity-like inspector and now it's like a game engine, minus some fancies like sound, networking, fancy shadows etc.
It was very nice experience, but don't delude yourself that you will make any game with it(or that making game alongside an engine will be faster). It's only nice because I have no goal, I can just tinker around and use it for prototyping out new things. I do believe that if I picked Unity and made framework from there I would save tons of time and probably be much further with my research than I'm now. But I wouldn't learn as much and I might have to struggle with issues with that engine instead of annoying bugs in the libraries I use(not sure which is worse tbh).
Also you need to know what the frick are you doing. I have quite a lot of experience with Unity and Source engine so my engine is somewhat similar to both of these. But if you have no understanding of how game engines are designed and made, it might be really hard to come up with something good solely by yourself.
Nah I just use Bevy ECS
How comfy is bevy?
Is it advanced enough to compete with Love 2D or at least SDL2?
It's pretty nice tbh. I did give it a shot and it seems to have a rock solid foundation for now so I think it'd be wise to use that (not like you have a choice other than making your own game engine in Rust, it's literally the only one still in active development at this point in time).
One very minor ick I'll point out though, is that to create custom materials / shaders, it's a PITA. Due to it's secondary render world / render thread method, I think they had to cut some corners in ease of use somewhere. I think they've updated how they do custom materials so you can now just implement a simple derive macro on your struct, which is pretty sweet as well. I was going to use bevy at first but after looking at that I got repulsed by how overcomplicated it looked and made my own engine instead kek :p (not a bad engine though)
Yeah, I made my own too because I needed some very specific features. I will try bevy one day tho.
I once did a MATLAB script that rotates 3D-wise an image of Hitler, from the game Wolfenstein 3D. I guess it is more game engine than you guys have ever produced.
Using code from other people do not count, remember.
I created a 2D game engine in PHP and it was utter cancer.
Can you share it?
It's hell.
I created the original unreal engine. It was very rewarding.
It’s the sort of thing that’s cool for the first couple of weeks then the longer it goes on the more depressing it gets because there’s a shit load of stuff that can go wrong that you need to think about.
Why do some people get so upset when an anon makes their own game engine?
I tried making a fully custom game engine in Rust. Fully custom built archetypal ECS with column based bitmasks and filters, with a custom renderer built on top of wgpu. Custom built Audio through CPAL and my custom Asset Loader. It was really fun working on it, but compared to something like Unity or UE4 getting shit done within it is super slow. Especially with Rust compilation times (albeit this could be fixed by converting to a dll and loading dynamically, and a proper editor)
One of the main reasons I wanted to build said game engine was because I wanted to optimize a game I wanted to make before hand. I've tried Unity and I "felt" it was slow, but that was just me having an ego and thinking I could do better kek. Spent years learning a completely different language and low levels libraries to make said game engine that I don't even use today.
I'd say, if you're trying to make a game engine, make it have something fundamentally different than other game engines. Other than that, why waste time reinventing the wheel? (tbf it's pretty fun doing so, I have no idea why)
Good thing about making a game engine is that you learn a lot. Like, a, LOT. 3 years ago I never knew what an "archetype" was or what a "cubemap diffuse irradiance convolution
" is. I've learnt both GPU and CPU algos to optimize code.
Also another thing to point out is that Rust does not have reflection by default, which makes writing some sort of editor become a pain in the ass (though something like bevy_reflect makes this relatively easy)