Practical Rendering

I was thoroughly impressed by Practical Rendering and Computation with Direct3D 11 by Jason Zink. Microsoft’s Direct3D API is certainly not for beginners, and neither is this book. But, at the same time, the author does a great job of explaining the material in a way that is approachable. The book assumes you are already comfortable with C++, and doesn’t hold your hand with the syntax. This is great, since you really should have an understanding of C++ before jumping into 3D graphics programming. It’s also not the kind of book that expects you to type in long pages of example code into your computer. In fact, there are not really any complete examples listed in the book at all. Instead the author chooses to highlight specific API calls and explain how different techniques can be implemented using the GPU.

This is in stark contrast to the last DirectX 11 book I read by Frank Luna. Luna’s text was great, don’t get me wrong. But it was very focused on producing functional demos to showcase certain effects (like shadow mapping or ambient occlusion). Instead Zink chooses to go totally knee-deep into the API itself and, as a reader, I came away much more confident that I understood the material. Just as an example, early on in the book there is a 100 page chapter just on resources. Most other tutorials would briefly show how to create a buffer, and then move on other stuff. Not here. In fact, the next 200 pages of the book is just about how the pipeline works. It’s really great, and rare to find such insight.

Don’t be fooled, there is certainly code in these pages, and there are a few examples. The book covers some topics like deferred rendering, multi-threaded graphics, dynamic tessellation, and physics. What I liked about the examples is that only the bare minimum amount of code was shown. Just enough to understand the key concepts without getting bogged down with boiler-plate code. It also made reading along much nicer, without having to feel like you need to get up every 5 minutes and type something in on a PC. Plus, the source code for the examples, and the author’s engine, are available for free online. So no need to type either way.

One thing I really enjoyed was the discussion on DirectCompute and on compute shaders. There are hardly any books covering DirectCompute, so it’s great to see so much space dedicated to the API. I am very interested in using this in my own engine, though it’s difficult to find information on the topic. Practical Rendering and Computation includes several chapters using compute shaders, for example to do image processing (blur). There was also a good amount of space given for tessellation. So if you are at all interested in these specific topics, it’s pretty much a no-brainer to get this book.

One other thing. Mad props to Jason Zink for being available to the community. You’ll find him on the gamedev.net forums, even helping out newbies with their 3D questions. Much respect.

All-in-all, this was quite an eye-opening read. I mean, after reading the Luna book and doing some online tutorials, I thought I knew about DirectX 11. Well, I knew something. But this book went much further than what I had previously seen on the topic. I would even recommend reading this *before* Frank Luna’s book, as I think that would flow a little better. Get the foundation solid, and then start learning how to code specific effects. Anyway, this book comes highly recommended by me if you are attempting to learn Direct3D.

3D Game Programming

Frank Luna’s DirectX series has been the go to book for DirectX development for many years. Although there are other great resources, Luna’s writing is both informative and approachable. The book also covers a broad range of topics from the basic lighting, texturing, and blending, to terrain rendering, normal and displacement mapping, geometry and compute shaders and more. He even tackles some tough topics like shadow mapping and ambient occlusion in a way that is understandable. Overall a lot of good material in a package that’s a bit under 900 pages.

The book assumes you have some knowledge of graphics and C++ programming, though it does go over some of the basics at the beginning. So you don’t need to be a graphics wizard to read this book, but you should at least have a firm grasp of C++ and some idea about 3D mathematics. Though you don’t need previous knowledge of DirectX. I had some experience with DirectX 9 going in, and I was still surprised about some of the changes with DirectX 11. Although the basic concepts are the same (using vertex and index buffers, for example), the code to accomplish things were very different in places.  That said, Luna’s style made even some of the denser code snippets manageable.

Luckily, the included samples did compile with only minor changes to the project properties. I purchased the Kindle e-book, but was able to download the samples from the website. Although I enjoyed the e-book, I will make note that many of the code snippets didn’t look great on the device. This is a common problem with programming books on the Kindle, where code that should be on one line spans multiple lines and makes a mess of the original print formatting. Unfortunately this book is not much better in that regard. Even so, I was still able to follow the code. I just wish more care would be taken with the formatting.

All in all, a great resource and should not be missed if you plan on writing a game or engine with DirectX 11.

