The basis of Firestorm Engine

So here's the first post on actual engine design, rather than tools and libraries.

Game engines are interesting beasts. They range from game-genre specific, like Source for FPSs or the Starcraft 2 engine for RTSs, to genre neutral like the ubiquitous Unreal Engine and Unity 3D. The thing that these have in common are that they have an editor, that they are extremely data-driven, and that they focus on allowing for the game to be made by non-programmers without ever having to touch a compiler.

The core purpose of my independent study is to understand what all goes into a game engine, why certain choices are made, and what the low and high level structures are. At its highest level, a game has to have certain specific things: Scene Management, Graphics, Input, Collision Detection and Physics, Sound, User Interface, and Scripting. Collision and Physics tend to go hand in hand, even when no physics simulation is required, so I lumped them together. My general task is to take the various libraries for these systems, and glue them together.

For Graphics, I've decided to use OpenGL for now, as Ogre3D is too difficult to set up, and too much of Monogame is being deprecated. SDL will be used to generate the context and to handle Input, the User Interface, and sound since it already has that functionality between itself and its plugins. Collision and Physics will use the well liked Bullet Physics library, as there's a wealth of tutorials available for it. Scene Management is something that is very domain-specific, and so I'll be writing my own scene management system. I'll be working on that as I go.

The core goals for this are: A working, demonstrable game and a working, demonstrable editor. These will help me understand the dual role of engines. To help content creators create the game, and to run the game created.

Task the first is to create the basic engine and then the graphics rendering part. On the engine side, once things are in place, I want to be able to just call Update() on a graphics component or Update() on the graphics system, and have them call the necessary functions under the hood. This is the general model for each system. That's the purpose of using components and entities, rather than making a unique game object class for each kind of game object. This also works for systems because all systems require a startup, update, and shutdown function, as well as a reference back to the main engine. Rather than coding all of these functions into the main engine, they're all treated as their own system object. This makes debugging easier, as this also means that systems can be turned on or off without having to comment out entire sections of code.

I think this is a pretty good place to start. Now to codecodecodecodecode...

References:

• Game Engine Architecture by Jason Gregory
• Real Time Collision Detection by Christer Ericson
• Game Physics Engine Development by Ian Millington
• Real Time Rendering by Tomas Akenine-Moller et al.
• Evolve your Hierarchy: Refactoring your game with components--Cowboy Programming

Ogre3D vs. OpenSceneGraph vs. Irrlicht vs. Panda3D vs. Monogame vs.OpenGL Free for all

So, I need to get this figured out and soon. I am trying to decide what the best option for making a game engine for my independent study course would be. The long and short of it is that Ogre3D is working on my wife's desktop, but I cannot build it for my mac, and I need to be able to work on it wherever/whenever. So here's a grand shootout of different libraries, with all their pros and cons laid out, with my own conclusions about what I am going to use after. Disclaimer: These are basically my combined thoughts from when I tried to work with it, or from DevMaster.net. Your mileage may vary, I'm just trying to aggregate my thoughts into one spot. On with the tables and lists!

Engine:	Ogre3D	OpenSceneGraph	Irrlicht	Panda3D	Monogame	OpenGL
Pros:	Platforms: Big 3, iOS, Android, WebGL Comprehensive, has scene management, resource loading, many built in shaders Abstracts most meshing functions Has extensions for input, GUI, physics Well Documented API, many tutorials, books	Platforms: Big 3, Playstation Scene Management, resource loading Many Plugins	Platforms: Big 3, Xbox Decent Tutorials Easy to get up and running(see below)	Platforms: Big 3 Uses Python Extensively Integrated tools for physics, AI, network, Audio, packaging	Platforms: Most of them Comprehensive Uses C#, my favored language Decently supported Can use OpenGL and DirectX	Complete and total control over my engine Don't have to deal with installing except in the case of physics engine
Cons:	Poorly documented for Mac, so far impossible to set up Must use 1.7 for set up, 1.8 for manual, 1.9 for available downloads, and 1.10 for latest features. Many things for ease of use are simply missing.	Poor Community and Documentation Poor support for procedural generation	Difficult to set up on Mac Poor Documentation	Documentation lacking, especially for c++ Not easily set up on IDEs that are not Visual Studio Because it uses integrated tools and is a full-stack engine, Panda3D needs to be disqualified for my purposes.	Have to make my own WebGL support Not helping me learn better C++, which is part of this exercise Unknown how easy it will be to install BulletSharp	The very definition of going to square one Have to implement all resource loading from scratch Might be too big a scope for a 6 week project

What it really seems to be coming down to is Monogame, OpenGL, or Irrlicht. I guess the game is then to figure out which one takes the least amount of time to install and get 10 rotating cubes on the screen. Once I have that down, I should be able to figure out what the best next step is. I'll update with my results once I get it done.
UPDATE: Ditching Monogame because OpenTK's been abandoned. Ditching Ogre3D because of its documentation. Haven't set up Irrlicht yet, but OpenGL/SDL is seeming like the way to go.

Ogre3D's Documentation Problem

