Skip to main content
GameDev.net gamedev.net
🔒 Locked

Basic Game Engine Design - Easy for Everyone, Let us Simplify Here

Started by scrut.hut Jul 14 at 8:20 PM 1 replies 350+ views
Original Post
scrut.hut
scrut.hut

Greetings Everyone,

I went back to the basics. My game engine is not quite as simple as the one I am discussing here. It is not as much an engine as much as a library. But we have to get past that, as you can still make an editor, with tools, and progress from there. The basic architecture is as follows.

Layered Structure

  • Core

  • Domain

  • System

Then you will have the namespaces global, and project.

Everything including global and project would be in a namespace called engine. Each layer would be encapsulated and managed structurally by classed called the same as the layer that contains them. Then in global you would declare the layer classes, and provide a UUID for the project and instance with any other global declarations so that the global scope is clean. Then in project your would have Init, Load, Create, Build (which would call Init / Load / Create in that order), Save, Execute, Release.

Domain would contain all your 3rd party libraries. This includes operating system, graphics, interface, physics, input, sound, and networking. Resolving all API libraries for sure would be a great benefit.

The engine would benefit if you had type definitions with the keyword using or typedef for all primitive types. Also, a result type for a return type for functions for error handling. Serialization would have to be handled of course, and streaming would be built into the Core layer.

This makes construction of an engine much simpler, so I wanted to post to simply it for beginners. What do people think of this simple design.

LorenzoGatti
LorenzoGatti

Considering that you are a student, you should strive to be much more articulate. You mention some inadequately described engine specific constructs (projects, instances, "a UUID for the project and instance"): you should explain better what they are, and what specific benefits they (and the naming guidelines, I suppose for C++, and the overall layered structure) provide.

Some simple and cheap things, like consistent naming conventions, can be done on principle, but actual complications have to be justified by actual needs.

In this kind of architecture discussion, abstract order and elegance are very cheap (e.g. nobody wants their names to be inconsistent or the "core" of their game to depend on third party libraries without a good reason): only nontrivial details and concrete examples are valuable, and they are needed as a starting point for learning and discussion.

For example, I'm tempted to argue that current C++ has precise enough names "for all primitive types" and your code base doesn't need NIH typedefs for them, but maybe you want to follow specific naming conventions with qualifier combinations, to manage the use of platform dependent types, or to do other interesting things with the names of primitive types.

Omae Wa Mou Shindeiru

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.