next »

[BlueSweatshirt]

I'm currently building a C++ engine, with the use of OpenGL and OpenAL mainly.(for cross-platform and freedom of royalties)

Where is some good documentation for designing an engine? Or likewise, does anyone here have any helpful advice on how I should?

So far I only have basic engine functionality planned out:
Image support(PNG, BMP, GIF(?) loading)
Sound support(WAV, OGG Vorbis loading)
Keyboard support
Timer support
Small vector-based math extension
3D rendering support(not sure how much I'm going to put 'behind the hood' yet)
Joystick support(maybe, eventual addition)
Achievement system support(entirely unnecessary, but it'll save time in my long run if I want them)
Instance manager classes(vector and map containers available)
--Including image and sound resource managing classes.

What else is there?
Everything I'm making has an abstraction layer to the API-specific code, so much of this functionality could be easily ported to other 3D or sound APIs, etc.

Right now I'm currently using a function layout for my project very similar to how it's done in XNA:

Code:

namespace Z4R
{
    class Game
    {
        private:
        //Initialize all game-wide data here
        resource_manager gfxResourceContext;

        public:
        void Init()
        {
            //Place user created code here
        }

        void Logic()
        {
            //Place all logic here
        }

        void Draw()
        {
            //Place all draw code here
        }

        void CleanUp()
        {
            //Place all code for cleaning up resources, after the process is terminated.
        }
    };
}

[Tycho Brahe]

Consider including something like box2d (if you're allowed by the licence) as I've found a lot of "pre-built" engines like xna or flixel have little or crappy physics/collision.

alternatively if you're going 3d something like bullet would be handy...

[Snakey]

My recommendations are:

a) Unless you actually use other platforms then you may want to consider cross platform support. Certainly you can make the decision to decide what libraries to use, but just remember that if you don't actually understand the platforms that you want to port to, then your own code is likely to contain code which won't be cross platform compatible any ways. Secondly, if you don't use those platforms how do you expect to test code on them? So for now, just concentrate on a single platform (Say Windows for the PC) and then either learn how to get it onto the other platforms later or pay someone to do it for you.

b) A lot of the things you have planned out are just basic necessities of graphics, sounds and input. But there doesn't seem to be much in the way of handling interactions between entities (physics).

c) Tool sets, will you have any?

The layout you have at the bottom is pretty simplistic, but it depends on the types of games you plan to support. At the moment, a simple arcade game could probably use that sort of layout.

As I've been told before, in order to make a good, decent game engine, there needs to be case examples, otherwise all you're really doing is making a tech demo.

[Tycho Brahe]

I'd agree with most of that although I would argue that from the ops specs I would argue that what he's thinking more of is a framework and would thus invalidate some of your structure concerns.

I would reccommend some sort of object/class for game entitys and to wrap physics bodies and functions, kinda like flixel does.

I've already written/got over most of the  problems with this kind of thing, so I'd be happy to help out or submit code to this if you want. 

[David Pittman]

Here's some rambling thoughts on the subject. Some of this might not be appropriate to your situation because I wasn't really sure about what you're trying to accomplish. Are you making a game with this? Are you releasing this for other developers to use? Is this a 2D or 3D engine? So I'm assuming 3D action game engine, because that's what I'm most familiar with.

