Watch This Before Working on a Big Game in Unity

And now i have a question, what’s a big game ?

When using a game with a large open world: keep in mind the problems with float imprecision. If your camera gets away more than like 2000 units from the origin, animations can start to flicker and shake. Look up various methods of "origin shifting" to solve that problem by moving the scene dynamically closer to the origin point.

I think one of the biggest hurdles (atleast for me) working with larger projects is to say "no" to things I want to have in the game. There is usually sooo much that I want to add to the game, there is a need to mash all those idéas into doable tasks.

Me making a 2D tic tac toe game: "Ah yes this is relevant to me"

Even five minutes into the video, I could barely believe how densely packed this video is with useful information. Thank you for this great video.

This is quality content. Well done. It's so hard to find topics about big projects with Unity. I hope you continue to share your knowledge.

This is very good content. I would love that video on an Event system.

This video is amazing. On YouTube the most of the videos about Unity are good enough for beginners or intermediate, but there aren't too many videos about these complex topics. I think that if you could create some videos about coding a big game it should be fantastic! Thanks again for the video

Haha nice message on the end! I’m developing a bus simulator for about five years, there are a lot of things that we learn the hard way haha. I abandoned ProBuilder because some updates broke some of my models. Huge games on Unity will suffer from another problem: the lack of precision on world coordinates. After 10km or so from the origin things will get broken, shadows appear blinking, too much jitter on smaller objects etc. The most common solution is moving everything back to keep the camera near the 0,0,0 position. Unreal Engine 4 includes a setting for that, on Unity there is a great open code called “Floating Origin”. But performance may be bad if there are tons of rigidbodies. I can’t wait to test a custom compiled version of Unreal Engine 5 with 64-bit coordinates. But I’m procrastinating on that.

this is really good content, this type of information is kind of hard to find when you encounter an issue related to them, so it's really beneficial to know them before you encounter these issues, just having the knowledge that a solution exists for a certain problem will save a lot of time when you encounter them. game devs really need someone like you, keep it up I think your the next Brackeys

Heyho, Game Dev here for Unity. I do a lot of profiling, and we are using Renderdoc. Its an extremely important tool as you can link it to Unity and grab Frames to analyze. It is similar to the Frame Debugger, but much much more indepth. When we started optimizing we were constantly checking our builds, and with Renderdoc we removed about 1/3 of GPU overhead already. One important topic to mention from GPU sides are shaders, lights, shadows and texture sizes. But thats probably a whole other video as well. Great Job otherwise. Grüße

Interesting topic, good to see more videos about it. I think there are more aspects to it, but these are def. some important ones. The part about the navmesh volumes was awesome, I didn't know about that! There is something for GPU/shader analysing too, the Frame Debugger, where you can step through separate draw calls and such.

Videos like these are legendary and must saves. This talks about many things you don't often hear about in 99% Game Dev videos. And it was purely knowledge, and no bull shit.

I would greatly appreciate another video on the event system you mentioned and a more in-depth look at organizing code for a complex game like that. Excellent video btw.

Thanks for this content! There is a lot of content about making demos and for beginners of Unity, but really lack content like yours about how to build complex systems and larger project! Subscribed!

Thank you for teaching about the material override. I had no idea that was a thing and makes things SO much better than having to create another material instance when I just need a slightly different material.

Thank you for the video! Would absolutely love to see more vids from you

Some real helpful things to consider here, even though I personally don't intend to make a "big" project and instead focus on smaller contained maps myself, keeping all these things in mind is still important and good practice. Will subscribe and look out for more helpful vids from you. :D

This video was such a relieving change of pace, I instantly subscribed.

I guess it goes without saying, but if you want to make a big complicated game, you need to be knowledgeable about game development, intelligent, and experienced. Too many inexperienced developers have big dreams of making big games that will be the next [insert open world game here]. I'm 36 now, and I've been doing this since I was about... 15. At this point in my life, I'm more than just a "jack of all trades, master of none," I know most aspects of game development on a deep level. I'm a jack of all trades and master of many of those trades. When I set out to make a big complicated game, the planning phase is monumentally important. I need to plan what the game looks like structurally before I place a single cube down in Unity. I need to have an idea of what the data will be structured like, I need to figure out if I'm going to use virtual texturing, HDRP, URP, how I'm going to pack my textures, what kind of audio fidelity is needed, what the art style needs to be to suit my aesthetic and performance desires, decide how modern the game will be and how that will affect how many people will be able to run it (will I be making a game with baked lighting? Am I making a very modern game that uses no baked lighting and uses ray tracing features exclusively? Is there a level of dynamism in the game that it even warrants real time lighting?)... There's a lot to consider, and if you're only a couple years into game development you might not even be aware of what questions to ask and what to consider, let alone how to consider it. As far as optimization, in my experience I've come to realize that rather than "don't optimize until you need to," time and experience will teach you what optimizations can be done in all kinds of situations, and you should carry those optimizations into EVERY project you do. Because if you optimize (and PLANNED!) your game all along, you won't have to after it's done which can lead to soul-crushing code refactors and bugs on the tail end of your development.