3D Game Engine Architecture

In preparation for my 3D game engine, I have been trying to read all I can on 3D engine design and architecture. Although there are some good books out there, it’s very difficult to find a text that will walk you through everything you need to know. That said, 3D Game Engine Architecture: Engineering Real-Time Applications with Wild Magic by David H. Eberly gives it a good attempt.

The book covers the author’s Wild Magic engine, and discusses certain choices he made when developing the engine. It briefly touches on OpenGL, discusses abstracting away platform-specific details, 3D mathematics (and there is a lot of math in this book), an object system, scene-graphs, level of detail, render states, sorting, terrain, animation, collision detection, physics, and more. A lot of ground is covered in less than 800 pages.

However, I found much of the book difficult to follow and still feel like I could have a better picture of the “architecture” of an engine. When I think of “architecture” I think about a broad 500 foot view of a project. I think of flow charts or UML. I expect discussion on how all these disparate elements come together a form a whole. Sadly, that is mostly missing from this book. What the author provides is a good insight into his particular engine, and certain specific aspects of that engine. While this is still a great example to look at, I feel the text could have been more robust in terms of painting the big picture. Some of the things that I found missing were an event system, which seems crucial to an object-oriented engine, or a component architecture, really any type of  structure that allows communication between classes.

Additionally, I found myself getting lost multiple times while reading the book. The author would frequently put in dense mathematical equations and proofs, sometimes spanning multiple pages, and by the end you would be left to wonder what the purpose of the equation even was. I feel like having proofs of equations was not really relevant to the architecture, and surely there are many books on straight math if the reader needed that. Some math is necessary, of course, for a 3D engine but the space could have been used for more important topics.

Not really a jab at the book so much as it is the author’s coding conventions, I really did not like his style. I realize this is somewhat of a holy-war with programmers, but I guess we all have a style that is comfortable for us. Personally I found the author’s style to be really obtuse, and made reading the code snippets more difficult. For example, for a camera’s forward vector, he would use something like:

m_pkFVec

Where “m_” was a member variable, “p” is a pointer, “k” is of a class type, and “FVec” for forward vector. Personally I would use simply:

forwardVector

Just glancing through the code, which one is more apparent to what it is? This really bothered me to no end, but I guess you can chock it up to personal taste.

All-in-all it may sound like I am putting down on this book, but I actually did find it useful in a lot of ways. Certainly if you are aiming to create a 3D game engine from scratch, you will need any and all the help you can get. So yes, still read this book. However, I had much higher expectations and I feel it was a missed opportunity for the author. While it is still a decent resource, this should not be your first stop in engine development.

Game Coding Complete

Finally, I’ve got around to reading (and finishing) Game Coding Complete, and it’s up there on the list of great game development resources. I’d been meaning to read this book for quite some time, but got distracted with DirectX and Windows hooking for use with my 3D driver. Now that I’m back on the 3D engine kick, it seems like a good time to hit this book. Reading through this, I was thoroughly impressed by the content and the writing style. Don’t be discouraged by the lengthy size, this text is well worth the time to read.

The authors, both seasoned game developers, working on the Ultima series and various Sims games, have a lot of collective knowledge and it comes through in the book. There are a lot of snippets and stories about things the went right (or wrong) on the production of some of the games they worked on. I found these insights to be refreshing, and certainly interesting to read about. It also helps to teach people what professional game development is like, and things to expect if you are looking for a job in the industry.

Aside from the stories, there is a lot of topics covered in the book. They go over game loops, component architecture, process system, an event system, 3D math, DirectX, audio, collision and physics, scripting with Lua, AI, a game editor in C#, debugging, version control, multi-threading, etc. Really almost everything you would need to know. They weren’t joking when they said “Complete.” Although the book is long, it’s really amazing what they managed to cram in there. Granted, most topics only get one chapter, which isn’t really enough to fully cover everything. But it’s a great overview on a ton of stuff.

I found the coverage of the event and process system to be every insightful, and I will probably be using a variation of these in my own engine. The event system basically allows different objects to fire events at key points, and then have other objects respond without tight coupling. The process system allows objects to spawn logic loops, that will be updated along with the rest of the engine. So, for example, the player can hit a key to throw a grenade. That would fire an event, which would spawn a grenade with the proper velocity. The grenade itself would have a process, that would count down a few seconds and then explode. At the time of explosion, this could fire another event, which would then cause the audio system to play a sound and the particle engine to create a visual effect. This is a very clean way of handling events and processes, and this is probably the single more useful thing I found in the text.

