How To Create your own game Engine Like Unreal,Cryengine ,and Unity Engines

Hey Guys on a Totally Unrelated note ...I know its ironic how come I'm asking on how to create an engine on the website of by far the BEST GAME engine's Website..but i just wanted to ask if you guys know of any information of how to create your own Game Engine/SDK that is Similar to Cryengine...I just finished high school and i have started learning C++ and the Java Languages..and I've have started reading Jason Gregory's Game Engine Architecture book so before I head into a College isn't there anyone that knows of any source where I can gain knowledge...so I can begin my own Engine while I Study..(not to say that Unity isn't enough but for my Goals/Or "FUTURE GAME PROJECT" it is crucial to have my own Engine hope you Understand) and if there is anyone who has Programmed AN engine or Specifically This Very Unity How Did you Make it There ,what did you need to do? I want To start this before I start my Game

My Career Goal..Game Programmer/Computer Scientist/Game Designer (of Course)

Please do get Back To Me .....Osiris....
Thanks..

 

This sounds like something @ShadowK could provide some input on.

 

If you need to ask, you don't need to ask

 

BennyBox on YouTube has a great series on creating a game engine. It was great help. He starts in Java, but soon converts to C++. And for anyone saying not to tackle it, don't listen. Now don't try to go create Unreal or Unity by yourself, but making Tetris or Pong from scratch will be an amazing learning experience. You'll have a deeper and better understanding of things under the hood when you start using Unity/Unreal/whatever.

You don't need much tools, simply an IDE and compiler. You build all the rest. Enjoy writing out Matrix and Quaternion libraries

 

Honestly, it's not worth doing and is basically a waste of time unless you specifically aspire to be a low-level engine programmer. I can almost guarantee you could spend 10 years working on it, and it still won't be as good as Unity is today (forget that Unity itself keeps advancing all the while). Not to mention that after that whole time, you still wouldn't have a game completed (only a not-as-good-as-Unity engine).

So, if you want to be a game programmer, program a game. If you want to be a game designer, design a game. Creating an engine is only really interesting sort of as a personal milestone or portfolio piece. It could certainly get you a job, and many big studios still do custom engines for their own reasons. However, as an indie developer it is pointless.

 

First up standardise your spelling and grammar. Understanding and using convention is a very important step in becoming a viable coder. Start with getting forum posts right, then work your way up.

Think very carefully about this before you embark on building your own engine. Chances are whatever you can build on your own will be far less then what the hundreds of engineers at Unity can build. You aren't going to be able to support multiple platforms. Or approach a feature set anywhere near Unity. So consider - Is your valuable time best spent on building an engine? Or does building a framework on top of the engine meet your needs?

 

Start programming the engine. Then keep doing it for about 5..7 years, preferably in team. Then you'll have your own engine, which will be inferior to every other engine on the market.

 

Developing an engine is a big undertaking. You will learn a lot by doing this which will help you immensely in game development. Only downside is, you need a lot of time, a lot.
I think, this book will help you out.
http://www.gameenginebook.com/

 

Don't let the naysayers completely turn you off the idea. There's plenty to learn from it. That being said...

Don't "make an engine". Instead, "make a game". Especially if it's your first. Generalising without prior experience rarely goes well.

Plus, as the book you're reading will tell you, the runtime bits are only a small part of an engine. A huge amount of work is about tools, workflows, and integration with third party stuff. On what experience are you going to base the decisions you make when you design those things? (Do a search for the "Four Stages of Competence". Where do you think you are?)

Making games without an off-the-shelf engine is definitely doable and a great experience. I think any serious games programmer can benefit a lot from doing it at least once. But, when it comes time to get jobs done, and to start projects you actually intend to finish, then its also time to consider what's actually the best tool for the job. And that's where taking advantage of the work of others has real value. The only person who cares about your engine is you.

 

I considered suggesting to read the sourcecode of one of the open source engines from id software to get an overview. Would you say this is a good idea? I won't ever write my own engine, I just wonder if that even would be a good starting point.

 

What are the chances he'll understand any of it though?

 

Here: https://handmadehero.org

He makes the game in C/C++ and it's all from scratch so first he has to make the engine. And making the engine may not be as big of a job as some people are making it out to be. He's made about 240 videos so far and I think he programs for 1 hour in each of them. So that's 240 hours of programming, but he's had a fairly acceptable engine going for a long time. Anyway, 240 hours is "just" 6 weeks of full-time programming if it was your job. I'm sure I've spent more than 240 hours on some of my barely started Unity projects.

I also recommend the project for those of you who are never going to attempt what he's doing. I'm never going to attempt something like that, but it's still very interesting to watch. The guy doing the project is extremely knowledgeable and he's a great speaker and great at teaching.

 

Making an engine for a single game isn't too bad, especially if it's single platform, moreso if its well defined in advance.

Most people who talk of "building an engine" don't mean that though. They mean a generic, reusable toolset, possibly with support for multiple platforms. Those are the things that make it time consuming and, since nobody has unlimited time, ultimately quite challenging.

 