So Ogre3D is a great library/framework/engine. It's Open Source, fairly easy to extend, is used by a few prominent games, one of the only stripped down and scalable rendering engines written in C++ and is ridiculously cross platform. As far as I can tell, it's failry easy to work with once you get going. Ogre3D is absolutely atrocious to get going, though.

The few times I've tried to get it working, the more I've realized that the documentation is written for someone who already knows quite a bit about Ogre, not for a complete beginner to it. A great example is trying to get a basic application set up from the SDK or source.

This adventure began with trying to set up Ogre3D on my mac. Yeah, it didn't work. I tried multiple times to get either the SDK or the source to build, and even with everything set up perfectly, it just wouldn't. Often, it was the tutorials that were out of date, missing crucial steps, or not having clear enough documentation. I abandoned it and switched back to my windows machine.

I've set it up on Windows before, even built from source, so I set out to do that again, having forgotten all the errors I had to work through to get it going again.

The first thing is, when you go to the main tutorial page, you are greeted with a whole bunch of tutorials, and a specific set that seems to be the right set: Basic Tutorials. You click on the first tutorial, and you're told that you need to go complete a prerequisite: setting up an application and setting up the Ogre wiki framework. So you click on setting up an application.

That one is how you set up the application using visual studio, but before you do that, you have to install ogre. So you click on that link to get to the real first one. After working through that first one, then working through the other first one, you run into a bunch of errors with no real explanation.

Among others: The include paths have changed, but neither the files nor the tutorials have been updated to include the new changes. The resource paths have been shuffled around, as well, and the resources.cfg file either was never updated, or the tutorial was never updated to fix it. You get cryptic errors about the fixed function pipeline or missing files, without any indication where the actual error is. Also, if you try to run it with the D3D11 renderer, it won't work. There's no explanation as to why(the tutorial application uses primarily fixed function shaders is the reason).

http://www.ogre3d.org/forums/viewtopic.php?f=1&t=78166 - missing includes and library files? Try this one. Also, add "$(OGRE_HOME)\include\Overlay;" to your include directories (sans quotes).
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=78338 - missing resource files? Try this.
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=81280 - wondering why it won't work in D3D11? Here's a thread that explains it.

So finally, you follow the little bread crumbs, type every little issue into Google, and finally, you get it working. What are you greeted with? This:

Now, it appears to be working, but it bothers me that there's no indication from the "setting up an application" that says what you're supposed to see. There's a suggestion to go set up precompiled headers to optimize your build time (something you really don't need to do at this stage), but not what you're actually supposed to see.

Getting it working is a pain, and it shouldn't be. Looking around at the tutorials, there's three versions of everything. The SDK is at version 1.9 stable and 1.10 development. The manual is at 1.9. Most of the tutorials are 1.7. Why aren't they all updated when the new version comes out? If you want people to use your libraries, then make sure they're well documented. Make sure that the basic stuff to get them going is friendly to new users.

I don't know what the process or infrastructure would be to improve the documentation and getting started tutorials, but I intend to find out. There is no reason for it to be this disjointed. Hopefully as I get this Independent Study going, I can write some tutorials here on the blog, and can get the documentation for this great library/framework/engine improved.

GDC 2015 Report

So this was an interesting bit of news:

But why stop there? Why would that be the only set of news?

So basically, the two best engines in the business are relatively free. The good news coming from GDC 2015 didn't stop there. Valve and Cocos2D also announced their engines going more or less free as well, although Source 2 isn't out yet, and nobody uses Cocos 2D (I jest, and digress).

I should clarify, if only to satisfy my new lawyer friends, that the word relatively is the operative word here. Obviously if you make more than $100,000 in a year, you have to buy Unity 5 Pro, and if you make more than $3000, you have to pay a 5% royalty to Epic Games.

Regardless of these two restrictions, $98,500 and/or $3,000+ minus 5% is still far more money than I have now, for virtually no start-up cost. This is pretty inspiring.

I spend a lot of time trying to remove excuses from myself. I think Unity and Epic Games just did that on a fairly large scale for most of the student and indie developer communities.

Up until this morning, I've been struggling to figure out what I should do with Unreal Engine 4. But I think my answer has come forth in the form of re-doing Project ACIDA. I'll start with getting the top-down controls working, and making some new ships. After that, I can start working on implementing Marching Squares into the engine. This'll give me some experience messing around with the procedural mesh system, and might give me an edge for when I re-implement my Ocean Shader.

This week, I'm hoping to implement a new routine, focusing on pushing myself to newer heights. Among other things, I'm trying to learn:

• Calculus, up through Calculus 3, through the book "Calculus: A Complete Course"
• Computer Graphics through the book "Computer Graphics: Principles and Practice"
• Better C++ by reading through the book "C++ Standard Library: A Tutorial and Reference"
• Game Design using the amazing "Challenges for Game Designers"
• A bunch of fun Unity stuff through Catlike Coding
• The Creation Kit
• Blender

Hopefully, it'll go well. For now, I just want to improve my knowledge and bring myself to the next level of programming. So far, I've managed to hit up every single thing on my list, although the day is young. We'll talk again tomorrow about how I did, and see if this schedule might actually work for me!

--Q