If you are looking at creating your own game or engine, or just want to see what goes into a commercial title, Game Coding Complete may be one of the best resources to do so. While there is a good amount of C++ code in the book, it is not so much of a “cookbook”, it is more of an overview of architecture. The writing style is casual and friendly, and I really love all the stories told throughout the book. This is a great resource, and should not be missed. My only regret is that I did not read this book sooner. Highly recommended.

So now we should have a good idea of why you’d want to create a 3D engine, and what kind of components make up the engine. Up next we will look at some of the tools and APIs necessary to actually compose the software. Keep in mind that the choices I am making are not necessarily the optimal choices for all situations. In fact, it may not be a good idea to follow this advice depending on what you are planning on doing. For me personally, this is mostly a learning exercise, so I want to mainly build up my skills. This means I may be taking the “scenic route” to (hopefully) completing this 3D game engine. If you want to follow me for the ride, maybe you will learn something too.

Programming Language and IDE

This is a no-brainer right here. I will be using C++ as the language of choice. By and large, C++ is the defacto standard for game development. While there may be some other languages that are becoming more popular on certain platforms (for example, on mobile), in the PC space it’s almost exclusively C++. Since one of the reasons for my building the game engine in the first place is to increase my skill-set, it makes absolute sense to use this language. It will also allow easier integration with different libraries and APIs, especially unique hardware devices which are almost always built for C++. And the performance will be better than some other options. There is no question here.

Specifically, I’d like to use C++11, since that is the latest standard. I learned a bit about the new features in C++ Primer, and I’d like to stay ahead of the curve and build the engine for the future. This also means I should probably be using Microsoft Visual Studio 2012. I think the Express edition should be fine for my needs, which is great because it’s free. Visual Studio is also probably the most popular IDE out there for professional software development, and I see no compelling reason to use any alternative.

Graphics API

For the graphics API, really the core of a 3D engine, there are only really two choices: OpenGL and DirectX. I am not going to try to argue whether one is better than the other, as I’m sure you can accomplish your vision with either. However, I will have to go with DirectX, again mostly because it’s the defacto standard. Nearly every AAA PC game is created with DirectX, and since I am trying to progress in this field I have no choice but to go with DirectX. I already have some experience with DirectX, at least version 9, so it makes more sense than learning OpenGL from scratch. While there is an argument for cross-platform support, this is not a priority for me at this point. Windows accounts for nearly 90% of the desktop market, there’s no good reason to not make this the main target platform. I develop on Windows, most PC gamers use Windows, it just makes sense. I can acknowledge that OS X and Linux are becoming more relevant, but I don’t personally use them so I am not going to go out of my way to code support.

The version I plan on using is DirectX 11. I have no desire to support Windows XP, since by the time I finish this project it will be largely irrelevant. I’d like to support the latest and greatest features, and that is just not happening on DirectX9. There is also a lot of good material on DirectX11, books, tutorials, etc. so I think it will be easier to pick up. Some of the features I am interested in are geometry shaders, compute shaders, and tessellation. So DirectX11 it is.

Audio Library

For sound I am still investigating options, but I am probably going to go with DirectSound. I am already engulfing myself in the Microsoft eco-system, it kind of makes sense. The main reason I chose this was because I am not a big fan of the licenses for other popular options. Some of the APIs I looked at were OpenAL and FMOD. FMOD costs a lot of money so that is off my list. OpenAL looks interesting (and I am still considering it), but I am uneasy about licensing. Basically, I want my 3D game engine to be 100% my ownership and my original code, with no strings attached. For example, if I decide to sell this one day as a commercial engine, I would like to have that option. I don’t want to have to pay anyone, or give them a cut of my profits, or have to release the source code, or any of those things. I’m not attempting to do anything fancy with audio, so I think DirectSound will suffice.

Input Library

Honestly haven’t given this one too much thought, but I could probably make do with the default Windows messaging for mouse and keyboard, and use XInput for game controllers. I also plan to support some more unique controllers like the Razer Hydra, but I would need to integrate their SDK directly anyway. I have used OIS a little, since it comes with OGRE, but I am not sure if this is really needed. Will see how far I can get just with the basic Windows messages for the time being.