As a 1 man operation the engine probably isn't going to get very far. I think step 1 is find out what part of the engine you can do, then step 2 is put a team together for making the other parts.

If your engine is going to have manual reference counting, 2d graphics, basic audio and basic input (reading keycodes for known devices), then you could probably have an alpha of an engine like that ready in 4 months. I know this because I took a class in college 2 or 3 years ago that involved making a game with c and sdl 1.2. By the end of it, a handful of people had bits of graphics, audio, reference and input management that could be reused.

 

Yeah, I understand, but it's still probably one of the best starting points out there. Especially if your goal is, as OP said, a "FUTURE GAME PROJECT". Making a generic engine to make your own games with is stupid in my opinion. You either use a an existing generic engine or you make a specific engine for your game because the generic engines didn't fit your needs. And later on you can start making your specific engine more generic just like Epic did, I guess, if you're going to make more games with it.

But if you think programming the engine is the fun part then by all means go nuts and make it support anything and everything.

 

There are lower level frameworks/engines than Unity that can be great teaching instruments. When I found SDL it was a "whoa" moment for me and I learned a lot about setting up my own level stacks and entity system. If I remember right handmade hero doesn't even use SDL just goes straight to C and OpenGL, in my opinion that's a layer unnecessarily deep unless you truly are trying to make an engine for a single platform.

 

He's making the project on Windows, but he's said the project will support all the major platforms and that it's written in such a way that it will be easy to port to more platforms. I have never heard of SDL, but I assume it's some kind of library, and Casey, the guy behind Handmade Hero, is actively avoiding libraries because he wants to show how you can do everything yourself, at least to the extent it makes sense. I'm sure that if you follow the project from the start and get intimate with it then you know how to replace certain parts with libraries if you so desire.

But I actually haven't watched him in a long time because I'm waiting for him to get back to the actual game and implementing potentially cool mechanics and whatnot. I'm not that interested in the raw behind the scenes stuff.

I remember that in all the games I tried to make before I started with Unity I got to the point where I needed collision detection and then I gave up, so no low level stuff for me, only design.

 

Yes, the Simple DirectMedia Layer is a library. It officially supports Windows, OS X, Linux, Android and iOS. It was created by Sam Lantinga who used to be the lead software engineer at Blizzard but now works for Valve.

It's a fantastic library for beginners. It's written in C but works with C++ and has bindings to C#, Lua, Python and others.

 

Just learn C++ and then start with opengl or directx

 

That's actually a bad idea. You'll want portable code that will run at least on windows, linux and mac. Doing that yourself will be royal pain.

The best idea is to grab a library or framework that will abstract away platform-specific initialization code and then concentrate on writing the rest of the engine.

I'd suggest to just start with opengl. Learning C++ will take few years.

 

Better yet learn C++ with SDL and OpenGL. Boilerplate code necessary to create and use the OpenGL context in an application is significantly easier using SDL than it is using platform-specific APIs like Win32. Additionally it eases the process of handling audio, input, threads, etc.

 

By curiosity, except for the fun and learning experience why would anyone want to develop his/her own game engines? What features can this give that is not possible in a current game engine? Why spend so much time creating a game engine to make a game instead of use the time to make the game?

I do not get it!

 

More knowledge is always a good thing. Creating your own tools has its advantages and disadvantages. The upside is that you have a lot of control, and you can build your game very performant and efficient, you don't have to build things in that aren't used. Downside is you have to build all the little things that you do need, and maintaining is an ongoing challenge given regular platform changes.

We had about 2(ish) internal engines a few years back. While they were super performant, (still in some way more than Unity for certain things), they were inconstant development, new features often got sidelined for overhauls to support updated devices. Particles, for example, were driven by xml, not exactly an efficient development pipeline. When we finally gave Unity a shot for a production game, within a year we adopted it across the board. Ultimately, it allowed us to put most of our focus directly into the games, and not the engine. Unity is dedicated to keeping all the platforms playing nice, and provides not only a solid base, but extensibility of the editor still allows us to have a very customized pipeline. I have helped build a couple of engines in the past, but these days, I really want to build games.

 

Nope. Might be an understatement, though.

Basic syntax can be learned in a few days. Wrapping your head around the language and its capabilities will take few years. I'd say 3 to 5 years. The language is very complex, and there's popular belief that "nobody on the planet knows entire C++, (including Bjarne Stroustroup)". There's some truth in that belief.

 

Fortunately, as can be seen by how useful and popular it is, you don't need to know the entire language.

 

Maybe if you're using a very small subset of it in extremely limiting conditions without ever bothering to look at it in depth.

Also, it is always possible to write a mess. You know, like "I can program in any language as if it was fortran".

 

In that case, it would be reasonable to ask why the heck are you using C++ to begin with.

The point of C++ is power and control it gives over every aspect of program. This language pays off after you spend a lot of time, develop some sort of discipline, and study it in detail. However, if you, say, throw away 75% of language, you won't benefit from it much, so why bother with it in that case?

 

