How do you go about beginning to develop something like a game engine?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • How do you go about beginning to develop something like a game engine?

      Hey all,

      What I mean by this question isn't "How do the systems work?" or "How do I initialize the program?", but instead: How do you plan and begin development for a project of this magnitude while still being able to test what you're writing?

      In my attempt to try and understand how to write a game engine, I gave myself the inital task of setting up a basic copy of the GCC4 engine with all the extraneous stuff stripped out using Moden OpenGL 3.3 and SDL 2.0. All I'm looking for is to try and get something like a basic colored cube rendered with a black background. I'm hoping that, over time and using that as a starting point, I can begin to build the other necessary systems from there.

      So, I could implement the renderer, scenegraph, actor, actorcomponents, resource loader, game view, ect. and get all of it running the way it is in GCC4, but I feel as if I'm getting slightly overwhelmed about what order to make things in, and all this time I'm like 700 lines in and I haven't been able to test a single thing because it needs everything to run properly!

      How did Mike and Rez start off this project?
      What did you implement first that you could test?
      Is there a UML diagram of GCC4 that I could look over for some clarity?
      How long was the planning period, and did it involve any UML diagrams?
      Did you write a driver for every subsystem as it was made?


      Thanks for the help.
    • Hey Moogooloo,

      I'm a rookie myself, so I'll try to answer your question, while also hoping to learn from the input of more experienced developers. I started developing my own engine a year ago, as a crash course in game development. It's nowhere near finished (which is why I got GCC4), but I think I can help you.

      My advice is this: Start slow, and start very, very small. I recommend starting with a Pong or Breakout clone. Develop the engine in a way that serves developing the game, and develop the game in a way that forces you to develop the engine. In other words, you'll be working on 2 projects at once. That might sound intimidating, but I like the approach, as it allows you to build parts of your engine that you can immediately implement in your game. Getting one system to work in your engine will lead you to implement that system in the game. In turn, you'll need to add to the game, which will drive you to add to the engine, which will lead you to add to the game, and so on.

      The "ordering" will come to you as you make your game. For example, you may want make the application class first (the part that will eventually handle memory set-up and clean-up). For the most part, the application class should just be a stub that you will expand as you add new systems. But you should definitely include a rudimentary game loop (which you will also tweak as you go along).

      Then, maybe make the renderer. Forget advanced stuff like scenegraphs, home-baked memory managers, etc. for now; that stuff comes later. Begin with basic graphics rendering, like rectangles, circles, triangles. Once that works, maybe add image file loading/texture management (using default C++ memory management -- I'm assuming you're working in C++). Once the engine is capable of drawing objects, develop a crappy pong game that's not even actually a game yet. Just make a program that can draw 2 paddles, a ball, and maybe a background. Developing the crappy pong app will force you to test the graphics rendering in your engine.

      Then, to make the game playable, you'll need some kind of input from the user. You'll need to add input handling to the game engine. Once it's implemented in the engine, you implement input handling in the game. Again, you'll test the engine by way of your game development.

      Once you get user input working, you may want to add collision detection. Once collision detection is up and running, you may want to add some rudimentary AI (or maybe not). After that, you may want to add sound, and then after that.... then, after that.......... I'm glossing over a lot of details, but hopefully the basic idea makes sense. Once you get one system working, add the next.

      Be prepared to spend many, many hours making the pieces of your engine work. Design your systems to be modular and extensible. But at the same time, don't worry about writing "perfect" code. Tweak things as you go along, but also stop tweaking when your code works reliably.

      Hopefully this helps!
    • I did pretty much what Masskonfuzion says when I created my basic game engine. I developed a simple Pong game along side the engine and added to each as I progressed. When I completed the simple Pong game and a very basic engine I added a twist to the game and used that to expand the engine along with the game again.

      I've since moved to Unity and don't know if I'll come back to my engine, but it was a very valuable experience. It helped me understand the pieces and how they fit together much better than before I made it.
    • Alright, before I start answering your specific questions, I'm going to ask one of my own. Why are you building an engine? What is your goal? If you want to make a game, your best bet is to use an existing engine like Unity or Unreal 4. Most game companies that aren't massive use an off-the-shelf game engine these days. Those that don't have a huge amount of tech to draw from. The Sims 4 was written from scratch if you don't include the million or so lines of code in the EA namespace and even the stuff from EA::Sims3 that was brought over. Mass Effect and Dragon Age used the Unreal engine for a while, then switched to Frostbite. It's very, very rare to be at a company where starting a project means opening your first CPP file.

      Now, if your goal is specifically to learn how to build an engine so you can understand how it all works, then that's great and you should go for it. But if your goal is to actually make a game, use another engine. I prefer Unreal 4 to Unity, but a lot of people (including Mike) probably disagree.

      Okay, on to your questions.


      How did Mike and Rez start off this project?

      You'll have to ask Mike about the first edition of the book. I started writing on GCC 3 where I wrote the AI chapter. When #4 was coming along, Mike asked if I'd be willing to do a refresh of it and I countered with an offer to co-author the book. I felt there were several things missing, like the actor/component system. I also felt we could a lot more together. He accepted and we became full partners for GCC 4.

      Then we went about tearing apart the engine. I remember the first thing I did was completely tear down the GCC 1/2/3 model of managing actors, which wasn't great. I wrote the actor/component system and hooked it back in. This was the third or fourth such system I had built throughout my professional career. The hard part wasn't building it, it was making it work with the engine. Those hooks into the engine are often the trickiest, which is why most of our systems are as self-contained as possible.

      The other thing to realize is that no code is sacred. When I was done with the actor system, Mike came in later and modified it to make it work with the editor. This is a very common practice in the industry. And he didn't just go in with a chainsaw, he and I talked on the phone about it and came to an agreement as to how it would work.

      The moral of this story is to try to build self-contained chunks that work by themselves. Build an event system. Build a process system. Build an AI manager. Build an actor system. Build a renderer. Then hook it all together.


      What did you implement first that you could test?

      That's a hard question to answer. It sort of depends on what level you're at. For me, when I built the bleach engine, the very thing I did was build the OS abstraction layer. Then I built a render skinning system so I could segregate Direct3D. Then I built the actual Scene abstraction layer and a SimpleScene implementation to test it. Then I built the core Application & Logic. Then I added multithreading, which is much easier to architect into the beginning. Etc.

      For someone just starting out, I would probably take a bottom-up approach. Build the rendering system. Then build the application/logic layers. This can all fit together as the skeleton of the app. In a totally separate solution, you can build input. Then hook it in. Same with most of the major components. Try to make them as separate as possible (I think you're sensing the theme here).

      Here's the most important part: don't be afraid to make mistakes. You will make a LOT of mistakes and your first engine will probably not be great. It's fine, everyone's first engine is terrible. Even when you have a good engine, you'll end up rewriting it. The first engine I built that really stood the test of time was the Bleach engine. I am now on the Bleach 2.0 and has toyed with scrapping it for Bleach 3.0.


      Is there a UML diagram of GCC4 that I could look over for some clarity?

      Not really. Someone built one a long time ago and it's probably still in the archives somewhere. There are dozens of UML diagrams for my bleach engine. I think very visually so I use them quite a bit.


      How long was the planning period, and did it involve any UML diagrams?

      I honestly don't remember. We had a lot of phone calls talking about what we wanted to do over the course of several months, but it's not like we were spending 40 hours a week on it. We would talk, think, sketch, talk again, and eventually settle on something. Then we'd build it.

      I don't really think in terms of a waterfall method. In other words, there was no real design phase followed by programming phase. For Bleach, I came up with the core architecture and some philosophies I wanted to follow. I wanted certain things to easy, so I worked on ways to make it easy. Then each system had its own design/implementation phase. Sometimes the implementation would fail, so I'd go back to the diagrams and tweak it. That's exactly what's happening now with an NPC schedule AI system I'm building. My initial design/implementation isn't working the way I want, so I'm rebuilding it another way. I think this will work but if it doesn't, I'll go again.


      Did you write a driver for every subsystem as it was made?

      What do you mean by driver here?

      -Rez
    • masskonfuzion wrote:


      @Trinak - I'm also looking at using more professionally-developed engines. But I agree with you that starting from scratch is the way to go, especially when you're starting out.


      Yes and no..... it depends on your goal. If you want to learn data structures & algorithms, you should implement your own version of the STL and use it for one or two projects. Then you should never use it again and just use the STL.

      The same is true for game engines. If you want to learn game engine architecture, build a little 2D or 3D engine and use it to build a couple of projects. You'll learn a lot. Then use Unity or Unreal 4 (or something else of your choice) because those engines will be 100x better than anything you'll ever build on your own. They were made by large teams of people with many more resources (QA, specialists, etc.) than you have.

      -Rez


    • Is there a UML diagram of GCC4 that I could look over for some clarity?

      Not really. Someone built one a long time ago and it's probably still in the archives somewhere. There are dozens of UML diagrams for my bleach engine. I think very visually so I use them quite a bit.


      I completely missed that question when I read through the first post. I created the UML I think Rez is talking about. It should be attached to this post now. There are lots of lines and it can be confusing so if you have any questions on it, feel free to ask. Hopefully it helps more than it confuses.
      Files
    • Hey Moogooloo, I would like to come to your thread and ask some questions to Rez about what he wrote above. I hope you don't mind.

      rezination wrote:

      masskonfuzion wrote:


      @Trinak - I'm also looking at using more professionally-developed engines. But I agree with you that starting from scratch is the way to go, especially when you're starting out.


      Yes and no..... it depends on your goal. If you want to learn data structures & algorithms, you should implement your own version of the STL and use it for one or two projects. Then you should never use it again and just use the STL.

      The same is true for game engines. If you want to learn game engine architecture, build a little 2D or 3D engine and use it to build a couple of projects. You'll learn a lot. Then use Unity or Unreal 4 (or something else of your choice) because those engines will be 100x better than anything you'll ever build on your own. They were made by large teams of people with many more resources (QA, specialists, etc.) than you have.

      -Rez


      Hey Rez, I read what you wrote about learning engine architecture and then move up on better AAA engines. But what if somebody, like me(I'm not sure which way I should go, engine programmer or AI programmer. I was always fascinated about artificial intelligence, but I haven't made a decision yet. You are AI programmer, aren't you? Can you give me some quick look-up on this specialization?), want to be engine programmer? It's a good way to stay on my own engine and upgrade it, bring new features, optimize it, look to other engine(like Unreal or Cryengine) how professionals are doing things what I want to do etc.?
    • Xperience wrote:


      You are AI programmer, aren't you? Can you give me some quick look-up on this specialization?

      Yes, I am an AI programmer. Most recently, I was the lead AI programmer on The Sims 4. Not sure what you mean by look-up though....


      But what if somebody, like me want to be engine programmer? It's a good way to stay on my own engine and upgrade it, bring new features, optimize it, look to other engine(like Unreal or Cryengine) how professionals are doing things what I want to do etc.?

      Yes, if you want to be an engine programmer, you should learn how to write a real game engine. But there's one really important thing to keep in mind: there are very few (if any) junior-level engine programmers. Most junior programmers are generalists and are placed on lower-risk systems, like "leaf" gameplay, UI, or tools. For example, my first programming job in the industry was working on an adventure game where I built some of the minigame puzzles.

      Furthermore, it's very rare that you'll be apart of actually architecting brand new major systems. I've never worked on a game where there was a meeting about how the render thread should talk to the logic thread. That stuff already existed. Now, extending the engine and adding features was something we did all the time, but actually building the core classes? That's pretty rare.

      If you want the experience of what it might be like to walk into a game studio with an existing code-base, Unreal 4 is the way to go. Take that engine and extend it. That's what a real engine programmer does. If you want a simpler task, take GCC4 and extend it. One big benefit of this is that you'll be forced to work in someone else's code, which is a critical skill to have.

      I'm not saying that building your own engine is useless. I have my own engine and I'm pretty happy with it. But it's definitely not representative of being a professional engine programmer.

      -Rez
    • Thanks for quick answer. Sorry about "look-up" it actually doesn't make sense. I meant what should AI programmer know so he can be hired on junior position. But you wrote that junior programmers are generalists so then my question isn't important.
      Yeah, I started with your book and based on principles you and Mike mention in the book I completely wrote my own engine from scratch. It supports everything what GCC4 does and I added some new features. It was a really good experience, but like you said, it's better to move on something bigger :) .
      What do you mean by extending it? You mean take an engine and make games? It's good to add engine, which I made, into my own portfolio?
    • Xperience wrote:


      I meant what should AI programmer know so he can be hired on junior position. But you wrote that junior programmers are generalists so then my question isn't important.

      Sorry, I didn't mean to discourage you here. I'm just saying that you shouldn't have the expectation of being a junior AI programmer because the position is extremely rare. Most AI programmers are mid-level or above. That having been said, one of the junior engineers on The Sims 4 was assigned to my team and got to do a bunch of cool AI stuff, so it does happen.

      If you're interested in AI, you should learn it and prepare for the day when they need someone with that kind of skill. Luck favors the prepared. There are a lot of great AI books out there. One of my favorites is Artificial Intelligence for Games by Ian Millington and John Funge:
      amazon.com/Artificial-Intellig…-Millington/dp/0123747317

      This is a great tour of real game AI techniques and gives you enough to build some really cool stuff. This is usually the book I recommend to people who are interested in AI but it's also written for experienced developers, so it assumes an understanding of data structures and algorithmic complexity.

      If you want something a bit more accessible, I would check out Introduction to Game AI by Neil Kirby:
      amazon.com/Introduction-Game-AI-Neil-Kirby/dp/1598639986/

      This is a fantastic book that is very gentle for beginners.


      Yeah, I started with your book and based on principles you and Mike mention in the book I completely wrote my own engine from scratch. It supports everything what GCC4 does and I added some new features. It was a really good experience, but like you said, it's better to move on something bigger :) .

      Great!


      What do you mean by extending it? You mean take an engine and make games?

      No, I mean extending the engine. There are a huge number of features that GCC is missing. For example, you could write a skeletal animation system. You could refactor the input system so it's not so hard-coded. Personally, I think your time is best spent making a game using an existing engine, even if that engine is the one you built already. Make stuff. Build systems. FINISH something. That's key. That's what I want to see on someone's resume.


      It's good to add engine, which I made, into my own portfolio?

      Of course! Add it to your portfolio.

      -Rez