Physics Library

Here is another area I am still debating. Previously I was set on using Nvidia PhysX, since I thought that would allow for the best performance. The applications I am aiming to write with this engine are seriously physics intensive. Probably more intensive than has ever been attempted in real-time. So I need a high-performance physics engine. I’d even be willing to dedicate a top of the line Nvidia card (like a GTX 680) just for PhysX alone. Most people would call this overkill, but I ask: is it enough? However, after looking carefully at the PhysX license I started to wonder if this would be the best option. I don’t like how Nvidia has to approve your application, I don’t like having to have logos and splash-screens all over the place, I don’t like the cost for platforms other than Windows. While none of these things are total deal-breakers, they do give me pause for thought. Plus the fact that it won’t run at full speed on AMD hardware is a major turn-off.

Another option is Bullet, which seems to be pretty mature and is free/open-source. They claim that their GPU-accelerated solver is “coming soon” but what does that even mean? It also doesn’t really instill confidence when their website homepage has only been updated twice in the past year. I mean, I’m just one guy and I can manage to post a new blog post at least once a week. You’d expect a whole team to be able to do better. Granted, the software itself appears pretty robust and I like the way it looks. Everything has a solid feel to it and animates well, not “floaty” like you see sometimes. I guess this could come down to the specific parameters, but the Bullet demos did impress me.

I am most interested in fluid dynamics and cloth simulation. I’ve seen demos of both, but I am not sure anything out-of-box does what I need. I am entertaining the idea of rolling my own physics engine, which I think would be a lot of fun. I have written physics engines before, but only in 2D. I know the step to 3D adds complexity, but I think the task is within reason. At least if I wrote it myself I could concentrate on the aspects I need the most, which seem lacking in most current video games. Since I am looking for the best performance, I’d like to code this on the GPU. I also want something that runs equally on Nvidia or AMD hardware, so I am looking squarely at DirectCompute. I know I am probably looking like the biggest Microsoft fanboy right now, but I don’t think that’s a bad thing. Microsoft has done a great service by creating all these awesome APIs and releasing them for free to developers. I do realize I am opening a can of worms with a custom physics engine, but I am really liking the idea of not using any 3rd party libraries (aside from what Microsoft provides).

Everything Else

A 3D game engine does include a lot more stuff than you get just cobbling together a few libraries, so I don’t want to gloss over this too much.  Of course, I still need to architect the structure of the engine, but that’s a given. Understandably there may be other small libraries I’d like to integrate, like for decompressing a zip file or whatever. So I am open to using external code provided I can still retain 100% ownership of the product. Though since this is mainly a learning exercise anyway, I’d like to do as much as I can myself. I can already tell that most people (maybe you) would think this is an impossible task for one person. You may be right. Maybe after doing some tests I will find that I’ll need to license an audio engine, or that I’m in over my head coding a custom physics engine. Sure, that’s fine. But even in trying and failing I think I would have learned more than never having tried at all.

Last time I recommended some good books for engine creation. Today I will talk a little bit more about what an engine actually is, since it’s rather silly to try to create something that is undefined. What I am defining a 3D game engine as is “a framework or set of tools that abstracts complexity and enables creation of real-time 3D experiences.”  It’s important that it deals with “a framework or set of tools” and not just a single tool. Obviously artists might use an image editor to create a texture, but we wouldn’t consider Photoshop to be part of a game engine. However we may have a standalone tool, let’s say a light-mapper, that works in conjunction with the 3D engine. In this case, we may count the tool as part of the engine. One key point is that the 3D game engine should “abstract complexity” and allow for more rapid development than otherwise possible. The whole point of using a game engine in the first place is to make common actions easier and quicker to do. It’s also important that you are not limited to creating games, although I would still call it a “game engine” since that is common terminology. The same engine could be used for virtual reality, or simulations, or data visualizations, or any number of non-gaming applications. The engine could even be used for non-interactive experiences (for example: machinima) but it would still need to be real-time in nature. Clearly a video player would not constitute an engine. So now that we have a clear, if not somewhat broad, definition of an engine, whats next?