If you're going to actually make games with this, some sort of entity system is in order. How will you manage destruction of entities? Will entities directly hold pointers to each other, and how will you ensure that they don't end up with dangling pointers? Will you use an inheritance hierarchy or a component model? (And if you're not going to do any of this and are simply making a rendering framework, I'd highly recommend stopping and reconsidering, because an engine without an application is an engine that by definition hasn't been battle-tested, and who wants to use that?)

Physics. Not necessarily full Havok-style rigid body dynamics, but at least collision detection (entity-entity and entity-world). Again, this is absolutely essential for just about every kind of game, so whether you're making a game with this engine or you're expecting someone else to, the work will need to be done; it might as well be done once, by you, in a manner consistent with the rest of the engine.

AI is very game-specific, but certain aspects like pathfinding and path network generation are ideal for inclusion in an engine if you can at least make the assumption that you're making an action-y game engine. If the engine is meant to support everything from shmups to platformers to football, there's obviously very little common ground. Likewise, the core elements of an AI decision system could be included, but without any specific behaviors implemented with them.

Graphics involves a lot more than just loading images and meshes. An engine is more than just plugging content into an API. How will you manage objects in your scene to maintain a playable framerate? (That goes for collision detection, too.) You'll probably want some kind of spatial partitioning to minimize what gets rendered. One topic which I've seen very little discussion on but which was a thorn in my side on an older engine is managing draw passes. Say you need to render your objects once from a light's camera for your shadow map buffer and then again from the player's camera; how do you define those render passes, and how do you define which objects belong to which passes? Beyond just rendering, you need a good system for animations: how to define them, how to play them, how to blend them if you're doing skeletal animation, etc. And shaders and materials are a whole post in themselves.

Likewise, audio is a lot more than just playing sounds. Talk with an audio designer and find out what they want. You'll probably want things like the ability to duck categories of sounds (e.g., turn down the background music and sound effects while a character is talking). Effects aren't always necessary, but reverb is pretty standard.

A good content pipeline is a huge thing that I think a lot of people initially overlook. How will content be authored? Will you need custom tools like a level editor, or can you make do with existing tools? I build levels for my engine in Blender; I know of pro studios that use Max. Heck, Excel and even Notepad can be acceptable tools for some purposes, but easier and better tools will enable easier and better content creation. Are you targeting only yourself or do you expect others to use this engine? (If the answer is the latter, and you're primarily a programmer and not an artist or designer, do not make any assumptions about what is or is not an acceptable tool. Ask someone who will actually use the tool every hour of every day.)

Further down the content pipeline: What sort of preprocessing is needed? Will you load raw images at runtime or bake them into DDS files? Will you distribute games on this engine with loose content files (lame!) or pack it all up neatly in compressed packages? How will these decisions affect development of the game (i.e., can you easily support loading both raw and baked/packaged content)? How easily and quickly can you bake content? How easily can you deploy a complete build? Ideally, building the entire game from raw assets (including code) should be a one-click process that builds the engine, the tools, and the game, bakes and packages the content, builds an archive (or installer), and runs a suite of tests to validate the build.

Debugging/profiling tools: When your engine starts to run sluggishly, how will you debug that? More importantly (if this engine is for public use), how will your clients debug that? Unit tests are nice for making sure you don't break basic things like containers. Autotests (or "monkey input," random button presses) require a bit of work to do well, but are a great way to soak test a game for hours without needing to be present, and they'll uncover a lot of bugs that normal user input might not find. Cycle counters are a good basic way to profile CPU time; clock the number of cycles at the start and end of a function to test how long the function takes.

[BlueSweatshirt]

My recommendations are:

a) Unless you actually use other platforms then you may want to consider cross platform support. Certainly you can make the decision to decide what libraries to use, but just remember that if you don't actually understand the platforms that you want to port to, then your own code is likely to contain code which won't be cross platform compatible any ways. Secondly, if you don't use those platforms how do you expect to test code on them? So for now, just concentrate on a single platform (Say Windows for the PC) and then either learn how to get it onto the other platforms later or pay someone to do it for you.

b) A lot of the things you have planned out are just basic necessities of graphics, sounds and input. But there doesn't seem to be much in the way of handling interactions between entities (physics).

c) Tool sets, will you have any?

The layout you have at the bottom is pretty simplistic, but it depends on the types of games you plan to support. At the moment, a simple arcade game could probably use that sort of layout.

As I've been told before, in order to make a good, decent game engine, there needs to be case examples, otherwise all you're really doing is making a tech demo.

Thank you for the advice!

En response:

a) I have Linux, Mac, and Windows in mind mainly. I have copies of all mentioned OS', and have the ability to test the engine on all of them.

b) I have a custom collision engine, but it lacks triangle->triangle collisions. It's not *physics*, though.

c) I uhhh...  

I guess this could be conisdered more of a framework as I currently have it.

What would you recommend as far as layout?

As far as case examples-- I'm not sure to how answer that one.

@ latest post
That's great advice, thank you.
The engine's purpose is for myself/team projects.
Either one or several games will be made with this, and I'd like it to be flexible between 3D and 2D game programming. I doubt I'd release it to other developers-- Unless I decided to go and create documentation for it.

[Snakey]

a) I have Linux, Mac, and Windows in mind mainly. I have copies of all mentioned OS', and have the ability to test the engine on all of them.

