Archived

This topic is now archived and is closed to further replies.

Engine Design

Recommended Posts

Nixsos    138
I have a few questions regarding engine design. I''ve got a good grasp on C++, but there are a few things which keep me from programming large projects like a game. I know they are minor, but i really need some input from the professionals out here. First of all, i whas thinking about using namespaces to seperate the engine from game code. Is this how it''s done in huge projects? like: namespace Engine { class Window; class CD3D; } namespace Game { class Window : public Engine::Window; } Secondly, how do you link objects to eachother? Let''s say I''ve got 3 classes: - CD3D - CWindow - CLog The window class depends on the log class and the D3D class depends on the Window class, but on the Log class as well. Would i just give the Window class a public instance of the log class, so the D3D class can use that log object? (Doesn''t that undermine OOP rules?) Or is it better to pass a pointer or reference in each constructor? Thirdly, is it logical to make a generic engine which can be used for multiple genres? Or is it better to make one engine for one game / genre? Thanks for your input.

Share on other sites
Oluseyi    2112
A more organic approach is to gain experience using engines, which will then inform desirable design characteristics for when you want to start building engines. In other words, use an available engine now to get used to the process of developing and completing projects (many "engine" projects never get completed for this precise reason).

Share on other sites
iNsAn1tY    476
I''m not 100% sure about your first question, but I don''t think that''s how they do it on commercial engines. Your second question I can answer. You should create all the classes you list there as singletons, in an engine. This means that if you have a window class which needs access to the log class, you include the log class''s header file in the window class''s code file (NOT the window class''s header file; see below). In this way, you can call your log write-to function from your window class like this:
CLog.GetSingleton().LogPrintf("This is sent to the log");
Look up some more stuff on singletons with Google or something.

Anyway, as I said above, every class''s code file can include every class''s header file, OK? This is useful, because then you can access all the classes in your engine, no matter which class you''re working on. All you have to do is include the relevant header file, like log.h or window.h. But, this can only happen if no class includes another class''s header file in it''s own header file. This creates conflicts, and it won''t compile. If a class is needed in another class''s declaration, you need to make that class a global, or make it specific to the class that needs it. In my engine, the 2D, 3D and 4D vector classes are globals, and are declared in shared.h. This means that by including shared.h in all my class header files, I can use the 2D, 3D and 4D vector classes in any class or class declaration (my camera class, for instance, needs 3D vectors in it''s declaration). Post back if you''re not sure what the hell I''m on about

Windows 95 - 32 bit extensions and a graphical shell for a 16 bit patch
to an 8 bit operating system originally coded for a 4 bit microprocessor,
written by a 2 bit company that can''t stand 1 bit of competition.

Share on other sites
IPKnightly    101
Look at

http://cg.cs.tu-berlin.de/~ki/engines.html

for all your 3d engine needs.

And with this list you don''t need to write one for most of them are open source and free.

Share on other sites
krez    443
in the "articles and resources" section (link at the top of the page) there is a series about game engines called "enginuity", as well as an article about singletons.

Share on other sites
Oluseyi    2112
quote:
Original post by DIRECTXMEN
http://cg.cs.tu-berlin.de/~ki/engines.html
That list is seriously out of date. I saw you defend it in another thread, saying that they had engines up to June 2000 - that''s an eternity in Internet Time, and particularly for game engines! Many of the links on that site are dead, too.