Well a lot of people (including myself) would like to say they created their 3D game engine “from scratch.” Now what does that mean exactly? Does it mean not using any 3rd party libraries? How far will you go with this is? I mean, does the C++ standard library apply here? Are you going to re-implement the STL? Write your own C compiler? Clearly this is too far. Unless you are creating your own programming language and compiler in straight machine-code, then you are going to be using someone else’s work somehow. There is no shame here. To make a good high-level application, like a video game, you will need to use a variety of low-level functions that you may not want to code all from scratch. This is a given. Especially if you actually want to have a working application finished within your life-time. Obviously you would be using an API like OpenGL or DirectX. There’s no glory in re-inventing the wheel here. While you could write your own physics engine (and some developers do), there are a number of decent solutions available. There also probably isn’t a big need to write your own PNG decompressor. That’s fine, but I still haven’t explained what “from scratch” means. What I would call “from scratch” is something that started as a blank text file, and that was slowly built up over time to have more features. I think this is fair. Even if 3rd party libraries were integrated, I don’t think this takes away from your original code. It’s still “your creation.”

So I defined my 3D game engine as a “framework,” but what exactly does that entail? Though not exhaustive, some of the things I would expect from this engine are:

  • Input processing. Reading state from keyboard, mouse, controller, etc. and exposing a high-level interface (like an action-map).
  • A graphical representation of a 3D environment. For example, to be able to set positions and orientations of objects in space, and draw them onto the screen.
  • A audio system. Being able to play ambient background music, or one-off sound effects.
  • A math library for 3D gaming: vector, matrix, quaternion, collision, intersection, AABB, etc.
  • An animation and physics system. The ability to animate objects, either due to dynamic interaction or through scripted animation.
  • An event system, which would allow entities to fire events and other entities to listen for events and respond accordingly.
  • File management, loading resources, streaming assets, saving configuration, etc.
  • A scripting system, that allows for rapid iteration and prototyping without recompiling the application.
  • An editor that simplifies scene creation, connecting scripts, parameter setting, asset management and other authoring actions.
  • A state machine, that lets objects to have different states. Useful for GUI, AI, etc.
  • Possibly networking, if the game is multiplayer.

While this list is not going to include every single element of a 3D game engine, I think I have touched on the most important sub-systems of the framework. Certainly, this is no small task. I realize that there is a long road ahead of me (and I hope you do too, since you’re reading this). I’m aiming to spend about 2 years to make this happen. Granted, I hope to have a MVP (minimum viable product) up and running in a much shorter time-frame, lets say 6 months. But I understand that these things can take time, especially for a lone coder. But I think it will happen. No, it will happen. I will make it happen.

With the first part of this series I have listed a few motivating reasons for developing a 3D game engine in the first place. In this next part I will go deeper into some of the research I have been doing for amassing the skills I feel are necessary to actually complete a project like this. As I have mentioned, one of the core reasons I am working on this engine is for knowledge building and personal development. Researching computer graphics plays a huge part in this. So I’d like to share some of the books I have been reading in the past year or so in preparation for creating my dream engine.

Real-Time Rendering

Real-Time Rendering, Third Edition (Tomas Akenine-Moller, et al): This is one of the best books I have read so far on real-time graphics for gaming. There are a lot of equations, but they are usually explained well. However, there is not a lot of code here to just straight copy-and-paste. It’s not a cookbook. It’s really more of a 1000 foot view of gaming and real-time technology. It talks about all the different lighting and shading models currently used, discusses texturing, collision detection, intersection methods, image-based effects, 3D math for gaming, etc. Really a great overview of the types of things a 3D engine has to handle. As mentioned, it’s not a cookbook. There is very little code, if at all. But I found this to give a helpful glance at a lot of topics of interest, of course with sources to find more detailed information. Highly recommended.

GamEngineArch

Game Engine Architecture (Jason Gregory): This is another amazing text. It talks about all the things that go into building a professional game and game engine. So 3D math is covered, as well as version control tools, fundamentals of coding in C++ (with cool tricks like memory alignment), main loops for rendering and game logic, debugging, character animation, collision and physics, and more. I found this book very insightful and actually made some of the topics listed a lot more understandable. I was especially surprised by some examples of main loops, as they were a lot more straight-forward than I previously thought. If you are attempting to code your own engine, this book should certainly be on the list.

