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:
ROBLOX is driven by an ever growing membership base of over 300,000 creators who generate an infinite variety of highly immersive experiences.
ReplyDeleteThese experiences range from 3D multiplayer games and contests, to interactive adventures where players can take on new identities imagining what it's like to be a dinosaur, a miner working a mine or an astronaut out in space.