If you know any language - ie know how to program - then C++ isn't a monster. I was easily able to make a few games on it even publish one of them to appstore before Unity days.

I probably got a basic hang of things in a few days. After a couple of weeks I was able to do anything I wanted. The key thing is - I was probably doing things that weren't the best way to do do them as I had no formal training in it. But it was fun, I was capable and had I stuck with it instead of moving onto Unity, I'd probably have grown my experience project by project.

C++ isn't this fearsome beast any more than C# is and there's plenty of mystery to be had with C# too. TLDR don't panic and internet noise makes things seem more scary than they are.

Engines? I have made a really good one for 2D in C++. I'll talk about that. I had some pretty clear ideas from the get go what I wanted it to do: I wanted it to take care of everything that it could reliably do without human input such as draw call sorting, vbo handling and so on - so all I needed to do was type DrawImage(params...) and it took care of it.

So before leaping into 3D engines, let us see some clear goals. Perhaps you'd like to use DX11 and move some quads around? Should be a suitable starting point.

 

What if you already know java?

 

It's a fantastic library for non beginners too L4D2, FTL, tons of great games made with it. Having the full support of valve behind it is nice too if you plan to deploy to Steam.

 

There's no reason you can't try writing your own engine from scratch, just be aware that, depending on how feature-complete you want it to be, it can be an insane amount of work. You would need to develop a solid understanding of the following:

- Rendering
- Collision detection
- Physics simulation
- Networking
- Audio
- Input

That's a LOT of complex concepts to learn!

Bear in mind also that the process flow needs to be considered, which is easily the hardest part. Drawing a 3D scene is actually quite straight forward, there are loads of tutorials out there ranging from simple rendering to deferred shading and advanced techniques like SSAO and even real-time global illumination.

The problem is how do you integrate that renderer into the wider solution, providing an integrated API that means you can actually build a game? That is where most of your time will be taken up.

 

Err. Where did you get that idea?

Valve have nothing to do with libSDL, last time I checked. l4d2 runs on source engine.

 

The SDL site proclaims loudly and proudly that Valve uses it. That is of course not the same as what is implied by putting "full support" behind something.

It does run on the Source engine. They claim that Source uses SDL for a bunch of its stuff.

Edit: Correction / clarification.

 

It is the other way around.
Engine like source or unreal can use SDL as an abstraction layer between operating system and engine. So, engine runs on it.

...

I checked the web and do not see any mention of SDL being "officially supported" by Valve. It has been used in many games over years, but I've never heard of something like Valve backing the project.

 

If you want to learn opengl, in my opinion this is the best tutorial :

http://learnopengl.com/

 

There's material on the subject all over on the Net. Books on it as well.

I'd suggest defining just a simple base for the beginning such as a collision system or managed rendering system. Of course, it all depends on how low you go. These days I wouldn't drop down lower than something like DirectX or openGL, openAL. All three of those are solid in my experience.

There are many great reasons to do such a project. Ranging from picking up a deeper understanding of what is going on under the hood in something like Unity to being able to develop a system that is more logical and efficient for you to work with.

I'd also like you to consider checking out Monkey X or heck even use Unity itself to make your own engine. You don't need to jump to C++ to do it. The main thing is figuring out what you want your engine to do. Sketch it out. What pieces does it have? Identify dependencies. Define your goals. What HAS to be in your engine and what would be a nice EXTRA to stick in your engine. To me design and clear goals are always the most important thing. You can then implement in anything.

So as you can see in the end it really depends on your goals. If you're after raw graphics bliss then find the best opensource graphics engine and use it. Or use CryEngine or whatever it is that people consider have the best graphics. Then build your own game engine around it.

 

It's so hard i wouldn't even try

 

This is not a good mindset to have in this industry or any other. Going to the moon was a lifelong project for some members of the team while they took on the enormous challenges of reinventing EVERYTHING to be able to operate in space. We would be nowhere if we didn't tackle the hard problems head on.

 

Do you even know how hard it is to create a damn Game engine???? Wrong mindset you say?? Sure, maybe i was wrong let's all encourage him to rack his brains out coming up with an even workable engine. He might be a senior citizen when finished but hey at least he did it.

 

Not very hard to Impossible. The question is of course open ended because "what do you want it to do?"

 

You have a very valid point there, all depends on what he wants to do with it.

 

Don't get me wrong i'm not saying he shouldn't, all i'm saying is that it will be a pretty hard task especially if he's doing it solo. If i were him, i'd spend my time implementing certain features into my games to make them more exciting and stuff. But if he still wannt's to create an engine then i applaud you sir, you have more balls than i do.

 

That is what I meant. L4D2 uses Source. Source in turn uses SDL.

 

Who said he needs to make the next Unreal engine? And yep, I've created my own game engine back a year or ago to get more familiar with deferred rendering techniques. So no, I've never created anything like Unity or Unreal, but there is not reason to say that this guy can't and that it's not his life goal to do such till he is a senior citizen.