Game Coding Complete

Game Coding Complete, Fourth Edition (Mike McShaffry): All I can say about this book is “Wow!”. There is an unbelievable amount of knowledge in these pages. This is the book I am currently reading, about 25% through so far, and I have already learned a bunch. This is another 1000 foot view, but they ground it with some really useful snippets of code. They give examples of different main/game loops, actor and component architecture, an event system, loading and caching resources, DirectX, scripting in LUA, collision, physics, creating an editor in C#, even network programming. This book is amazing! I’m not even finished yet and already I feel like I have learned so much. This is a must read.

3D Math Primer

3D Math Primer for Graphics and Game Development, 2nd Edition (Fletcher Dunn): I actually read the first edition, but I’m sure the updated text is just as good or better. It’s a book on 3D math for games. Certainly this is the type of book that’s great for foundation learning. Creating a good 3D engine will require a deep understanding of this type of math (mostly linear algebra) and this is a great book to get you started. Even though a lot of the equations are dense, I found the writing style to be approachable. It talks about all the stuff you would expect: vectors, matrices, orientation, transformations, etc. I would also recommend this book.

3D Game Programming

Introduction to 3D Game Programming with DirectX 11 (Frank Luna): This is one for my wishlist. I have read the older edition on DirectX 9.0c, but haven’t got around to this latest version. However, the series is one of the most recommended and highest rated books on the DirectX API. Luna’s writting style is very clear, and there is a lot of ground covered in the book. 3D math, drawing basic primatives,  texture mapping, lighting, shadowing, normal/parallax mapping, ambient occlusion, etc. I like the little things that make the demo apps very polished (like being able to switch between windowed and full-screen with the touch of a button). If you plan to use the DirectX API for your engine, then this book is an absolute must.

C++ Primer

C++ Primer (5th Edition) (Stanley B. Lippman): Although I have been learning and working with C++ for years, I read this book recently and ended up learning a lot. Keep in mind this book covers the new C++11 standard, though most of the discussion still applies to the previous standard. This is, hands down, the most comprehensive book I’ve seen on C++. Most books teach you the basics, but fail to explain the intricacies of the language. Not here. The author goes deep and shows you everything you need to know (and more). I also liked that he kept the code samples short and to the point. There is not even one sample that you are expected to type in and test. If there was, the book would probably be twice as long (and it’s already pretty long at 1000+ pages). Rather the author chose to highlight relevant structures and algorithms with as little code possible. I found this method to be very effective. If you are just starting out with C++ then I would recommend reading C++ Primer Plus first. However, if you already know some C++ and just want to brush up on your skills, this is a great resource.

Of course, I’m not going to list every book I’ve ever read on programming. These are just a few recent ones that I found useful. I will continue to post links to new books and other material that help me get closer to completing my 3D game engine. Even reading these books, there is still a lot of knowledge that can only be found by doing, and I hope future posts in this series will address that. After I get a better idea of the architecture of the engine, I can post some simple samples for review and for performance testing. Again, this is a learning process for me, so I would love to hear feedback from the community of this. Don’t be shy.

Unity 3x Essentials

I’ve been keeping tabs on Unity since back when it was a Mac only thing, and it sure has come a long way over the years. Even though I have downloaded and toyed with the program before, I hadn’t took the time to read a proper book on the engine. Now that I am having to work with Unity more for the job, I figured it was a good time to brush up on some knowledge. Although there are tons of Unity books out there, Unity 3.x Game Development Essentials seemed to have good reviews, and the price was right (only $16 for the Kindle e-book).

The book basically walks you through creating a dirt simple “game”, that you build up throughout the reading. Only the first chapter has a standalone demo to get your feet wet, the rest of the book is all one project. I found this format to work nicely, as you can concentrate on one aspect of the game design during each chapter but feel more accomplished as you built up the game. It covers creating a terrain, setting up a player controller, importing models, creating a GUI, collision detection, basic scripting to trigger events, and basically everything you would need for a simple demo. Although the game you build will not win any awards, it is functional and teaches some fundamental concepts.

