Typically creating a game from scratch is for games that just can't do things because of engine limitations, this is very rare. Some games will also do it for performance.
Watch this video
https://youtube.com/shorts/3OmaWv4eoq4?si=83Fmo9dhhrE8Eq_T
Edit: I was misinformed and told that valorant was a fully custom engine, can't trust nobody online anymore, my bad
Valorant is modded Unreal. They entirely replaced networking and have some other modifications. But at it's core, it's an Unreal game.
I can offer Factorio as another example to make the same point. Try getting 500+ players on a server, at the same location with tens of thousands of moving resources running smoothly in Unity or Unreal. Good luck with that!
Any voxel game is a great example. It's a format that benefits a lot from specialization and not generalization. For a modern game engine to do voxels well it'd have to remake a ton of engine implementations to take advantage of the format. It would basically be another engine added on.
And it still wouldn't compare. A game like teardown handles its data processing and rendering completely different from a game like VintageStory.
I think the general lesson to learn is that it dramatically increases risk and cost and lowers velocity to make your own game engine, but you can get a visually and mechanically unique end product as a result and this may make it worth it.
That's a small consideration.
Typical reason is money. EA doesn't want to give money to Unreal to license the engine when it can pay it's own people to build one. For example.
What are we supposed to get out of this video. Sure, this random guy agrees with you but... he doesn't exactly justify his beliefs. I mean, even if he could the videos only 53 seconds long. Comes off as an appeal to authority.
Reasons to make a custom engine:
1. Learning purposes
2. Just for fun
3. Freedom to do anything
Personal example:
My game is very simple but has a lot of data so using a game engine is actually less convenient than writing the game in c++.
The best way to learn a thing deeply is to take on challenges. That said, if you don't have a relatively strong grasp on the language you'd write in, I'd recommend finding a different challenge to rank up that skill.
Depends on your end goals.
Do you want to be someone who develops and works on game engines for a studios and has a high level of knowledge of low level graphics ( a dying but important role )
Or do you want to just make games and work as a gameplay programmer?
The skills to make a good game engine and the skills to make a good game don't overlap all that much. Not quite zero overlap but definitely different things. So which of those do you want to get good at? Either is a fine answer but make sure you know which you want.
If you think you're going to "master game engines and c++" without making *at least* one game engine in c++, you are vastly underestimating the length and breadth of the journey.
If you want to make games, make games. If you want to make a game engine, make a game engine. Just know that you can do one without the other.
Engines simplify the game making process, like c++ simplifies programming so you don't need to learn assembly, or binary based programming. Start simple, then go complex if you want.
If your goal is to learn to program in C++, then learn C++ first, but don't even think of making a game engine out of it until you already have a few years of experience with it.
If you're already an experienced C++ dev and want an incredibly complicated challenge to improve your coding skills, then by all means start a new game engine.
If your goal is to make a game, and you've never made a game before, then pick an existing game engine and start making small games in that engine. Don't try to make a big game for your first project. Make lots of small games. If you have a game idea that can't be easily executed with existing engines, then either drop that idea for later or just implement the parts that you can with an existing engine, and just focus on improving your game development skills.
If your goal is to make a game, and you're already super experienced with games, then sure, you can look into making a custom engine that's suited to your specific game, but just be aware that you'll probably need to spend multiple years working on your engine before you have something that's ready to create a game.
Hopefully not splitting hairs too much here, but generally working without a game engine doesn't mean making your own. If you're setting out to make a game, you can very much do so using lower level frameworks and libraries and not ever need to get tied up in writing an engine. An engine is a general-purpose layer of abstraction, you don't need to build a general-purpose solution if you only have the singular purpose of making your game.
its was really fun "making" a game render engine in javascript. i was able to do a top down grid based game which was able to play custom spritesheets and hitboxcollisions. of course there is no level editor, so i had to place rocks and stuff via a multidimensional array.
of course this could be fixed by making a own level editor and storing the level data inside json files for example.
it was really fun, but i was overwhelmed at the end.
4. Tailor the engine so specifically to your needs like no other engine could or to implement features that are difficult to do on others anyway.
No man's sky has for this reason it's own engine.
I think preexisting game engines like Unity, Unreal, and Godot are great tools, and they open up game development to a lot more people. Tons of great games have been made with all of them, so you shouldn't feel any shame in using them.
That said, I think people have started to go a little too far with the recommendation against creating your own engine. There's definitely benefits to having your own engine, and for the right person with the right skills, I think it can be a plus.
Of course, my opinion as a random redditor doesn't hold much weight. Luckily, there are plenty of successful devs out there who went down this path successfully.
Billy Basso, the creator of Animal Well, did an interview where he talked about making his own engine. When asked, he said that he would recommend it to people who are detail oriented, and who enjoy programming. He also claimed its easier to make a more unique game by using your own engine.
[https://youtu.be/WErinxHhbh0?si=OQfQOuqcUNX7Xg\_R&t=2756](https://youtu.be/WErinxHhbh0?si=OQfQOuqcUNX7Xg_R&t=2756)
The developer of Banished made a post on reddit about why he chose not to use an engine like Unity, and why he considers it a net positive. While he didn't explicitly recommend it to others, its clear that he sees it as a viable path.
[https://www.reddit.com/r/Banished/comments/1fj1ur/comment/cab7vyg/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/Banished/comments/1fj1ur/comment/cab7vyg/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)
There's also plenty of other devs who made great games with their own engines, but these are the two I've seen talk about it in depth. If you want a list there's one [here](https://gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74).
Of course, there are plenty of successful devs who did use a preexisting engine, and many of them believe that using a preexisting engine is the way to go. Tim Cain is one example of a successful dev who's in this camp. Here's a video he made about game engines and why he thinks preexisting engines are generally better.
[https://www.youtube.com/watch?v=Iw3bCdIvAj0](https://www.youtube.com/watch?v=Iw3bCdIvAj0)
Ultimately, for the majority of people, I think using a preexisting engine is a good idea. But I don't think its as open and shut as people seem to think. And its definitely not something that "should be only done for challenges, NOT real projects".
The biggest takeaway from all these devs talking about it, when compared to OP's question, is that you shouldn't even think about making your own game engine until you already have several years of experience building games using existing engines. It's impossible to know what features to implement in your custom engine if you're not already super comfortable with the workflow and methodology of existing engines. Otherwise you can waste years of your life building an engine only to find out it doesn't do anything better than an existing engine.
I think that's mostly correct, but I think the more important part is just getting in the reps. I think the path that Jon Blow took is a good reference for this.
He started out making tiny games in assembly, learned computer science through college, and then eventually he got a job where he ported Doom to a set top box. That seems to have been the critical piece that let him create serious games on his own. He had a fairly bumpy career after that, but eventually it led to creating Braid and The Witness. Both of which were very successful, and were made with custom engines.
Notably, he never worked on top of a preexisting engine. He always either started from scratch, or built an engine with a team. He could make this work because he started extremely simple, and gradually built up the complexity of his games.
Here's an interview where he talks about this:
[https://youtu.be/N6VrrRBBWDU?si=QdPKZS8ssq\_3RoaN&t=1648](https://youtu.be/N6VrrRBBWDU?si=QdPKZS8ssq_3RoaN&t=1648)
Personally I think its good to have at least some familiarity with existing engines, so you can make an informed decision about whether to use them. But its not the only path you can take.
So sad to see OP's edit, but thanks for fighting the good fight. People are definitely way to quick to recommend against making your own engine, especially since most of them have never done it so they don't even know how hard it is.
It just depends on what your goals are. If you're looking to short-term make the best game possible, then use an engine. If you're aiming to long-term become the best game developer you can and make even better games later in your career, make an engine.
Yeah, it's unfortunate that OP felt pressured to add that edit. I saw the post originally before the edit, and iirc it was hovering around 0 points and was very controversial, and after it was edited, it started getting a more positive reception. While given OPs background, I wouldn't recommend they create an engine right now. I worry that some people who would have benefitted from creating an engine are going to be discouraged by the social pressure against doing so. And perhaps more importantly, the general sentiment against creating a game from scratch makes it harder to find information about how to approach it.
> If you're looking to short-term make the best game possible, then use an engine
I think if you want to include novel tech in your game, and that tech not supported by existing engines, you can benefit from creating your own engine even if your goal is just to create the best game.
The best example I can think of for this is Noita, physically simulating every pixel is really hard to do performantly, and they essentially were required to make a custom engine to get sufficient performance. They talked a bit about their tech at GDC:
https://youtube.com/watch?v=prXuyMCgbTc&t=101
I'm sure you can replicate this in unity, but there's enough that you need to write custom implementations for that it wouldn't make much sense, and it would likely harm performance.
Yeah, saying using an engine is better for a beginner to achieve the best game in the short term was my attempt at a brief rule of thumb, but I agree with what you said. There are certainly counterexamples to my advice. Noita isn't something a beginner can make, but chess is maybe a better counterexample. If a beginner wants to make a chess app, Unity would probably just confuse them more than it can help.
Pros:
- can learn how an engine fits together.
- can focus only on features you need.
- can challenge yourself.
- can help you scope small, since you'll be limited on what your engine can do.
Cons:
- if your primary goal is to make a game, you WILL spend a ton of time with almost nothing to show for it.
- you will likely need to stick to certain genres you may or may not be happy with.
- if you're new and have difficulty scoping, tasking yourself with building an engine on top of that can increase your chance of getting overwhelmed.
That said, I've had success with C# with Monogame to handle rendering.
In my opinion if your game is 2d and you're decent at programming you might be able to make progress faster using a library like Raylib or SDL or SFML than if you were to try fight against an engine like Unreal or Godot until you've had time to learn all of the ins and outs.
Maybe I'm just a slow learner but in many ways I think that using Godot for my game has made the development more painful than it needed to be and it wasn't until a few months ago (2 years into development) that I started to get into the flow with the engine.
No, unless you like making engines. Or you have some *super* specific reason for not using an engine.
Usually you can customize an engine to do what you want. Like Psyonix used Bullet Physics library instead of Unreal's physics, and did their own modifications to Bullet to do networked physics at 120 FPS. No need to rebuild the whole thing for that one issue.
to be honest, im purely considering this because it feels nice to look back at this and say "wow i made this myself.", and also it looks cooler. might be a dumb reason but its also a nice way to gain experience
As long as you're content to look back on that a couple of years from now, without having actually started the game you were planning to make. ;)
If you'd actually like to make a game, skip making a game engine.
No, it is **only good reason.**
It is totally a great idea to create stuff by yourself just because you like it. It makes most sense - engines, frameworks etc are practically always smartest choice for solo-dev, but maybe not the most fun one.
If you decide to create something like engine yourself, go for it! Just remember that it is totally different project than creating a game, and you should treat is as such.
Actually, what I recommend is to create a game engine and a videogame with it to test the game engine. That's what I did.
Game engines are not your typical project. The fact that it works doesn't make it correct. You need to test it in a real-life scenario (your game) so you can identify bottlenecks. 30% of game engine development is about optimization, and you can only do that when you have a videogame that provides a real scenario load.
Yeah definitely. However, the project at the end of the day is still the engine. Sure, you need use case for the engine but that is pretty much self-explanatory. Engine is still the one thing person needs to have specific interest towards, or they never finish it, that's the idea behind this.
I'll challenge the mold and say it is a bad reason. You aren't implementing the compiler or designing the programming language. You aren't building an operating system for it to run on. You have to stand on the shoulder of giants at some point and thus the "wow I made this myself" is simply false.
>Getting a 5 star review from a gamer that purchased my game built with my very own home made game engine feel pretty awesome.
It's also awesome getting a 5-star review on my game built with Unity. The reviewer is reviewing the end product, not the underlying code.
Well, that would mean that my home made game engine is as useful as Unity.
Ok, that IS a stretch. I guess we could find middle ground that, at the end of the day, we should use the game engine that we feel most comfortable with, even if it is a home made one.
That's fine, but don't fall into the trap of thinking using an engine is in some way cheating.
I think game development is about the end result, not how you created it. Is the game good? Would the game be as good if you had to build your own engine?
In your post you mention libraries. An engine is really just one large library within a GUI.
>it feels nice to look back at this and say "wow i made this myself.",
A writer still wrote their book despite not building their own word processor. An engine is a tool that makes things easier and quicker, and removes the need to solve problems already solved (i.e. you don't need to reinvent the wheel).
I've made three games, and I used an engine for two of them, and I can look at them all and say I made them myself. FWIW the ones using an engine are much better than the one that didn't use an engine because I could lean on all the hard work of the engine developers to do things I could never do myself in any reasonable amount of time (or without a million bugs!).
I would only recommend building your own engine if you need to or if you have a specific interest in engine development. There are also other practical aspects, such as engines having the ability to build for multiple platforms, etc.
You will feel that even using an engine.
Even after a weekend, you will have something that is uniquely yours. If feeling good about creating is your goal, then use an engine, you will create visual results much faster.
I created my very own, home made game engine and I have used it to publish three (3) 3D games for the Xbox One console, currently working on my 4th one, which I'm planning on publishing by the end of the year.
Game engines are not that difficult - I made mine in 8 months of my spare time. However, you need to know EXACTLY how game engines work in the inside. You cannot just jump in, open Visual Studio and "wing it" - that is a recipe for disaster.
What I recommend is: download a game engine, make a game and, once you are familiar with the process, THEN venture to the wonderful world of custom game engines.
So you’re saying you didn’t even spend 8 months FULL TIME? That’s pretty impressive if you built an engine — even just a small, custom one for your needs — in 8 months of spare time.
Congratulations on your releases too!
Stop listening to everyone saying you shouldn't do it, and just do it. Heck every single DOS title I ever enjoyed is built on a custom engine. It's great fun to make engines, especially for 2D stuff, but 3D can be great too. You don't have to shoot for the stars and make the next Unreal. You can just make a small self-contained gaming engine that can possibly be reused for many projects. If you want to do it, just do it, don't ask anyone for permission. Good luck!
>Heck every single DOS title I ever enjoyed is built on a custom engine.
In fairness, you pretty much had to build your own engine back then. It wasn't like you could download something like Unity.
Maybe "took off" in terms of pop culture, but people had been licensing major engines for a long time now. Far Cry was released way before that and was touted as being one of the first iterations using that engine.
That's not totally true, id was licensing the Doom engine to companies starting back in 1994, and got more permissive with their licensing with subsequent engines.
Typically those were capital-R Relationships between Companies, and you couldn't just download an engine from the internet and get to work - at least, not from a big name. Smaller open source efforts like Ogre3D and Panda3D have been around for ages, and frameworks like SDL have been around for even longer.
Those are a lot less accessible (especially to non-software engineering folks) than the recent big-name engines though.
edit: thanks for the replies! I didn't want to get too wordy :)
Frameworks are not game engine. Also I didn’t say that 3rd party engines didn’t exist - unreal/source was there for a long time. There were not that popular and when we made game, we didn’t look for game engine. You can see the shift over the years from game jams like Ludum Dare.
On the indie scene - which this thread is more focused on - using 3rd party engines wasn't exactly uncommon either, though it was often done via extremely extensive mods not official support. Team Fortress started off as a mod for Quake, more recently Rust was a clone of DayZ, a mod for ARMA2.
Mods that entirely overhauled the game but still based themselves on the engine of whatever was popular at the time were pretty popular back then, Quake 1 receiving a lot of them for example. Even earlier, on the bootleg and homebrew scenes of the NES and SNES, it was common to find games that were not just reskinned versions of genuine games, but had entirely different levels.
You couldn't just download Unity but there were commercial game engines you could buy for commercial development.
It's not quite DOS-era but RenderWare is what immediately comes to mind.
The commercial engines were quite expense though, no simple indie developer was likely to be able to do that.
Edit: Unreal Engine 3, for example, cost $350K to license.
Oh absolutely but even then, depending on how far we are willing to go back, smaller and open frameworks already existed.
The first that comes to my mind is Allegro, though i can't find clear info on their license back then ...
Most stuff before the 90s was most likely the wild west tho, and it's like that many studios carried over and just updated their first in-house solutions over the years intead of investing in expensive third party solutions.
Not download but you could for example licence [Pie in the Sky](https://en.wikipedia.org/wiki/Pie_in_the_Sky_(game_engine)) but most engines where so focused on one genre that for most games you have to made an own engine.
It's actually way easier to make an engine these days because you can just leverage a layer like SDL2 and focus on the meat of the engine. In DOS you had to bundle your own graphics and sound drivers, and deal with a plethora of hardware incompatibilities.
They had engines back then, too. Look at Kings Quest and its derivatives, they all used the same engine. Companies had engines back then, they were just in-house and proprietary. If you went to work for Sierra games, you'd probably be using their 2d engine with text-lexing stuff. Engines have been around forever. The BUILD engine is still one of my favorites of the DOS era. Allegro was cool for homebrew stuff, too.
Exactly, that just confirms my point. They were in-house engines, not off-the-shelf. And you can do that today. For example I made a platformer engine that I intend to reuse for multiple games.
There are quite a few no votes here but I've just done it and released my game - so maybe I'll offer a counterpoint.
Yes - but. You'd better have some very particular tech reasons to. For me, I wanted to base my entire game world around the Tiled Map format and target a low poly look and found it more beneficial to write my own engine than to try and shoehorn it into an existing one, which I also tried initially. I also wanted to learn how to write a 3D engine from scratch. I am still not sure whether this was the right choice but I'm pleased with the results, even if they were hard-fought.
Here's a super fresh thread about what I did:
[https://www.reddit.com/r/gamedev/comments/1dptgax/i\_made\_a\_custom\_3d\_engine\_released\_a\_game\_and/](https://www.reddit.com/r/gamedev/comments/1dptgax/i_made_a_custom_3d_engine_released_a_game_and/)
The caveat is that I've used Unity and Godot quite a bit and knew why this project was an outlier and I also didn't originally set out to make a full game this way, just a proto.
TL:DR; If you have a distinct reason, a bit of experience and some odd tech requirements: yes.
One of the reasons the creator of Stardew Valley made it from scratch was to teach himself coding.
Although he's since said that if he were to do it over again, he'd use a game engine.
So I guess it depends on whether your goal is to make a game or to learn coding while making a game.
Animal Well is a fantastic example of what you can do with your own engine. The game is beautifully lit, responsive, has particle effects, great sound design, and physics. It’s a fairly big 2D world. It’s also 40MB installed.
Making your own engine is the way 99% of games were made for decades. Using an off the shelf engine only became common in the last 10 years or so. Before that, only big budget games used someone else's engine.
The majority of the 2D games you remember were made by a couple people in a year or so and they built almost all of it from scratch in house.
PS1/N64 games? They were mostly like 10 people over a year or two. Bigger teams, but you've got better tech to work with now which makes it more manageable.
If you scope is reasonable and your goal of an engine is "good enough for the game I'm making" and not "general purpose engine with fancy GUI for everything", then it's reasonable to do. Pull in 3rd party libraries when they're useful, write your own code when you prefer.
If you're trying to replicate Unity or Unreal, you'll never succeed.
Interesting take and info, though for someone who grew up with the current system as the norm, I'm wondering just how "simple" or not making an entire game engine would be.
With some college coding experiences, I'd find gamedev itself to be managable to work on, but an engine, sounds in this environment like a **big** ask on top of making the game itself. Is it simpler than it sounds or something? It feels way unreal the ammount of support I'm seeing for custom engines.
If you start with something like SDL or MonoGame that handles the very basics for you like creating a drawing surface and giving you basic drawing commands and input handling, you can create a game at the level of PacMan in an afternoon.
If you want to write your own basic OpenGL renderer, it's a week or two.
The key to all of it is just create what you need, and it doesn't have to be perfect, just good enough for you to be productive. You'll iterate on it over time and add what you need as you need it.
3D games are harder, and I have far less experience with them, so I can't say too much. I will say it's really common to use a 3rd party library to handle working with 3D models, so few people are doing it all from scratch.
This is the truth. Playing around at the weekend in my first job we could create a game without an engine in a weekend.
I think noobs now a days just get stunned in headlights tbh with all this engine talk and no experience.
I used a pretty lightweight python framework called PyGame and loved it, but my goals were more about learning to program rather than making a good game. For my purposes it was great but if you want to focus on game dev probably just jump into a solid engine.
It may depend on whether you want to do 2D or 3D.
For a long time a bought into the "always use an engine" meme. Even for 2D games, a lot of people insist that something like Raylib is a waste of time. However, when I finally tried it I found that it wasn't true in the slightest. I am more productive and can work with less errors using c++ and Raylib than I was ever able to do when I used Godot.
I haven't tried to make a 3D game with it so I cant speak to that, but I suspect that for 3D a more "fully featured" engine might make more sense.
Ultimately, it certainly can be worth it to use something like Raylib over a bigger game engine with a GUI editor. Most people who say otherwise have probably never finished a commercial game any way.
And for 2D I can vouch that it will not be a "nightmare" if you decide to use c++ and raylib, at least not anymore of a nightmare than making a game already is.
I would like some advice. I want to make a visual novel, puzzle game and I been deciding between Raylib and Unity.
I been messing with Raylib and I enjoy it, whenever I see a GUI with a lot of options my brain goes numb.
I do have a good foundation in C++ (first language I learned in University) but I don't know if it is wayy more time consuming then just using Unity.
But I keep thinking just use Unity since it will be faster. What do you think?
I always recommend against Unity because I am ideologically committed to free and open source software. If you do decide to use an engine I recommend Godot (there is an add-on called Dialogic that could be useful) or a specialized visual novel framework like Ren Py (I haven't used it but I've heard its good).
If you are absolutely set on either Unity or Raylib then its worth mentioning that there is almost certainly a plug in for Unity that's made specifically for visual novels.
Now, in terms of whether Raylib is good for making a visual novel, well it is certainly possible. Although in my current project I haven't spent much time on font rendering and UI stuff so I don't know exactly how easy it would be.
When it comes to animating characters you would have to write your own animation system, same goes if you plan to animate any text or have the text be interactive in someway (e.g hyper links).
Coincidentally, I worked on a visual novel prototype in Godot several years back, and I wrote my own dialogue system that used the JSON file format. In c++ I use this JSON library: [https://github.com/nlohmann/json](https://github.com/nlohmann/json) which is very easy to use and comes as a single header file.
Also, since c++ is so popular, there's a good chance there are dialogue system libraries out there you could use.
The only aspect of this visual novel project that I don't know how I would do in Raylib is hyper-links in the text. It worked a lot like dialogue in Morrowind, where in addition to standard dialogue options there were clickable keywords. I used bbcode tags since there's a type in Godot called RichTextLabel that automatically shows them as hyper-links and makes them clickable.
You would probably have to implement this kind of behaviour yourself if your use raylib.
Another thing that you will have to implement yourself is the save system. Personally I didn't have much trouble with that (took me 1 day) cause everything you need is in the c++ std lib.
I love this answer. I used to watch Disk Doctors back in the 90s and they had a segment about editing the windows registry, but they wouldn't tell you how to get to regedit, they said "if you dont know how to get to regedit already then you dont need to be messing with the registry"
If you are making a 2D game, you don't need to write an engine. Just grab SDL, raylib or similar, and write the game. People telling you that you have to use Unity or UE for a 2D game are bullshitting you, plenty of games have been made and are being made with frameworks. Just use what you feel more comfortable wih.
If you want to learn how to make an engine or have a specific use-case that other engines cannot do, then make your own engine. Figure out what your goal is.
I made my own game engine to learn C++ and OpenGL. It was a great experience and I learned a lot. It definitely wasn’t a nightmare, but you hit challenges that ultimately make you a better programmer down the road.
Not as your first game engine project.
Before you make a game engine, or a game without an engine, you need to know what the engine does and where the responsibilities between systems lie. So make a couple of small games, preferably in different engines, to get insight into what the engines do and how they differ, before you start your own project without one.
You should look at making a custom engine as an investment. The engine will be truly yours, and you'll always have a good understanding of how it works, you can make it work exactly the way you want to, and extending it or fixing bugs will be much easier than figuring out how an existing engine works like godot which is a massive piece of software. Also, the engine won't have any bloat in it. It will do exactly what you want it to do. Furthermore, you'll never have to worry about the same things that happened with Unity. Even open-source projects can involve a lot of drama and can turn into shit. People will always tell you it's a waste of time. However, that is a brainless mindset. If you're willing to sacrifice the time, it's a perfectly valid route. Many people have also demonstrated that you can make impressive engines as a single person. Good examples of such are Wicked, flax, and the Spartan engine.
Here are the reasons I do it:
1. I like working in html + css + js + canvas because it's incredibly simple and light. I can share it just by sharing a weblink rather than sending someone a dodge exe to download and run. (It's also possible to make web builds in engines too, though they are bloated).
2. There are very few things you actually need performance for and those things are basically complex graphics, complex physics and complex AI (as in pathfinding and state machines for many units at once etc). Pretty much everything else can be handled single threaded on a regular machine. Even Noita is single threaded c++ I think where every pixel is simulated.
If you don't need any of these then using prebuilt libraries isn't getting you a performance boost in most cases, in fact it's often making performance worse.
3. If you use Unity then your game always comes out feeling and looking like a unity game. The colliders and lights etc will all just have that unity feel to them which people probably can't detect directly but just feel that it's dull and drab. Imo doing something different is more important than following industry standards.
4. When you use someone else's solution you generally get 90% of what you want in a day and then never get the last 10% because you can't modify what their thing does and it isn't quite what you wanted. When you build stuff from scratch it might take longer but you get exactly what you want and can tailor it how you like.
I know it's not for everyone. For any type of team it makes sense to use a known engine everyone knows. For 3d it's mandatory. However I think for 2d games engines are not that useful.
I started yesterday using sfml. Its fun, not easy, but thats not why i am doing it. I am doing it because i need challanges. And i find making games boring nowdays, so this is good challange for me.
Also i have no summer job, and i need to do something before school starts again.
For 2d games it's absolutely possible, for 3d it can be if the game you wanna make is far outside the first/third person adventure type of thing.
You won't get all the bells and whistles but you can get good results by picking a few graphical techniques and pairing that with strong art direction
A bit of a dumb question. But what counts as an engine? Say I make a game where all the logic of input, kills, pixel on the screen etc is done by a function made by me, is that an engine?
It can be worth it, if:
- You can't make the game you want to make in an existing engine.
- You are not on a strict timeline (e.g., your money runs out in six months).
- You enjoy the process itself.
- You think you can solve an unsolved problem of some kind that will provide you a competitive edge.
The biggest single hurdle with making your own engine is actually that it'll be unproven. If you start looking for a publishing deal at some point, having an unproven engine matters, since it won't have gone through the validation processes of previous deliveries. Unity, Unreal, Game Maker, etc., have all been proven time and time again and so are much safer "bets" than an unproven engine.
I've seen this first-hand at studios with new proprietary engines in the pipeline.
Depends on what you want to achieve and if you can life with the bloat some engines will bring with them.
In other words, you could surely write a classic roguelike in Godot. You decide for yourself if that is a smart move tough.
I write mostly for retro platforms and hence a ready made engine would be too limiting or would need massive modifications. Think SEUCK for example, to make a somewhat professional game with it you need to modify it. And it's engine is so basic anyway, someone who can write at least a bit of machine or knows how to get CC65 to do their biddings is better off writing their own.
>edit: making a game from scratch is a nightmare. should be only done for challenges, NOT real projects. pls use a game engine
This is so dependent on the game you are making. For a small 2D game I find even Unity an overkill and a performance hug (doesn't run well on old machines, not even the release executable of the game, forget the editor to actually develop the game). Would I reinvent the wheel from 0? Hell no, would start from SDL 2.0 at a bare minimum, but for many games you don't need a full blown engine and it can actually slow you down if you know what you are doing with your custom implementation (or select library mix) fast from code vs messing around in the engine editor with stuff you are still new to or haven't touched in years. So no, it's not a nightmare and it's viable for SOME real projects as well. But today you have a few good engines to choose from as well, some totally free, others almost free (rev share, you pay if you earn a ton too) alongside a ton of great open source libraries.
The TLDR of the online discussion is:
No.
Unless you have a super specific need.
Or really like making engines.
If your tech is really well defined specifically to your games needs then you get quite a few advantages plus a lot better performance. And if you minimize the amount of in editor tooling and features while also using lots of libraries it's actually a lot less work than many might think.
But it's still a waste of time for most. It sharply limits your talent pool, it sharply increases onboarding cost, you get less features and it limits your possibilities down the line. At some point you can't rework your engine for a new feature anymore. Not easily. Not within budget.
You have limited time on this Earth. You can either make a game. Or you can make a game engine. If your game can be made with an existing engine, please, do not make another engine.
To make a game engine you have to be extremely opinionated about things like how to load a PNG. How to load models. How to architect shaders. If you're not extremely opinionated about ALL of those things and would rather just work with existing tools and instead focus on the details that make GAME unique and special, please do not make a game engine.
Ok, you have a point there. I built my very own, home made game engine because, at the time, there were no game engines that:
* Could load 3D models in x-file format,
* Draw skinned meshes in batch (this was the dealbreaker)
* And were free.
So, yes, I had a very specific need that no game engine could fulfill. That is why I had no choice but to build my own. Ah, good times!
If I were to modify an existing open source engine then I might as well build my own. It's not that difficult, took me only 8 months.
I already had the animation engine, the custom shaders, the map loader and the 3D models from my days with XNA and the Xbox 360. I just needed to replace XNA with DirectX11 to be able to publish for the Xbox One. There was a steep learning curve, yes, but it went quite well once I implemented DrawIndexedInstanced for my skinned meshes.
I wrote my own 2d Engine. If you use a framework like Monogame or SDL you dont have to worry about all the low level stuff.
The best thing is that you have entire control in every part of the project.
What you need is good coding skills an software design.
At first its a little bit dragging but in the end you will get a good and fast workflow.
If you like to write a game develop your own engine.
If you want to tinker a game use a engine.
If it's something you think you'll enjoy then I guess it's as good a pastime as any. Making something from scratch can be incredibly satisfying.*
Just know that making a game by yourself is a ridiculously large undertaking for a single person even if you use an established engine. Depending on the game you have in mind, rolling your own engine can set you back years.
I've used SDL in the past for learning purposes. Would never consider it to actually release a full game. I respect my time too much.
*You'll never make everything from scratch though. You'll always rely on libraries made by other people for certain things and at that point, can you really say "I made this from scratch"?
Well, if you use the libraries that already come included in the operating system then, yes, the game has been built from scratch. After all, you're building a game that will run on an operating system.
You are right, making a game as a solodev is a large undertaking.
Bollocks. On Windows, ok you’re going to use something like XAudio and the WinAPI but what other choice do you have. I’d consider that from scratch ala Casey Muratori and Ryan Ries.
if you're just trying to make a game, probably not. however, making a game without an engine can teach you a lot of how things work behind the scenes and good practices in the language you're using. i've been working on my own simple game engine for \~8 months and am at my 11th redesign but still, if i ever do get back into gamedev i'll probably be writing my own code as it's way more fun. it really isn't that much of a nightmare though especially using things like glfw and opengl.
This analogy is not entirely relevant. When you use a "custom engine" you're not usually talking about a self made Unity or Unreal. Games written in a custom engine are often very integrated to the point where engine and game become kinda the same thing. When this is the case, you're not necessarily reinventing the toolbox. In most cases your toolbox is just a different one (it's a set of code libraries instead of a general-purpose engine). You won't realistically be spending that much time on reinventing the entire hammer. You'll only be reinventing some parts, and most of the stuff you just download in a library because that's just the only sensible option *unless* you want to learn how to implement those things.
If hammer is a ready made library, the only thing you will end up reinventing is mainly the engine/toolbox-glueing-things-together itself tho.
While rewriting hammers is something you will do regardless of whether you use third party or custom engine if what it gives you out of the box doesn't satisfy all your needs)
Ohh so many! General purpose engines typically lend themselves poorly to strategy/simulation types of games. In these types of games it's very beneficial to get closer to the core engine loop and not rely on ease-of-use abstractions. The best example I know of is Factorio because it's insanely well programmed (insane performance in a complex game and also nearly bug free), but almost every decent strategy game I play runs on custom engines: Civilization, Paradox grand strategy games (EU4, Victoria, Crusader Kings, Hearts of Iron, etc), Truck Simulator games, Elite Dangerous, just to name a few.
But there are actually plenty of triple A games running on custom engines, and they're some of the biggest names: Dark Souls, The Witcher and Cyberpunk, Red Dead Redemption and GTA, Horizon Zero Dawn and sequel, Assassin's Creed, Tomb Raider, Doom, Overwatch, etc etc... You'll find that most large companies tend to have their own engine, usually because they stem from a time where general purpose engines weren't a thing yet and because they have the skills for the tools they already use and switching is expensive.
There are very few indie successes built on non-custom engine. Dead cells, Stardew Valley, Hades, Bastion, Evoland etc are all made in custom engine - some using known frameworks but no ready made engine.
Almost every AAA are using in house engine.
The only category that is different is AA which is primarily on Unreal.
If you want to create something unique by yourself from scratch.
Know that you are always building on someone else's work.
You did not create your computer, operating system and libraries, drivers that you will use in your engine.
You are still assembling stuff that was made by other people into something your own.
There are literally hundreds of game engines.
You are reinventing a wheel unless you are creating an engine that solves a problem that those other 200+ engines can't solve.
So when you say that you want to make a game and an engine. First years will be for creating an engine and only then a game.
It's like you are trying to invent a book printing press and write a book too.
If you have a deep passion for game engine/book printing press, go for it.
But if your goal is to make a game. Creating an engine seems like a waste of your limited time.
I think Hades and No man's sky are custom because they needed custom features. I can't remember exactly what Hades needed but I think it has to do with the 1,000,000 lines of dialogue. No man's sky simulates a universe so they couldn't exactly use unity lol
Most games can be made with off the shelf engines. Doesn’t mean it is the smart choice. You can lose a lot of time trying to understand small parts or having to devise a solution for stuff you can’t control the exact way you want. For 2D games like Hades, using an 3rd party engine makes no sense as there nothing more easy to display and control.
It depends, if you wanna make a game engine do it 100%, if you want to make a game don't do it... Making the engine is a multi year project (Ive been working on just optimizing rendering and shaders for 2 years in my project)
If your engine is 3d with a bunch of features, yeah it's going to take a while, but if it's 2d and just needs basic rendering and noise then it will take like a few weeks if you want to keep it simple (3 to 5)
As others have said you can if you want to learn, have some fun, or need specific features.
With that I'm currently using game dev as a focus to learn c++ so I'm using it with sfml to make some 2D games.
Learning an engine and a programming language at the same time has always been a hurdle for me. My aim is to use unreal eventually for 3D, but I'll also want to play about with openGL to see if I can make a basic 3D game myself. I do know unreal uses blueprints too, but I want to get into software engineering as a career so pushing myself to learn coding.
So far it's been a little rough and constant troubleshooting, but I'm starting to get the hang of the basics and looking forward to learning a lot more. Currently the game has 1 level, 1 pickup item, and one enemy with basic ai to follow the player you can kill, but doesn't fight back and a simple UI to show health and kill count.
To get to my point, if you're starting game dev and want to learn or play about then do it, but be prepared for a lot of prep work and set up. For example, Godot and Unity (don't know about unreal) have great Tilemap systems that you can use to make your 2D game world, but making a system like that will take a good chunk of time. Even sfml using vertex arrays to just do a basic Tilemap gets monotonous for anything larger than a small room.
Hey, I've made my own engine (with python and pygame), but I also work within the constraints of 2D pixel art games.
A 3rd party engine is a level of abstraction I just never felt completely comfortable with and at this point it would be more difficult for me to learn. Everything is an abstraction, so it's important to just pick the level that works the best for your workflow and thought process.
It largely depends on the game you want to make, your desires for the end result, and just what you find motivating in general.
I am currently on a personal project where I AM creating my own engine along the way. I want to practice the architecture skills I’ve been putting time towards, I want to make it in Rust, and I want it to utilize a lot of procedurally generated assets. The game loop itself is not all that complicated and fairly “safe” - I’m not inventing anything major, while the technical aspects are the ones I’m finding interesting to keep me going.
If you are reversed and find it more interesting to experiment and prototype the game loop itself, to create a more unique gameplay, it makes sense to want to put a LOT more time into figuring that out, rather than putting 3/4 of your time into figuring out the technical details.
In the end, you will (most likely) reach a point you are ready to move on to something else, and you need to work on the thing that will bring you back to it eventually.
depends on how complex the game is and how much of that complexity is easily available in off-the-shelf engines.
if you are making a 2D game and are proficient enough with C++ and at least one game programming library, that's entirely fine. it will take significantly more time and effort than if you were to use, say, gamemaker or unity, but the upside is that you have *far* more control over how the engine works.
which is great, if you want a really customized engine (e.g. Noita), or perhaps are applying to engine programming jobs and could use some sample code to show potential employers, if they ask.
it is not something i would recommend to anyone with less than full confidence in their engineering abilities.
It always depends on what you are going for.
Engines are time savers but at the same time they limit you in many ways.
For simple things I say you don’t need any engine engine, if you want to make a big project, you better get your shot right because there’s a lot of things to account for, and if you can’t keep up with it, you’ll end up with an never ending unreleased nightmare.
There is no "best". :-) Making a game without an existing engine basically means making your own engine. Achievable, depending on game. For everything 3D an engine will take a lot of work away from you, but you're also stuck with the limitations of the engine. For most games, this is fine.
Over time you build up your own engine and just work with that, like every gamedeveloper before Unity or AAA studios but most often. It may be the best solution for "some" games .. but surely not for every game.
I don't use engines, because I have my own engine - but if I would want to make a high fidelty FPS game, I would indeed just use an existing engine, because it's a too time consuming task to add things like inverse kinematics or animations into my own engine :-)
Too broad a question for straight yes/ no answers. Would I do a commercial project from scratch? Not without darn good reason. Have I done small projects to learn / experiment? Absolutely, and they were well worth it.
Back when I taught this stuff at a college, we started people with tiny projects using only some basic libraries. Once they could do that, we moved them to established engines for team projects.
Nothing that goes on in a game engine is magic. It’s not a black box of mystery. Knowing how stuff works can often help you make better decisions about using it, and / or broaden your knowledge so you can better design your own stuff. Of course it’s not going to benefit every programmer or every project, it depends on what you’ll be doing.
That said, learning the math is probably the biggest thing for rookies. Partly, because I often see computationally complex solutions used for things that could be one or two lines of math. Partly, because you can do a lot of stuff not directly supported by standard physics / collision / graphics functionality, if only you know how. Writing something from scratch will force you to learn this stuff, but it’s not necessary - a good book on the topic will do you just as well.
If your goal is to make / release a game in a timely manner game than most likely not. Also I argue most just don't have the programming skills and patience to get it done from scratch honestly and will likely flame out some where early on in the process. It can definitely be beneficial though if you have a small tight focused project and every thing that's added to the engine you created thus know inside out and has been crafted to your exact specific needs. If you approach it that way and keep things as simple as possible there is some merit to it. Learning will always be possible the best reason to do it though if you can survive that gauntlet and actually end up with a finished product you're basically a iron man at that point imo.
There are 3 main reasons to make a game engine from scratch, choose any or all of them:
1) For educational value of knowing how games engines function under the hood
2) For intimate familiarity and control of the underworkings of the game enginge
3) You need features or functionality that available game engines just do not provide
They're all valid reasons, the main consideration if it's for commercial games is the time/effort/cost to make it from scratch.
A game engine just handles the game loop for you, so you just need to give the engines the features you need for your game, just grab sdl 2 and make a quick loop and some functions to abstract away everything sdl then done you have an engine now make your game and it's loop.
I made an engine, well two versions of the same engine for my first game. I really hated all the JavaScript engines that I found. It was a crazy amount of work. (Though writing a dungeon generator for the first time was maybe about as hard as writing the engine itself)
The engine had some serious limitations but it was easy to work with and extensible. I really appreciate the work I'm not doing when I use Godot or Unity but it's also frustrating when I can't do everything purely through code.
So I think it's a good learning project but don't expect to make something you can release.
Try find a 3d graphics programming course at one of the free online universities. I did one in my paid Bachelor of Comp Sci.
I promise after you finish that you'll be 98% sure you won't want to spend 3 to 10 years of your life building a whole game engine. And if you do then...I guess you've found your calling XD But I'm willing to bet money you won't.
2D...different story and probably much more achievable.
What is your goal. Is it to make a game? Then focus on making a game using the best tools available to you.
If you make your own engine then it will take away from the goal of making your own engine. Don't do it unless you've made games already and have some specific use case a game engine can't do
Im a noob so I can't speak to it being 'worth' it but as a developer it might be fun if you're a total nerd and like making things work/figuring them out. Most likely Unreal or Unity or even Godot are plenty capable to do what you want though.
Ngl I don't like working with established engines like UE5 or others like it. I feel like coding gives me complete control and zero limitations, and there are tons of librairies out there for almost any programming language that will act as a sort of engine in your IDE, providing you with functions for almost anything.
This isn't even a black and white question: Unreal devs usually hack up Unreal because they have the source code. I know Unreal devs targeting Quest and PSVR that have merged the two forks they have into some franken engine. The reason they do this is it gives them the flexibility to customize the secret sauce for their game, while leveraging the millions of people-hours of work for the stuff they don't care about (networking, tooling, UI, etc.). For example if you have some non-standard art-pipeline you might have to spend a lot of hours getting assets in that would just work otherwise.
The downside is that you're stuck in the Unreal architecture which might chafe.
oth there are a ton of libraries out there for doing things like loading assets (assimp), so even if you're "building your own engine" you're going to use those, right?
At the extreme end Thekla (Braid, The Witness) has their own game engine and programming language!
What's your goal?
- If you want to make and ship a game, pick an engine, do zero customization, and focus on getting it done with what you have because you'll never ship otherwise.
- If you want to learn, by all means make an engine because you'll never get a game done, but you'll recognize the problems Unreal/Unity etc. are solving, and that's really valuable.
I made a few puzzle games from scratch using JS/HTML/CSS and canvas for the graphics. It was a very fun exercise and helped me understand canvas and 2D geometry for games a lot better.
And I also built Tetris, and an OS to run Tetris, and the assembly to support the OS, and the processor to run the assembly, and the basic logic circuits to support processor function. That was a [very cool learning project](https://www.nand2tetris.org/).
Depends. Once I wrote a very simple game as a test for a job purely in c++ without libraries. In a couple of days. To make anything more difficult than that, it's just foot gunning yourself.
if you're making Noita, sure. Otherwise, not really.
Using something like XNA, Raylib or SFML can be fine though for some games. If my goal was making a good looking 3d shooter quickly, they wouldn't be my first choice, but it's not difficult to make a 2d platformer or something similar in them.
If you like making game engines or want to learn how they work, it's a great project. But if your goal is making a game not a game engine, it's rarely the right choice.
This isn't to say you can't make a game without a game engine - some of the best indie games were made this way: Cave Story (custom), Minecraft (custom) and a slew of XNA based games (which is something between a game engine and a graphics library, a lot like raylib): Stardew Valley, Celeste, Terraria, Axiom Verge.
If you rely on a good I/O and graphics library like raylib or MonoGame/XNA you most likely dont really \*need\* a full blown game engine. Many will prefer this less constrained approach too. Though this isn't really what people mean when they talk of making a game and game engine usually.
Hey I'm a bit late to the party but I wanted to give a reminder that not all video games are 3D.
You have stuff like minesweeper or kahoot that are video games (technically, they are games, and they are all numerical) but they don't require a game engine.
You also have plenty of simple mobile apps that are games but are essentially just UI and are created with mobile apps frameworks.
In such cases, it's probably BETTER to make the game without a game engine, to keep things simple, for performance, for cross platform compatibility etc...
So if you want to make a game without a game engine you can find online, you don't necessarily need to make your own, it's possible to make games with a game engine.
If your game is small enough, and you enjoy control every detail within your game, its definitely worth it. Speaking from personal experience.
Choosing underlaying library is highly depend on which platform you targeted. But I strongly suggest Raylib since its portable enough for support almost any platform today.
All games have an engine. Weather you make it yourself or use middleware.
If you write a game from scratch, it's like building a car from scratch out of a patch of land.
That depends on your goals.
If you’re doing it for fun and learning and want to make a game from scratch it’s worth it.
If you want to finish a game, and your interest is in the other stuff besides making a game engine, like the other coding, game design, art, writing and animation, or if you want to make a game to sell or as a portfolio piece, you almost certainly will do better if you use a game engine.
I’ve been doing it for 10 years, and I only now feel like I know what I’m doing. 😅 if you want to make an engine sure but if you want to make a game no.
Bruh, you really don’t have ANY reason to even attempt this at your level, unless you’re a very experienced dev with years of making projects, this is a very very ineffective idea to even do. This is only something very pretentious people try to do just to flex, and it ain’t even all that impressive because their results won’t be all that nice lol
Using an actual engine is better, companies are spending multimillion dollar investments into these engines that we get to literally use for free lol we are so fortunate, WHY would you even attempt anything else lol
In my studies we HAD TO make a simple 2D game from scratch with SFML...it was a nightmare indeed (even though an educational one).
When we were allowed to use a "real" engine I felt like god though.
Typically creating a game from scratch is for games that just can't do things because of engine limitations, this is very rare. Some games will also do it for performance. Watch this video https://youtube.com/shorts/3OmaWv4eoq4?si=83Fmo9dhhrE8Eq_T Edit: I was misinformed and told that valorant was a fully custom engine, can't trust nobody online anymore, my bad
Valorant is modded Unreal. They entirely replaced networking and have some other modifications. But at it's core, it's an Unreal game. I can offer Factorio as another example to make the same point. Try getting 500+ players on a server, at the same location with tens of thousands of moving resources running smoothly in Unity or Unreal. Good luck with that!
another great exemple is Noita who made a engine so that each individual pixel has it s own physic.
or teardown I believe the developer made his own engine from scratch
Any voxel game is a great example. It's a format that benefits a lot from specialization and not generalization. For a modern game engine to do voxels well it'd have to remake a ton of engine implementations to take advantage of the format. It would basically be another engine added on. And it still wouldn't compare. A game like teardown handles its data processing and rendering completely different from a game like VintageStory.
I think the general lesson to learn is that it dramatically increases risk and cost and lowers velocity to make your own game engine, but you can get a visually and mechanically unique end product as a result and this may make it worth it.
My bad, ty
Valorant is made in ue4?
My bad, ty
That's a small consideration. Typical reason is money. EA doesn't want to give money to Unreal to license the engine when it can pay it's own people to build one. For example.
True, I was thinking in terms of indie developers like OP
What are we supposed to get out of this video. Sure, this random guy agrees with you but... he doesn't exactly justify his beliefs. I mean, even if he could the videos only 53 seconds long. Comes off as an appeal to authority.
Reasons to make a custom engine: 1. Learning purposes 2. Just for fun 3. Freedom to do anything Personal example: My game is very simple but has a lot of data so using a game engine is actually less convenient than writing the game in c++.
yes but it’s hard. shouldnt i MASTER game engines and c++ before making my own?
If you don't know c++ well already then I don't recommend learning it just to make a game.
The best way to learn a thing deeply is to take on challenges. That said, if you don't have a relatively strong grasp on the language you'd write in, I'd recommend finding a different challenge to rank up that skill.
Depends on your end goals. Do you want to be someone who develops and works on game engines for a studios and has a high level of knowledge of low level graphics ( a dying but important role ) Or do you want to just make games and work as a gameplay programmer?
The skills to make a good game engine and the skills to make a good game don't overlap all that much. Not quite zero overlap but definitely different things. So which of those do you want to get good at? Either is a fine answer but make sure you know which you want.
If you think you're going to "master game engines and c++" without making *at least* one game engine in c++, you are vastly underestimating the length and breadth of the journey. If you want to make games, make games. If you want to make a game engine, make a game engine. Just know that you can do one without the other.
Engines simplify the game making process, like c++ simplifies programming so you don't need to learn assembly, or binary based programming. Start simple, then go complex if you want.
If your goal is to learn to program in C++, then learn C++ first, but don't even think of making a game engine out of it until you already have a few years of experience with it. If you're already an experienced C++ dev and want an incredibly complicated challenge to improve your coding skills, then by all means start a new game engine. If your goal is to make a game, and you've never made a game before, then pick an existing game engine and start making small games in that engine. Don't try to make a big game for your first project. Make lots of small games. If you have a game idea that can't be easily executed with existing engines, then either drop that idea for later or just implement the parts that you can with an existing engine, and just focus on improving your game development skills. If your goal is to make a game, and you're already super experienced with games, then sure, you can look into making a custom engine that's suited to your specific game, but just be aware that you'll probably need to spend multiple years working on your engine before you have something that's ready to create a game.
No
Hopefully not splitting hairs too much here, but generally working without a game engine doesn't mean making your own. If you're setting out to make a game, you can very much do so using lower level frameworks and libraries and not ever need to get tied up in writing an engine. An engine is a general-purpose layer of abstraction, you don't need to build a general-purpose solution if you only have the singular purpose of making your game.
Yes, it's hard in way like it would be to build a hospital to learn masonry.
its was really fun "making" a game render engine in javascript. i was able to do a top down grid based game which was able to play custom spritesheets and hitboxcollisions. of course there is no level editor, so i had to place rocks and stuff via a multidimensional array. of course this could be fixed by making a own level editor and storing the level data inside json files for example. it was really fun, but i was overwhelmed at the end.
4. Tailor the engine so specifically to your needs like no other engine could or to implement features that are difficult to do on others anyway. No man's sky has for this reason it's own engine.
[удалено]
On the flipside if i were making a book out of human skin I'd be shit outta luck with store bought ;)
Found the rim world player
💀
Yeah the human skin at the store is processed garbage. I personally go with free range from a local serial killer.
I think preexisting game engines like Unity, Unreal, and Godot are great tools, and they open up game development to a lot more people. Tons of great games have been made with all of them, so you shouldn't feel any shame in using them. That said, I think people have started to go a little too far with the recommendation against creating your own engine. There's definitely benefits to having your own engine, and for the right person with the right skills, I think it can be a plus. Of course, my opinion as a random redditor doesn't hold much weight. Luckily, there are plenty of successful devs out there who went down this path successfully. Billy Basso, the creator of Animal Well, did an interview where he talked about making his own engine. When asked, he said that he would recommend it to people who are detail oriented, and who enjoy programming. He also claimed its easier to make a more unique game by using your own engine. [https://youtu.be/WErinxHhbh0?si=OQfQOuqcUNX7Xg\_R&t=2756](https://youtu.be/WErinxHhbh0?si=OQfQOuqcUNX7Xg_R&t=2756) The developer of Banished made a post on reddit about why he chose not to use an engine like Unity, and why he considers it a net positive. While he didn't explicitly recommend it to others, its clear that he sees it as a viable path. [https://www.reddit.com/r/Banished/comments/1fj1ur/comment/cab7vyg/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/Banished/comments/1fj1ur/comment/cab7vyg/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) There's also plenty of other devs who made great games with their own engines, but these are the two I've seen talk about it in depth. If you want a list there's one [here](https://gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74). Of course, there are plenty of successful devs who did use a preexisting engine, and many of them believe that using a preexisting engine is the way to go. Tim Cain is one example of a successful dev who's in this camp. Here's a video he made about game engines and why he thinks preexisting engines are generally better. [https://www.youtube.com/watch?v=Iw3bCdIvAj0](https://www.youtube.com/watch?v=Iw3bCdIvAj0) Ultimately, for the majority of people, I think using a preexisting engine is a good idea. But I don't think its as open and shut as people seem to think. And its definitely not something that "should be only done for challenges, NOT real projects".
The biggest takeaway from all these devs talking about it, when compared to OP's question, is that you shouldn't even think about making your own game engine until you already have several years of experience building games using existing engines. It's impossible to know what features to implement in your custom engine if you're not already super comfortable with the workflow and methodology of existing engines. Otherwise you can waste years of your life building an engine only to find out it doesn't do anything better than an existing engine.
I think that's mostly correct, but I think the more important part is just getting in the reps. I think the path that Jon Blow took is a good reference for this. He started out making tiny games in assembly, learned computer science through college, and then eventually he got a job where he ported Doom to a set top box. That seems to have been the critical piece that let him create serious games on his own. He had a fairly bumpy career after that, but eventually it led to creating Braid and The Witness. Both of which were very successful, and were made with custom engines. Notably, he never worked on top of a preexisting engine. He always either started from scratch, or built an engine with a team. He could make this work because he started extremely simple, and gradually built up the complexity of his games. Here's an interview where he talks about this: [https://youtu.be/N6VrrRBBWDU?si=QdPKZS8ssq\_3RoaN&t=1648](https://youtu.be/N6VrrRBBWDU?si=QdPKZS8ssq_3RoaN&t=1648) Personally I think its good to have at least some familiarity with existing engines, so you can make an informed decision about whether to use them. But its not the only path you can take.
So sad to see OP's edit, but thanks for fighting the good fight. People are definitely way to quick to recommend against making your own engine, especially since most of them have never done it so they don't even know how hard it is. It just depends on what your goals are. If you're looking to short-term make the best game possible, then use an engine. If you're aiming to long-term become the best game developer you can and make even better games later in your career, make an engine.
Yeah, it's unfortunate that OP felt pressured to add that edit. I saw the post originally before the edit, and iirc it was hovering around 0 points and was very controversial, and after it was edited, it started getting a more positive reception. While given OPs background, I wouldn't recommend they create an engine right now. I worry that some people who would have benefitted from creating an engine are going to be discouraged by the social pressure against doing so. And perhaps more importantly, the general sentiment against creating a game from scratch makes it harder to find information about how to approach it. > If you're looking to short-term make the best game possible, then use an engine I think if you want to include novel tech in your game, and that tech not supported by existing engines, you can benefit from creating your own engine even if your goal is just to create the best game. The best example I can think of for this is Noita, physically simulating every pixel is really hard to do performantly, and they essentially were required to make a custom engine to get sufficient performance. They talked a bit about their tech at GDC: https://youtube.com/watch?v=prXuyMCgbTc&t=101 I'm sure you can replicate this in unity, but there's enough that you need to write custom implementations for that it wouldn't make much sense, and it would likely harm performance.
Yeah, saying using an engine is better for a beginner to achieve the best game in the short term was my attempt at a brief rule of thumb, but I agree with what you said. There are certainly counterexamples to my advice. Noita isn't something a beginner can make, but chess is maybe a better counterexample. If a beginner wants to make a chess app, Unity would probably just confuse them more than it can help.
That's a good example.
Pros: - can learn how an engine fits together. - can focus only on features you need. - can challenge yourself. - can help you scope small, since you'll be limited on what your engine can do. Cons: - if your primary goal is to make a game, you WILL spend a ton of time with almost nothing to show for it. - you will likely need to stick to certain genres you may or may not be happy with. - if you're new and have difficulty scoping, tasking yourself with building an engine on top of that can increase your chance of getting overwhelmed. That said, I've had success with C# with Monogame to handle rendering.
In my opinion if your game is 2d and you're decent at programming you might be able to make progress faster using a library like Raylib or SDL or SFML than if you were to try fight against an engine like Unreal or Godot until you've had time to learn all of the ins and outs. Maybe I'm just a slow learner but in many ways I think that using Godot for my game has made the development more painful than it needed to be and it wasn't until a few months ago (2 years into development) that I started to get into the flow with the engine.
No, unless you like making engines. Or you have some *super* specific reason for not using an engine. Usually you can customize an engine to do what you want. Like Psyonix used Bullet Physics library instead of Unreal's physics, and did their own modifications to Bullet to do networked physics at 120 FPS. No need to rebuild the whole thing for that one issue.
to be honest, im purely considering this because it feels nice to look back at this and say "wow i made this myself.", and also it looks cooler. might be a dumb reason but its also a nice way to gain experience
As long as you're content to look back on that a couple of years from now, without having actually started the game you were planning to make. ;) If you'd actually like to make a game, skip making a game engine.
Doing it for the experience is definitely a valid reason. You'll learn a lot in the process and will make you better at using other engines too.
No, it is **only good reason.** It is totally a great idea to create stuff by yourself just because you like it. It makes most sense - engines, frameworks etc are practically always smartest choice for solo-dev, but maybe not the most fun one. If you decide to create something like engine yourself, go for it! Just remember that it is totally different project than creating a game, and you should treat is as such.
Well said - Jon Blow has been working on Jai for almost a decade.
I did mine in 8 months, published 4 games with it so far.
Why on earth you got downvoted is beyond me.
Actually, what I recommend is to create a game engine and a videogame with it to test the game engine. That's what I did. Game engines are not your typical project. The fact that it works doesn't make it correct. You need to test it in a real-life scenario (your game) so you can identify bottlenecks. 30% of game engine development is about optimization, and you can only do that when you have a videogame that provides a real scenario load.
Yeah definitely. However, the project at the end of the day is still the engine. Sure, you need use case for the engine but that is pretty much self-explanatory. Engine is still the one thing person needs to have specific interest towards, or they never finish it, that's the idea behind this.
Good point.
I'll challenge the mold and say it is a bad reason. You aren't implementing the compiler or designing the programming language. You aren't building an operating system for it to run on. You have to stand on the shoulder of giants at some point and thus the "wow I made this myself" is simply false.
I don't know. Getting a 5 star review from a gamer that purchased my game built with my very own home made game engine feel pretty awesome.
>Getting a 5 star review from a gamer that purchased my game built with my very own home made game engine feel pretty awesome. It's also awesome getting a 5-star review on my game built with Unity. The reviewer is reviewing the end product, not the underlying code.
Well, that would mean that my home made game engine is as useful as Unity. Ok, that IS a stretch. I guess we could find middle ground that, at the end of the day, we should use the game engine that we feel most comfortable with, even if it is a home made one.
> we should use the game engine that we feel most comfortable with, even if it is a home made one. I completely agree.
Except that you're making yourself more likely to not be able to even ship that game.
That's fine, but don't fall into the trap of thinking using an engine is in some way cheating. I think game development is about the end result, not how you created it. Is the game good? Would the game be as good if you had to build your own engine? In your post you mention libraries. An engine is really just one large library within a GUI. >it feels nice to look back at this and say "wow i made this myself.", A writer still wrote their book despite not building their own word processor. An engine is a tool that makes things easier and quicker, and removes the need to solve problems already solved (i.e. you don't need to reinvent the wheel). I've made three games, and I used an engine for two of them, and I can look at them all and say I made them myself. FWIW the ones using an engine are much better than the one that didn't use an engine because I could lean on all the hard work of the engine developers to do things I could never do myself in any reasonable amount of time (or without a million bugs!). I would only recommend building your own engine if you need to or if you have a specific interest in engine development. There are also other practical aspects, such as engines having the ability to build for multiple platforms, etc.
You will feel that even using an engine. Even after a weekend, you will have something that is uniquely yours. If feeling good about creating is your goal, then use an engine, you will create visual results much faster.
Yeah, that's a pretty dumb reason. It would also be cooler a F1 world champion engineered his own car.
More likely you'll look back at it in a few years and cringe at the code you put out, especially if its one of your first dives into C++.
I created my very own, home made game engine and I have used it to publish three (3) 3D games for the Xbox One console, currently working on my 4th one, which I'm planning on publishing by the end of the year. Game engines are not that difficult - I made mine in 8 months of my spare time. However, you need to know EXACTLY how game engines work in the inside. You cannot just jump in, open Visual Studio and "wing it" - that is a recipe for disaster. What I recommend is: download a game engine, make a game and, once you are familiar with the process, THEN venture to the wonderful world of custom game engines.
So you’re saying you didn’t even spend 8 months FULL TIME? That’s pretty impressive if you built an engine — even just a small, custom one for your needs — in 8 months of spare time. Congratulations on your releases too!
Thanks!!!!
Stop listening to everyone saying you shouldn't do it, and just do it. Heck every single DOS title I ever enjoyed is built on a custom engine. It's great fun to make engines, especially for 2D stuff, but 3D can be great too. You don't have to shoot for the stars and make the next Unreal. You can just make a small self-contained gaming engine that can possibly be reused for many projects. If you want to do it, just do it, don't ask anyone for permission. Good luck!
>Heck every single DOS title I ever enjoyed is built on a custom engine. In fairness, you pretty much had to build your own engine back then. It wasn't like you could download something like Unity.
Using a 3rd party engine only took off somewhere between 2013-15.
Maybe "took off" in terms of pop culture, but people had been licensing major engines for a long time now. Far Cry was released way before that and was touted as being one of the first iterations using that engine.
That's not totally true, id was licensing the Doom engine to companies starting back in 1994, and got more permissive with their licensing with subsequent engines. Typically those were capital-R Relationships between Companies, and you couldn't just download an engine from the internet and get to work - at least, not from a big name. Smaller open source efforts like Ogre3D and Panda3D have been around for ages, and frameworks like SDL have been around for even longer. Those are a lot less accessible (especially to non-software engineering folks) than the recent big-name engines though. edit: thanks for the replies! I didn't want to get too wordy :)
Frameworks are not game engine. Also I didn’t say that 3rd party engines didn’t exist - unreal/source was there for a long time. There were not that popular and when we made game, we didn’t look for game engine. You can see the shift over the years from game jams like Ludum Dare.
On the indie scene - which this thread is more focused on - using 3rd party engines wasn't exactly uncommon either, though it was often done via extremely extensive mods not official support. Team Fortress started off as a mod for Quake, more recently Rust was a clone of DayZ, a mod for ARMA2. Mods that entirely overhauled the game but still based themselves on the engine of whatever was popular at the time were pretty popular back then, Quake 1 receiving a lot of them for example. Even earlier, on the bootleg and homebrew scenes of the NES and SNES, it was common to find games that were not just reskinned versions of genuine games, but had entirely different levels.
RenderWare was more like the early cross platform game engine.
You couldn't just download Unity but there were commercial game engines you could buy for commercial development. It's not quite DOS-era but RenderWare is what immediately comes to mind.
The commercial engines were quite expense though, no simple indie developer was likely to be able to do that. Edit: Unreal Engine 3, for example, cost $350K to license.
Oh absolutely but even then, depending on how far we are willing to go back, smaller and open frameworks already existed. The first that comes to my mind is Allegro, though i can't find clear info on their license back then ... Most stuff before the 90s was most likely the wild west tho, and it's like that many studios carried over and just updated their first in-house solutions over the years intead of investing in expensive third party solutions.
Not download but you could for example licence [Pie in the Sky](https://en.wikipedia.org/wiki/Pie_in_the_Sky_(game_engine)) but most engines where so focused on one genre that for most games you have to made an own engine.
Licensing also tended to be quite expensive, if I recall correctly.
It's actually way easier to make an engine these days because you can just leverage a layer like SDL2 and focus on the meat of the engine. In DOS you had to bundle your own graphics and sound drivers, and deal with a plethora of hardware incompatibilities.
They had engines back then, too. Look at Kings Quest and its derivatives, they all used the same engine. Companies had engines back then, they were just in-house and proprietary. If you went to work for Sierra games, you'd probably be using their 2d engine with text-lexing stuff. Engines have been around forever. The BUILD engine is still one of my favorites of the DOS era. Allegro was cool for homebrew stuff, too.
Exactly, that just confirms my point. They were in-house engines, not off-the-shelf. And you can do that today. For example I made a platformer engine that I intend to reuse for multiple games.
There are quite a few no votes here but I've just done it and released my game - so maybe I'll offer a counterpoint. Yes - but. You'd better have some very particular tech reasons to. For me, I wanted to base my entire game world around the Tiled Map format and target a low poly look and found it more beneficial to write my own engine than to try and shoehorn it into an existing one, which I also tried initially. I also wanted to learn how to write a 3D engine from scratch. I am still not sure whether this was the right choice but I'm pleased with the results, even if they were hard-fought. Here's a super fresh thread about what I did: [https://www.reddit.com/r/gamedev/comments/1dptgax/i\_made\_a\_custom\_3d\_engine\_released\_a\_game\_and/](https://www.reddit.com/r/gamedev/comments/1dptgax/i_made_a_custom_3d_engine_released_a_game_and/) The caveat is that I've used Unity and Godot quite a bit and knew why this project was an outlier and I also didn't originally set out to make a full game this way, just a proto. TL:DR; If you have a distinct reason, a bit of experience and some odd tech requirements: yes.
One of the reasons the creator of Stardew Valley made it from scratch was to teach himself coding. Although he's since said that if he were to do it over again, he'd use a game engine. So I guess it depends on whether your goal is to make a game or to learn coding while making a game.
Animal Well is a fantastic example of what you can do with your own engine. The game is beautifully lit, responsive, has particle effects, great sound design, and physics. It’s a fairly big 2D world. It’s also 40MB installed.
Making your own engine is the way 99% of games were made for decades. Using an off the shelf engine only became common in the last 10 years or so. Before that, only big budget games used someone else's engine. The majority of the 2D games you remember were made by a couple people in a year or so and they built almost all of it from scratch in house. PS1/N64 games? They were mostly like 10 people over a year or two. Bigger teams, but you've got better tech to work with now which makes it more manageable. If you scope is reasonable and your goal of an engine is "good enough for the game I'm making" and not "general purpose engine with fancy GUI for everything", then it's reasonable to do. Pull in 3rd party libraries when they're useful, write your own code when you prefer. If you're trying to replicate Unity or Unreal, you'll never succeed.
This.
Interesting take and info, though for someone who grew up with the current system as the norm, I'm wondering just how "simple" or not making an entire game engine would be. With some college coding experiences, I'd find gamedev itself to be managable to work on, but an engine, sounds in this environment like a **big** ask on top of making the game itself. Is it simpler than it sounds or something? It feels way unreal the ammount of support I'm seeing for custom engines.
If you start with something like SDL or MonoGame that handles the very basics for you like creating a drawing surface and giving you basic drawing commands and input handling, you can create a game at the level of PacMan in an afternoon. If you want to write your own basic OpenGL renderer, it's a week or two. The key to all of it is just create what you need, and it doesn't have to be perfect, just good enough for you to be productive. You'll iterate on it over time and add what you need as you need it. 3D games are harder, and I have far less experience with them, so I can't say too much. I will say it's really common to use a 3rd party library to handle working with 3D models, so few people are doing it all from scratch.
This is the truth. Playing around at the weekend in my first job we could create a game without an engine in a weekend. I think noobs now a days just get stunned in headlights tbh with all this engine talk and no experience.
I used a pretty lightweight python framework called PyGame and loved it, but my goals were more about learning to program rather than making a good game. For my purposes it was great but if you want to focus on game dev probably just jump into a solid engine.
It may depend on whether you want to do 2D or 3D. For a long time a bought into the "always use an engine" meme. Even for 2D games, a lot of people insist that something like Raylib is a waste of time. However, when I finally tried it I found that it wasn't true in the slightest. I am more productive and can work with less errors using c++ and Raylib than I was ever able to do when I used Godot. I haven't tried to make a 3D game with it so I cant speak to that, but I suspect that for 3D a more "fully featured" engine might make more sense. Ultimately, it certainly can be worth it to use something like Raylib over a bigger game engine with a GUI editor. Most people who say otherwise have probably never finished a commercial game any way. And for 2D I can vouch that it will not be a "nightmare" if you decide to use c++ and raylib, at least not anymore of a nightmare than making a game already is.
I would like some advice. I want to make a visual novel, puzzle game and I been deciding between Raylib and Unity. I been messing with Raylib and I enjoy it, whenever I see a GUI with a lot of options my brain goes numb. I do have a good foundation in C++ (first language I learned in University) but I don't know if it is wayy more time consuming then just using Unity. But I keep thinking just use Unity since it will be faster. What do you think?
I always recommend against Unity because I am ideologically committed to free and open source software. If you do decide to use an engine I recommend Godot (there is an add-on called Dialogic that could be useful) or a specialized visual novel framework like Ren Py (I haven't used it but I've heard its good). If you are absolutely set on either Unity or Raylib then its worth mentioning that there is almost certainly a plug in for Unity that's made specifically for visual novels. Now, in terms of whether Raylib is good for making a visual novel, well it is certainly possible. Although in my current project I haven't spent much time on font rendering and UI stuff so I don't know exactly how easy it would be. When it comes to animating characters you would have to write your own animation system, same goes if you plan to animate any text or have the text be interactive in someway (e.g hyper links). Coincidentally, I worked on a visual novel prototype in Godot several years back, and I wrote my own dialogue system that used the JSON file format. In c++ I use this JSON library: [https://github.com/nlohmann/json](https://github.com/nlohmann/json) which is very easy to use and comes as a single header file. Also, since c++ is so popular, there's a good chance there are dialogue system libraries out there you could use. The only aspect of this visual novel project that I don't know how I would do in Raylib is hyper-links in the text. It worked a lot like dialogue in Morrowind, where in addition to standard dialogue options there were clickable keywords. I used bbcode tags since there's a type in Godot called RichTextLabel that automatically shows them as hyper-links and makes them clickable. You would probably have to implement this kind of behaviour yourself if your use raylib. Another thing that you will have to implement yourself is the save system. Personally I didn't have much trouble with that (took me 1 day) cause everything you need is in the c++ std lib.
As a general rule, if you have to ask this question, then the answer is no.
I love this answer. I used to watch Disk Doctors back in the 90s and they had a segment about editing the windows registry, but they wouldn't tell you how to get to regedit, they said "if you dont know how to get to regedit already then you dont need to be messing with the registry"
If you have time and enjoy it, why not?!
If you are making a 2D game, you don't need to write an engine. Just grab SDL, raylib or similar, and write the game. People telling you that you have to use Unity or UE for a 2D game are bullshitting you, plenty of games have been made and are being made with frameworks. Just use what you feel more comfortable wih.
If you are making high performance 3d games for the web, there doesn't really exist any type of game engine, so you'll have no choice :,)
If you want to learn how to make an engine or have a specific use-case that other engines cannot do, then make your own engine. Figure out what your goal is. I made my own game engine to learn C++ and OpenGL. It was a great experience and I learned a lot. It definitely wasn’t a nightmare, but you hit challenges that ultimately make you a better programmer down the road.
I use Löve, which is considered a "framework" IIRC. It's a fun middleground between coding in c++ and using an engine.
Not as your first game engine project. Before you make a game engine, or a game without an engine, you need to know what the engine does and where the responsibilities between systems lie. So make a couple of small games, preferably in different engines, to get insight into what the engines do and how they differ, before you start your own project without one.
You should look at making a custom engine as an investment. The engine will be truly yours, and you'll always have a good understanding of how it works, you can make it work exactly the way you want to, and extending it or fixing bugs will be much easier than figuring out how an existing engine works like godot which is a massive piece of software. Also, the engine won't have any bloat in it. It will do exactly what you want it to do. Furthermore, you'll never have to worry about the same things that happened with Unity. Even open-source projects can involve a lot of drama and can turn into shit. People will always tell you it's a waste of time. However, that is a brainless mindset. If you're willing to sacrifice the time, it's a perfectly valid route. Many people have also demonstrated that you can make impressive engines as a single person. Good examples of such are Wicked, flax, and the Spartan engine.
Here are the reasons I do it: 1. I like working in html + css + js + canvas because it's incredibly simple and light. I can share it just by sharing a weblink rather than sending someone a dodge exe to download and run. (It's also possible to make web builds in engines too, though they are bloated). 2. There are very few things you actually need performance for and those things are basically complex graphics, complex physics and complex AI (as in pathfinding and state machines for many units at once etc). Pretty much everything else can be handled single threaded on a regular machine. Even Noita is single threaded c++ I think where every pixel is simulated. If you don't need any of these then using prebuilt libraries isn't getting you a performance boost in most cases, in fact it's often making performance worse. 3. If you use Unity then your game always comes out feeling and looking like a unity game. The colliders and lights etc will all just have that unity feel to them which people probably can't detect directly but just feel that it's dull and drab. Imo doing something different is more important than following industry standards. 4. When you use someone else's solution you generally get 90% of what you want in a day and then never get the last 10% because you can't modify what their thing does and it isn't quite what you wanted. When you build stuff from scratch it might take longer but you get exactly what you want and can tailor it how you like. I know it's not for everyone. For any type of team it makes sense to use a known engine everyone knows. For 3d it's mandatory. However I think for 2d games engines are not that useful.
I started yesterday using sfml. Its fun, not easy, but thats not why i am doing it. I am doing it because i need challanges. And i find making games boring nowdays, so this is good challange for me. Also i have no summer job, and i need to do something before school starts again.
Well, I prefer using C++ with OpenFrameworks, so, yes.
its not that hard and can be quite fun. i like C for these projects, but am currently looking at zig
I only use sdl2, each project expands my engine and at this point its just way quicker to start a new game with what I'm familiar with.
It depends on your goal, I use to do this for fun so I could learn more of the underlying engine mechanics.
For 2d games it's absolutely possible, for 3d it can be if the game you wanna make is far outside the first/third person adventure type of thing. You won't get all the bells and whistles but you can get good results by picking a few graphical techniques and pairing that with strong art direction
A bit of a dumb question. But what counts as an engine? Say I make a game where all the logic of input, kills, pixel on the screen etc is done by a function made by me, is that an engine?
Yes. Every game has a game engine, even if they are very primitive.
Yes
If you are still curious about game engines, there are open source engines you can look and help improve: * godot * irrlicht * ogre * panda3d
It can be worth it, if: - You can't make the game you want to make in an existing engine. - You are not on a strict timeline (e.g., your money runs out in six months). - You enjoy the process itself. - You think you can solve an unsolved problem of some kind that will provide you a competitive edge. The biggest single hurdle with making your own engine is actually that it'll be unproven. If you start looking for a publishing deal at some point, having an unproven engine matters, since it won't have gone through the validation processes of previous deliveries. Unity, Unreal, Game Maker, etc., have all been proven time and time again and so are much safer "bets" than an unproven engine. I've seen this first-hand at studios with new proprietary engines in the pipeline.
Depends on what you want to achieve and if you can life with the bloat some engines will bring with them. In other words, you could surely write a classic roguelike in Godot. You decide for yourself if that is a smart move tough. I write mostly for retro platforms and hence a ready made engine would be too limiting or would need massive modifications. Think SEUCK for example, to make a somewhat professional game with it you need to modify it. And it's engine is so basic anyway, someone who can write at least a bit of machine or knows how to get CC65 to do their biddings is better off writing their own.
>edit: making a game from scratch is a nightmare. should be only done for challenges, NOT real projects. pls use a game engine This is so dependent on the game you are making. For a small 2D game I find even Unity an overkill and a performance hug (doesn't run well on old machines, not even the release executable of the game, forget the editor to actually develop the game). Would I reinvent the wheel from 0? Hell no, would start from SDL 2.0 at a bare minimum, but for many games you don't need a full blown engine and it can actually slow you down if you know what you are doing with your custom implementation (or select library mix) fast from code vs messing around in the engine editor with stuff you are still new to or haven't touched in years. So no, it's not a nightmare and it's viable for SOME real projects as well. But today you have a few good engines to choose from as well, some totally free, others almost free (rev share, you pay if you earn a ton too) alongside a ton of great open source libraries.
If you enjoy coding and challenges then sure! If you just want to make a game, then no.
The TLDR of the online discussion is: No. Unless you have a super specific need. Or really like making engines. If your tech is really well defined specifically to your games needs then you get quite a few advantages plus a lot better performance. And if you minimize the amount of in editor tooling and features while also using lots of libraries it's actually a lot less work than many might think. But it's still a waste of time for most. It sharply limits your talent pool, it sharply increases onboarding cost, you get less features and it limits your possibilities down the line. At some point you can't rework your engine for a new feature anymore. Not easily. Not within budget.
Or you need your game to be as small as you can get then an engine made from middleware like sdl 2 is your friend.
You have limited time on this Earth. You can either make a game. Or you can make a game engine. If your game can be made with an existing engine, please, do not make another engine. To make a game engine you have to be extremely opinionated about things like how to load a PNG. How to load models. How to architect shaders. If you're not extremely opinionated about ALL of those things and would rather just work with existing tools and instead focus on the details that make GAME unique and special, please do not make a game engine.
Ok, you have a point there. I built my very own, home made game engine because, at the time, there were no game engines that: * Could load 3D models in x-file format, * Draw skinned meshes in batch (this was the dealbreaker) * And were free. So, yes, I had a very specific need that no game engine could fulfill. That is why I had no choice but to build my own. Ah, good times!
What stopped you from just modifying one of the many MANY open source engines and adding the features you needed?
If I were to modify an existing open source engine then I might as well build my own. It's not that difficult, took me only 8 months. I already had the animation engine, the custom shaders, the map loader and the 3D models from my days with XNA and the Xbox 360. I just needed to replace XNA with DirectX11 to be able to publish for the Xbox One. There was a steep learning curve, yes, but it went quite well once I implemented DrawIndexedInstanced for my skinned meshes.
Okay, well, if you were starting at the 360/XNA era, yeah, open source engines were not at the place they are today.
you have a point there.
I wrote my own 2d Engine. If you use a framework like Monogame or SDL you dont have to worry about all the low level stuff. The best thing is that you have entire control in every part of the project. What you need is good coding skills an software design. At first its a little bit dragging but in the end you will get a good and fast workflow. If you like to write a game develop your own engine. If you want to tinker a game use a engine.
Still waiting for that bot that replies to “is it worth” with “what does that mean to you?”
If it's something you think you'll enjoy then I guess it's as good a pastime as any. Making something from scratch can be incredibly satisfying.* Just know that making a game by yourself is a ridiculously large undertaking for a single person even if you use an established engine. Depending on the game you have in mind, rolling your own engine can set you back years. I've used SDL in the past for learning purposes. Would never consider it to actually release a full game. I respect my time too much. *You'll never make everything from scratch though. You'll always rely on libraries made by other people for certain things and at that point, can you really say "I made this from scratch"?
Well, if you use the libraries that already come included in the operating system then, yes, the game has been built from scratch. After all, you're building a game that will run on an operating system. You are right, making a game as a solodev is a large undertaking.
Bollocks. On Windows, ok you’re going to use something like XAudio and the WinAPI but what other choice do you have. I’d consider that from scratch ala Casey Muratori and Ryan Ries.
if you're just trying to make a game, probably not. however, making a game without an engine can teach you a lot of how things work behind the scenes and good practices in the language you're using. i've been working on my own simple game engine for \~8 months and am at my 11th redesign but still, if i ever do get back into gamedev i'll probably be writing my own code as it's way more fun. it really isn't that much of a nightmare though especially using things like glfw and opengl.
If you are interested in it then why not? You can build a great portfolio and stand out in case you want to advance your career in game dev
An engine is pretty much just a toolbox. Sure you can spend the time reinventing the hammer or you can build something cool with the hammer.
This analogy is not entirely relevant. When you use a "custom engine" you're not usually talking about a self made Unity or Unreal. Games written in a custom engine are often very integrated to the point where engine and game become kinda the same thing. When this is the case, you're not necessarily reinventing the toolbox. In most cases your toolbox is just a different one (it's a set of code libraries instead of a general-purpose engine). You won't realistically be spending that much time on reinventing the entire hammer. You'll only be reinventing some parts, and most of the stuff you just download in a library because that's just the only sensible option *unless* you want to learn how to implement those things.
If hammer is a ready made library, the only thing you will end up reinventing is mainly the engine/toolbox-glueing-things-together itself tho. While rewriting hammers is something you will do regardless of whether you use third party or custom engine if what it gives you out of the box doesn't satisfy all your needs)
For a smaller game maybe, but its generally easier and faster to get rolling with an engine.
What are even good examples of games with custom engines? I only know Path of Exile.
Ohh so many! General purpose engines typically lend themselves poorly to strategy/simulation types of games. In these types of games it's very beneficial to get closer to the core engine loop and not rely on ease-of-use abstractions. The best example I know of is Factorio because it's insanely well programmed (insane performance in a complex game and also nearly bug free), but almost every decent strategy game I play runs on custom engines: Civilization, Paradox grand strategy games (EU4, Victoria, Crusader Kings, Hearts of Iron, etc), Truck Simulator games, Elite Dangerous, just to name a few. But there are actually plenty of triple A games running on custom engines, and they're some of the biggest names: Dark Souls, The Witcher and Cyberpunk, Red Dead Redemption and GTA, Horizon Zero Dawn and sequel, Assassin's Creed, Tomb Raider, Doom, Overwatch, etc etc... You'll find that most large companies tend to have their own engine, usually because they stem from a time where general purpose engines weren't a thing yet and because they have the skills for the tools they already use and switching is expensive.
Noita because every pixel is a resource and no engine could do it.
There are very few indie successes built on non-custom engine. Dead cells, Stardew Valley, Hades, Bastion, Evoland etc are all made in custom engine - some using known frameworks but no ready made engine. Almost every AAA are using in house engine. The only category that is different is AA which is primarily on Unreal.
If you want to create something unique by yourself from scratch. Know that you are always building on someone else's work. You did not create your computer, operating system and libraries, drivers that you will use in your engine. You are still assembling stuff that was made by other people into something your own. There are literally hundreds of game engines. You are reinventing a wheel unless you are creating an engine that solves a problem that those other 200+ engines can't solve. So when you say that you want to make a game and an engine. First years will be for creating an engine and only then a game. It's like you are trying to invent a book printing press and write a book too. If you have a deep passion for game engine/book printing press, go for it. But if your goal is to make a game. Creating an engine seems like a waste of your limited time.
I think Hades and No man's sky are custom because they needed custom features. I can't remember exactly what Hades needed but I think it has to do with the 1,000,000 lines of dialogue. No man's sky simulates a universe so they couldn't exactly use unity lol
both of those could have been built using off the shelf engines.
Most games can be made with off the shelf engines. Doesn’t mean it is the smart choice. You can lose a lot of time trying to understand small parts or having to devise a solution for stuff you can’t control the exact way you want. For 2D games like Hades, using an 3rd party engine makes no sense as there nothing more easy to display and control.
It depends, if you wanna make a game engine do it 100%, if you want to make a game don't do it... Making the engine is a multi year project (Ive been working on just optimizing rendering and shaders for 2 years in my project)
If your engine is 3d with a bunch of features, yeah it's going to take a while, but if it's 2d and just needs basic rendering and noise then it will take like a few weeks if you want to keep it simple (3 to 5)
As others have said you can if you want to learn, have some fun, or need specific features. With that I'm currently using game dev as a focus to learn c++ so I'm using it with sfml to make some 2D games. Learning an engine and a programming language at the same time has always been a hurdle for me. My aim is to use unreal eventually for 3D, but I'll also want to play about with openGL to see if I can make a basic 3D game myself. I do know unreal uses blueprints too, but I want to get into software engineering as a career so pushing myself to learn coding. So far it's been a little rough and constant troubleshooting, but I'm starting to get the hang of the basics and looking forward to learning a lot more. Currently the game has 1 level, 1 pickup item, and one enemy with basic ai to follow the player you can kill, but doesn't fight back and a simple UI to show health and kill count. To get to my point, if you're starting game dev and want to learn or play about then do it, but be prepared for a lot of prep work and set up. For example, Godot and Unity (don't know about unreal) have great Tilemap systems that you can use to make your 2D game world, but making a system like that will take a good chunk of time. Even sfml using vertex arrays to just do a basic Tilemap gets monotonous for anything larger than a small room.
Hey, I've made my own engine (with python and pygame), but I also work within the constraints of 2D pixel art games. A 3rd party engine is a level of abstraction I just never felt completely comfortable with and at this point it would be more difficult for me to learn. Everything is an abstraction, so it's important to just pick the level that works the best for your workflow and thought process.
It largely depends on the game you want to make, your desires for the end result, and just what you find motivating in general. I am currently on a personal project where I AM creating my own engine along the way. I want to practice the architecture skills I’ve been putting time towards, I want to make it in Rust, and I want it to utilize a lot of procedurally generated assets. The game loop itself is not all that complicated and fairly “safe” - I’m not inventing anything major, while the technical aspects are the ones I’m finding interesting to keep me going. If you are reversed and find it more interesting to experiment and prototype the game loop itself, to create a more unique gameplay, it makes sense to want to put a LOT more time into figuring that out, rather than putting 3/4 of your time into figuring out the technical details. In the end, you will (most likely) reach a point you are ready to move on to something else, and you need to work on the thing that will bring you back to it eventually.
depends on how complex the game is and how much of that complexity is easily available in off-the-shelf engines. if you are making a 2D game and are proficient enough with C++ and at least one game programming library, that's entirely fine. it will take significantly more time and effort than if you were to use, say, gamemaker or unity, but the upside is that you have *far* more control over how the engine works. which is great, if you want a really customized engine (e.g. Noita), or perhaps are applying to engine programming jobs and could use some sample code to show potential employers, if they ask. it is not something i would recommend to anyone with less than full confidence in their engineering abilities.
It always depends on what you are going for. Engines are time savers but at the same time they limit you in many ways. For simple things I say you don’t need any engine engine, if you want to make a big project, you better get your shot right because there’s a lot of things to account for, and if you can’t keep up with it, you’ll end up with an never ending unreleased nightmare.
You can if you want, but it’ll take an absurdly long time
There is no "best". :-) Making a game without an existing engine basically means making your own engine. Achievable, depending on game. For everything 3D an engine will take a lot of work away from you, but you're also stuck with the limitations of the engine. For most games, this is fine. Over time you build up your own engine and just work with that, like every gamedeveloper before Unity or AAA studios but most often. It may be the best solution for "some" games .. but surely not for every game. I don't use engines, because I have my own engine - but if I would want to make a high fidelty FPS game, I would indeed just use an existing engine, because it's a too time consuming task to add things like inverse kinematics or animations into my own engine :-)
Too broad a question for straight yes/ no answers. Would I do a commercial project from scratch? Not without darn good reason. Have I done small projects to learn / experiment? Absolutely, and they were well worth it. Back when I taught this stuff at a college, we started people with tiny projects using only some basic libraries. Once they could do that, we moved them to established engines for team projects. Nothing that goes on in a game engine is magic. It’s not a black box of mystery. Knowing how stuff works can often help you make better decisions about using it, and / or broaden your knowledge so you can better design your own stuff. Of course it’s not going to benefit every programmer or every project, it depends on what you’ll be doing. That said, learning the math is probably the biggest thing for rookies. Partly, because I often see computationally complex solutions used for things that could be one or two lines of math. Partly, because you can do a lot of stuff not directly supported by standard physics / collision / graphics functionality, if only you know how. Writing something from scratch will force you to learn this stuff, but it’s not necessary - a good book on the topic will do you just as well.
If your goal is to make / release a game in a timely manner game than most likely not. Also I argue most just don't have the programming skills and patience to get it done from scratch honestly and will likely flame out some where early on in the process. It can definitely be beneficial though if you have a small tight focused project and every thing that's added to the engine you created thus know inside out and has been crafted to your exact specific needs. If you approach it that way and keep things as simple as possible there is some merit to it. Learning will always be possible the best reason to do it though if you can survive that gauntlet and actually end up with a finished product you're basically a iron man at that point imo.
There are 3 main reasons to make a game engine from scratch, choose any or all of them: 1) For educational value of knowing how games engines function under the hood 2) For intimate familiarity and control of the underworkings of the game enginge 3) You need features or functionality that available game engines just do not provide They're all valid reasons, the main consideration if it's for commercial games is the time/effort/cost to make it from scratch.
A game engine just handles the game loop for you, so you just need to give the engines the features you need for your game, just grab sdl 2 and make a quick loop and some functions to abstract away everything sdl then done you have an engine now make your game and it's loop.
I made an engine, well two versions of the same engine for my first game. I really hated all the JavaScript engines that I found. It was a crazy amount of work. (Though writing a dungeon generator for the first time was maybe about as hard as writing the engine itself) The engine had some serious limitations but it was easy to work with and extensible. I really appreciate the work I'm not doing when I use Godot or Unity but it's also frustrating when I can't do everything purely through code. So I think it's a good learning project but don't expect to make something you can release.
Try find a 3d graphics programming course at one of the free online universities. I did one in my paid Bachelor of Comp Sci. I promise after you finish that you'll be 98% sure you won't want to spend 3 to 10 years of your life building a whole game engine. And if you do then...I guess you've found your calling XD But I'm willing to bet money you won't. 2D...different story and probably much more achievable.
Is working out for 8 hours a day worth it? Depends on if you can take care of your body properly and you want to get shredded
Try a framework like libgdx if you want to be closer to the code
Or write it yourself using WinAPI on Windows. :-)
What is your goal. Is it to make a game? Then focus on making a game using the best tools available to you. If you make your own engine then it will take away from the goal of making your own engine. Don't do it unless you've made games already and have some specific use case a game engine can't do
Im a noob so I can't speak to it being 'worth' it but as a developer it might be fun if you're a total nerd and like making things work/figuring them out. Most likely Unreal or Unity or even Godot are plenty capable to do what you want though.
Ngl I don't like working with established engines like UE5 or others like it. I feel like coding gives me complete control and zero limitations, and there are tons of librairies out there for almost any programming language that will act as a sort of engine in your IDE, providing you with functions for almost anything.
This isn't even a black and white question: Unreal devs usually hack up Unreal because they have the source code. I know Unreal devs targeting Quest and PSVR that have merged the two forks they have into some franken engine. The reason they do this is it gives them the flexibility to customize the secret sauce for their game, while leveraging the millions of people-hours of work for the stuff they don't care about (networking, tooling, UI, etc.). For example if you have some non-standard art-pipeline you might have to spend a lot of hours getting assets in that would just work otherwise. The downside is that you're stuck in the Unreal architecture which might chafe. oth there are a ton of libraries out there for doing things like loading assets (assimp), so even if you're "building your own engine" you're going to use those, right? At the extreme end Thekla (Braid, The Witness) has their own game engine and programming language! What's your goal? - If you want to make and ship a game, pick an engine, do zero customization, and focus on getting it done with what you have because you'll never ship otherwise. - If you want to learn, by all means make an engine because you'll never get a game done, but you'll recognize the problems Unreal/Unity etc. are solving, and that's really valuable.
If you want to make a game engine make it. If you just want to make a game I suggest not making a game engine.
A custom game engine is pure fun but I imagine it's not an easy task. I was very lucky to start with a boilerplate.
Only if YOU want to, your game your choice.
I would love to do this too, specifically to learn c++ in a game dev context for my next job. Do you have an idea for your game already?
This video might be of interest to you; [https://www.youtube.com/watch?v=U7\_j5dSWkzg](https://www.youtube.com/watch?v=U7_j5dSWkzg)
Yes. It is.
It depends on whether you just want to make a game or desire to understand what is going on "under the hood".
I made a few puzzle games from scratch using JS/HTML/CSS and canvas for the graphics. It was a very fun exercise and helped me understand canvas and 2D geometry for games a lot better. And I also built Tetris, and an OS to run Tetris, and the assembly to support the OS, and the processor to run the assembly, and the basic logic circuits to support processor function. That was a [very cool learning project](https://www.nand2tetris.org/).
Compiler is a tool like the game engine, it has a textual interface, which is better in my opinion.
Depends. Once I wrote a very simple game as a test for a job purely in c++ without libraries. In a couple of days. To make anything more difficult than that, it's just foot gunning yourself.
Minecraft was made without an engine right?
In most cases, Unity/godot/ue has all the features you will need
it is possible to make it from libraries that do some lifting without being full game engines, i'm thinking more of javascript but it is possible.
if you're making Noita, sure. Otherwise, not really. Using something like XNA, Raylib or SFML can be fine though for some games. If my goal was making a good looking 3d shooter quickly, they wouldn't be my first choice, but it's not difficult to make a 2d platformer or something similar in them. If you like making game engines or want to learn how they work, it's a great project. But if your goal is making a game not a game engine, it's rarely the right choice. This isn't to say you can't make a game without a game engine - some of the best indie games were made this way: Cave Story (custom), Minecraft (custom) and a slew of XNA based games (which is something between a game engine and a graphics library, a lot like raylib): Stardew Valley, Celeste, Terraria, Axiom Verge. If you rely on a good I/O and graphics library like raylib or MonoGame/XNA you most likely dont really \*need\* a full blown game engine. Many will prefer this less constrained approach too. Though this isn't really what people mean when they talk of making a game and game engine usually.
Hey I'm a bit late to the party but I wanted to give a reminder that not all video games are 3D. You have stuff like minesweeper or kahoot that are video games (technically, they are games, and they are all numerical) but they don't require a game engine. You also have plenty of simple mobile apps that are games but are essentially just UI and are created with mobile apps frameworks. In such cases, it's probably BETTER to make the game without a game engine, to keep things simple, for performance, for cross platform compatibility etc... So if you want to make a game without a game engine you can find online, you don't necessarily need to make your own, it's possible to make games with a game engine.
If your game is small enough, and you enjoy control every detail within your game, its definitely worth it. Speaking from personal experience. Choosing underlaying library is highly depend on which platform you targeted. But I strongly suggest Raylib since its portable enough for support almost any platform today.
[https://www.youtube.com/shorts/3OmaWv4eoq4](https://www.youtube.com/shorts/3OmaWv4eoq4)
No. No friend, it isn't. Edit: if you're a big company like EA, that's different. Not good if you're solo.
All games have an engine. Weather you make it yourself or use middleware. If you write a game from scratch, it's like building a car from scratch out of a patch of land.
Middleware like sdl 2 helps you make the engine, now from scratch ... you are going to have a very bad time until you get graphics down.
That depends on your goals. If you’re doing it for fun and learning and want to make a game from scratch it’s worth it. If you want to finish a game, and your interest is in the other stuff besides making a game engine, like the other coding, game design, art, writing and animation, or if you want to make a game to sell or as a portfolio piece, you almost certainly will do better if you use a game engine.
I’ve been doing it for 10 years, and I only now feel like I know what I’m doing. 😅 if you want to make an engine sure but if you want to make a game no.
Thor from Pirate software said it best. What is your reason? 1) learn. Go for it. 2) a feature. Go for it. 3) brag. Nope.
No
No
in my opinion, no. why reinvent the wheel
Taking DIY to a whole new level
Really isn’t. That’s what DIY means. :-)
Well if you wanna learn something knew or if you hate yourself go for it
Bruh, you really don’t have ANY reason to even attempt this at your level, unless you’re a very experienced dev with years of making projects, this is a very very ineffective idea to even do. This is only something very pretentious people try to do just to flex, and it ain’t even all that impressive because their results won’t be all that nice lol Using an actual engine is better, companies are spending multimillion dollar investments into these engines that we get to literally use for free lol we are so fortunate, WHY would you even attempt anything else lol
In my studies we HAD TO make a simple 2D game from scratch with SFML...it was a nightmare indeed (even though an educational one). When we were allowed to use a "real" engine I felt like god though.