Just be careful with that thought. Getting a project to successfully compile is one thing ... getting it to work is another. I'd advise to just pick a single platform and then to just stick with it and then transfer across at a later date. Thinking too much about cross platform is going to hinder your progress more than anything else ... particularly if you don't even know if people who use those OS's are going to even play / pay for your game.

[Garthy]

Just a few thoughts and words of caution that I hope help. For what it's worth, I've worked on cross-platform (Linux/Windows) software for years, both for other people and for myself, including my own C++ game framework, and a completed game suite.

The first and most important question is- do you really need your own engine? If your goal is developing a game, making your own engine too can set you back many, many months. The answer might be yes, or might be no, but you need to think about it.

Don't get too caught up in the framework. It's tempting, and addictive, to build up a clever and monumental framework, much of which doesn't actually bear out into a real game. Don't go overboard. It's very tempting, and I've given in to this somewhat at times. It's much faster to design for expansion than implement everything at once.

Whenever you try out a new library to pull into your framework (you'll be using a bunch of these and not reinventing the wheel every time, right?), make sure you can get it to compile for your targeted platforms. Sometimes this is enough to eliminate the viability of a library- the fact that it is almost impossible to get going on one of the platforms. Then, get the basics going OR a test that uses it, then try it on each of the platforms. You need to know about major problems *early* in the piece. This will let you decide if you wish to use the library or not, and if it can only be viably used on one platform, how you're going to deal with it.

If you're going cross-platform, I'd get the engine to a very basic state, and then make sure it runs on each of the platforms you plan to support initially. Then I'd develop on your favourite platform (whichever you prefer), and every so often, bounce your code across to the other platforms and fix the problems that arose. Pre-release, I'd do this perhaps once a month or once every two months. Depending on the focus of your work, this can take anything from a couple of hours to a few days each time. I know this contradicts the other advice in this thread, so you'll have to make your own call as to the best way to proceed.

And last of all, reread my first suggestion. Do you really need your own engine? I've done it, but if I had my time over again, I'd invest some more time into checking out existing engines, which, whilst not perfect might be close enough for it to be more worthwhile to use them instead. Remember, if you use an external engine, whilst you may be at the mercy of its developers, they are also very likely working on that engine in the background, and improving it, while you work on your game.

Hope it turns out okay. Good luck!

[BlueSweatshirt]

It's something I've thought about a lot.(the relevance of making my own entire engine)

The main shindig in my motivations here is that I want full access to what's going on behind the scenes. I like working with systems I know everything about.
Royalties are another issue. Using other peoples'/companies' engines brings up the question "What do you want so I can use your engine?". Which almost always involves money.

I'll only be reinventing the wheel as much as I have to. I'll probably draw in as much outsourced code as I can to provide functionality early on. Over time I plan on replacing all the code that has costly royalties associated with it.

My goal is to create my own environment to work with. While I would be much better off using another engine,(not to mention-- As you said, the time it would save) I'd like to have my own 'platform' to work with. Partly for the sake of just saying 'I made an engine', but not entirely.

As for cross-platform considerations, I want as many people as possible to play games I make. I'm going to try to make it as dynamic as possible, but I'd probably take the platform-constraint if I had to so I could provide functionality. And eventually work out of that over time. My main concern is that it works on Windows, and that's not really something I'll have to worry about.

Thanks much to everyone for the support and criticism so far!

[rfrank.nj]

honestly, no offense intended by this, but I'd take a look at some existing libraries if I were you -- I'm sure your capable of writing one -- but you'll realize quickly that it's gonna take a hell of a lot of time to write all that out even if it's all fairly simple.

Check out sfml -- cross platform, great license, does everything you want it to do. http://www.sfml-dev.org/

so instead of spending time writing an engine you can spend your time writing great games.  you want to go for playability first before making the 'best looking code ever'.

end users don't often 'look under the hood', you just want the car to be shiny (and really fun to drive)!  if you're getting my metaphor ;P

edit: or alternatively, build upon sfml / combine it with a 2d phys engine like chipmunk or box2d.. basically just write a layer on top of it to make it look and feel exactly the way you want it to.

[BlueSweatshirt]

honestly, no offense intended by this, but I'd take a look at some existing libraries if I were you -- I'm sure your capable of writing one -- but you'll realize quickly that it's gonna take a hell of a lot of time to write all that out even if it's all fairly simple.

Check out sfml -- cross platform, great license, does everything you want it to do. http://www.sfml-dev.org/

so instead of spending time writing an engine you can spend your time writing great games.  you want to go for playability first before making the 'best looking code ever'.

end users don't often 'look under the hood', you just want the car to be shiny (and really fun to drive)!  if you're getting my metaphor ;P

edit: or alternatively, build upon sfml / combine it with a 2d phys engine like chipmunk or box2d.. basically just write a layer on top of it to make it look and feel exactly the way you want it to.

Funny you mention that--

Because that was my verdict I reached a few days ago.(using and building upon SFML)

[Ivan]

I've been working on my own 2d/3d engine and just to give you some idea of a timeframe, it's taken me about 2 years of work to get it to a point of near completion (I consider myself a skillful programmer).  I am very happy i've done that, but i have not made barely any games in the past 2 years, or really had time to work on any other projects. So, that's something to consider if you plan on writing your own.

[salade]

Say, i was wondering what everybody's thoughts were about modularity in game engines and overall concepts of how to(or how not to) implement it. I know that an engine like source is highly modular, and that the early design ideas behind the monocle engine included ideas for a modular design, but i have heard that there are pitfalls that one can get trapped in when trying implement modularity, although not exactly what they are.

[Ivan]

I dont think you should worry about it at all.  Everything starts with a fast and efficient core engine that can manage your drawing and basic object management. You need some abstract base types for your engine elements, like entities, resources or what have you, something to make sure there is a solid abstract foundation to build on. Any well written object oriented code is modular by design, but you shouldn't over think it. If your base is abstract and speedy enough, you can always build on it in the future.

[oahda]

I recently started working on an engine, and what I find very important is portability. Portability makes the engine all that more attractive to work with.

I don't know what you're shooting for, but it's common in many engines to define a lot of basic things of their own, such as string classes, instead of using the std::string. My engine has its own string class and a lot of other basic things of its own.

Just make sure it's well-structured. You're using C++, so make use of classes and generics. They are your primary tools for writing well-structured libraries. Give comprehensive names to the classes.

Also, make sure that any file can be loaded individually. You shouldn't have to load the entire library if you don't even want to use half of it. Also make sure you write Doxygen comments all the way from the beginning, so that you won't have to do that later. That way, you can easily generate an HTML documentation for your library.

[jmp]

Also make sure you write Doxygen comments all the way from the beginning, so that you won't have to do that later. That way, you can easily generate an HTML documentation for your library.

In addition to this, remember that a generated documentation is not a replacement for a proper hand-written documentation.

Check out sfml -- cross platform, great license, does everything you want it to do. http://www.sfml-dev.org/

Slightly off-topic, but SFML also does a lot of things awfully wrong. Printing all of its errors to the standard error stream instead of its own ostream instance, for one. Sure, cerr can be redirected to something else, but what if my own program uses it as well? Then all of my errors are redirected there too. I do not think engines should do that.

[oahda]

Also make sure you write Doxygen comments all the way from the beginning, so that you won't have to do that later. That way, you can easily generate an HTML documentation for your library.

In addition to this, remember that a generated documentation is not a replacement for a proper hand-written documentation.

Of course not, but that way you at least have the opportunity to quickly and easily generate a good HTML documentation.

I don't think you have to complement it with another documentation, though, but rather with some good tutorials to get the users to understand how the engine and the library works.

[jmp]

Of course not, but that way you at least have the opportunity to quickly and easily generate a good HTML documentation.

I have said nothing that contradicts this.

I don't think you have to complement it with another documentation, really, but rather with some good tutorials to get the users to understand how the engine and the library works.

Which is exactly what I meant. Automatically generated “documentations” are only good for API references.

[Garthy]

Adam & jmp:

Document-generating tools (eg. Doxygen) tend to be quite good at producing decent quality API references. They are less impressive when generating other documentation (eg. tutorials, guides, etc), but *can* be used in this way, if that is the preference of the person writing the documentation. Personally, I'd say you both have good points, and perhaps agree more closely than you realise.

[oahda]

Yeah. Even if you're learning through a tutorial, a complete API documentation is always handy if you want to look up stuff on your own, and find out about every detail that's not covered in the tutorial.