My biggest regret making my game (not using an engine)

1,960
0
2024-07-16に共有
Get 40% off CodeCrafters + 1 week free! app.codecrafters.io/join?via=BarneyCodes

Wishlist Star Mining Co. on Steam and join the play test: s.team/a/2584800/

Become a member: youtube.com/channel/UCrzKp7Z7PuuuAPXfQnDTdpQ/join

Join the discord: discord.gg/Qnc3jWTeEW


Chapters:
0:00 Intro
1:25 Trap 1
3:05 Trap 2
4:08 Trap 3
5:30 How this has impacted me
7:09 Game dev takes time
7:47 When SHOULD you make an engine?
8:30 CodeCrafters AD
9:13 Try it out!
9:39 Warnings

As a programmer venturing into the world of game dev, it can be incredibly easy to get sucked into making your own engine from scratch. I made this mistake and hopefully by sharing this, even though I'll look like a bit of a gronk, I can help stop you from falling into the same traps that I did!

Follow me:
Twitter: twitter.com/barney_codes
Reddit: www.reddit.com/user/BarneyCodes/

#gamedev #indiedeveloper #gameengine

コメント (19)
  • @beidero
    I think another common trap once you use an engine is to get stuck making tools. Tools are nice to have and you might be able to sell them, but in the end if your goal is to release games then spending time polishing tools does not achieve that goal.
  • "Don't do everything yourself" and "use an engine" aren't synonymous and shouldn't be used this way, IMHO. I usually compare it to cooking. I don't want to build my own stove and cast my own pan, etc. However, the existing engines are like McDonalds kitchen, which is the other extreme. I want to buy a pan, pick between iron cast or Teflon, maybe go for a wok shape, etc... but ultimately I want to setup my own kitchen for the kind of cooking I'll be doing. I really don't want to go into the McDonalds kitchen to try to adapt it for making pasta or pizza. Even the sentiment of "just make a game". Game isn't a painting that you just paint. Game is a piece of software. Games are basically the only software that have this kind of tooling. Every other software is built via normal build processes, not by launching an app, that has a button to make another app. Like, I don't disagree with your sentiment in general, and most of your points, I'm just adding this to point out why engine still might not be the answer.
  • Most voxel games (on the level of Minecraft) even are perfectly suited for game engines; it's only if you want to go super crazy with high fidelity voxels, voxel raytracing, particle physics etc. that an engine might fail you
  • Half way through I found out making the game was like 30% of what I wanted. I want to make my own engine and tools. Because I want to make a publisher. So im just full bar into engine development now. So the idea now is my games will be tech demo's, process refinement, and learning
  • Bro I really hope you finish strong and update us along the way. I need some legitimate dev log content in my life
  • Trap that's been luring me in: "Games with bespoke engines are easier to release updates for because the engine can be modified at any time. i.e. EVE Online"
  • being able to say "I made the game engine from scratch" can be such a good selling point. The fact that a game isn't bound by an engine's limitations is what really makes for unique experiences. But agreed that you'll be spending more time squashing bugs than design and features. Probably a good idea to at least prototype in an engine and then possibly transition to a custom engine when it needs it.
  • as a (not game) developer I understand the urge to do everything on your own, that way you know how everything works and you can always customize, expand and change the behaviour to work with the other parts of the project, you don't rely on other packages and you learn a lot of plain knowledge and Principles behind some things as well as learning and having control over optimizations. Since i've never done stupidly big projects it worked out so far, but I can imagine the scope of the project just balloons out of control quick But on the other other hand, when you do a lot of things custom in the right way, eventually you'll have an ever growing toolset that you can use in other projects too, but then you also need to maintain its functions for all applications which is again a lot of work
  • Well, I've got this on my mind after a few programmer friends asked me about just moving to an engine while the game is considerably done, so I'll join the rant- I'm currently on like... 8 months of gamedev, and while I didn't go for a game engine, I didn't make it from scratch, per se... I'm using a game library, Raylib to be specific. That did help a bunch because all the work for the collision, the shaders etc have been "skipped", but it's still focused on programming, which is my forte, and I still have the flexibility of coding "from scratch", since I can just overload or not include parts of the game library that I'm using. There is a reason for me to do that, and I'll mention it soon. I've not that much finished-game-gamedev experience. I've only some small platforming things and some collision details solved to my name, but I've tagged along platforming gamedevs on bugs and glitches enough to feel comfortable, and that's what's making me comfortable with my choice, most of all. There's also the thing that I have a long-term plan of supporting the game once I have it done, with varying levels of success taken into account. The capability to be able to adjust the "root" level of the physics to deal with pesky corner cases years after the launch is something that I'm sure that I'll need, and the level of optimization is really important for the genre (Platform Fighter, which needs to be CONSISTENTLY at 60 fps), so those are the main reasons I'm picking the game library route. Would I recommend to go for game libraries to just put commercial games out there? Dear GOD no, even with the "skip" that the library gives its still too much effort. Do I regret going the way that I'm going at it? No, at least not yet, and I got a feeling that I won't. Does it take some major concentration and patience to do it? Yes. Every step needs much more preparation before the reward of seeing stuff take place in your screen. It is a huge commitment, and you need to think thoroughly to go through it. If you think it is necessary though, don't be afraid to do it. Just keep in mind, you'll have to appreciate the smaller things much more to keep yourself motivated. But I'm sure it is worth it.
  • You should put visuals of your game in the first seconds of the video, I didn't notice I was looking at one of your videos before I saw the game
  • Looking at the style of game you're making, pixel graphics game, it's understandable that you felt building your own engine was the right path. Maybe Rust and Bevy would be worth including in your possible choices if this is the style of game you want to continue making.
  • While I agree with most of what you are saying, it also gave me the impression that you are underestimating the struggles of using an already made engine. Which isn't to say that your overall message isn't true. I actually agree that making your own engine should be the exception. But the time investment in learning someone else's solution is not negligible, specially when compared to making your own simplified version. I used Unity for years, and I'm too familiar with banging my head against some unity's system, trying to make it work. Weeks later I give up and make my own in an afternoon. This isn't an isolated event. Also not uncommon is updating the engine and breaking the entire project. Also not isolated. Then there's the more pressing problem of not having a very good free and open source solution out there, in my opinion. Licensed engines, like unity will impose extra costs on you as well. Which sucks on a profession that's very hard to make a living on. Anyway, this is a good video. Subscribed. I'm curious to know how your opinion will update after your use one of these engines for your next projects!
  • I don't get that why would anyone think it is a better idea to create an own game engine...
  • 1. Making engines and making frameworks are entirely two different things. 2. Godot is nowhere near enough for practical game developement. 3. Unity is bloated, I don't know a single good game that doesn't lag in comparison with AAA games that don't and actually look better. 4. Unreal Engine is also bloated. Same arguments as with Unity. I remember playing Green Hell and it was... not fun. On my GTX 960 (at that time), Witcher 3 on normal settings was giving me around 80-ish fps and looked good, while green hell looked like a 2011 game at best at settings that gave me at most 60 fps. I understand that people that use these engines usually overlook the underlying processes, techniques and architecture and spiral into the route of bad practices, resulting in a bad player experience. Licensing is another part of all of this. Game engines try to be a magic bullet, solution for all problems, but in reality, you're stuck on reimplementing your own graphics pipeline, your own physics, your own UI, implementing your own game mechanics, and for people that don't - marketplace exists, which add on to the problem by brute-forcing the solution, sometimes trying to fit them all together. IMHO - practical engines/frameworks that solve only one problem (your game) are better for many reasons.