What I will say is that the author did a bang-up job with the source code listings. There are tons of code snippets throughout the book and I found only one, yes one, mistake out of the whole thing. And, even then, it was a minor variable misnaming. Nothing major. This was a refreshing surprise, as many programming books are riddled with errors and non-compiling code. Bravo for that.

In general, though, I found this to be a very approachable book, even for a beginner. Of course, development experience doesn’t hurt, but it’s really not required for this text. The author clearly explains everything that is taught in the book and only at the end is some code glossed over (since it was already covered). I also liked how all the code is shown in both C# and Javascript, so the choice of language is up to the reader. Very nice.

The greatest part, I would say, is how far you can go with Unity itself in little time. I read this book in just one week and feel like I have covered more ground than I have with other engines spending *far* more time learning. So that just goes to show how solid the engine is. It’s not so much about the graphics of the engine, as it doesn’t really look any better than anything else out there. However the editor is very functional and very efficient. Especially nice is how you can create references to objects in the editor, greatly simplifying communication between different components. Overall I found it to be a great learning experience.

If you are just starting out with game development then this book is a great resource for learning the Unity engine. If you are already a developer but not familiar with Unity, this is also a great text. Granted, its not a very advanced book, so if you are already using Unity you can probably pass on it. That said, the book was very affordable and well worth the money in my opinion.

This is the first part in, what I hope to be, a long running series of articles about creating a 3D game engine. Just to be completely honest, I have never created a 3D engine before. Granted, I have worked on many games but usually in the casual and social space (read: 2D). However, I do have some years experience using other people’s 3D engines as a hobbyist. So I’m not a complete noob, far from it. But this is very much a learning process for me. I hope to detail this process, mistakes and all, in a series of articles. At the end, hopefully I will have a fully functional 3D game engine. In the process, I will log basically all the steps needed to create said engine. Maybe eventually these notes could be the basis of a book. Who knows? I think the information will be valuable, and I hope it will prove helpful to other people walking this path.

So the big question is: why would you want to create yet another 3D engine?

That is actually a good question. Before you embark on a (potentially long) journey of creating your own engine, you probably want a good reason to do so. There are tons of engines out there, some even free, and many of them will be suitable for a variety of projects. This is true. There is also the advice that says “make games, not engines.” This is also sound advice for most people. Especially if you are on a deadline from school or a client, it makes absolutely no sense to waste time building an engine. Just make the game, and finish the project. Get your grade, or get paid.

For me, however, I’d like to learn exactly what goes into a 3D engine, as I feel this knowledge will be very useful. Even if I, ultimately, end up using a pre-existing engine. So knowledge is a big part of this. I don’t mind if my engine takes years to complete. I don’t expect it to compete with the big commercial engines. I just want something I can use for my own little projects and demos, and that I have absolute full control over.

Another aspect is limitation with current options. Many of these “all-in-one” game engines will get you 90% of the way there but you will struggle and twist the engine to get that last 10%. In some cases, you will encounter show-stopping bugs that you just have no way of fixing without the source code. In other cases it just means you have to “dial back” your vision to get things working. Some engines have restrictive licenses, or complex revenue sharing models that I’d like to avoid. Some of them are just too darn expensive (I guess this is a financial limitation more than anything). Some 3D engines look great, at first, but don’t include the types of things you would need to complete a game (like a proper level editor). There are lots of reasons to be dissatisfied with the popular options out there.

More concretely, I’d like to explore how using virtual reality can aid in the game development process. So some features that I consider requirements simply aren’t available today. For example, full stereoscopic 3D rendering not only in-game, but also inside the editor. Supporting 6DOF (degrees of freedom) motion controllers to place and orient objects, again, in the editor. Intuitive 3D model editing and texturing, no external content creation tool needed. Motion capture tools built straight into the engine, so you could literally animate a character in real-time as you play the game and save those animations out. I know this all sounds very “blue sky” but these are things within the realm of possibility. I believe it can be done, and this is a motivating factor for me. Maybe your vision is different, but I think this series could be helpful none-the-less.

I’d really love feedback on how I’m doing, or topics that you might be interested to have me cover. Remember, this is as much a learning experience for me as it will be for you. Surely mistakes will be made, just post a comment and correct me, or post a fix for the problem. I really have high hopes for this series, and I want this to be as much of an interactive experience as possible. So keep reading, have fun, and let me know what you think. Thanks.