Jump to content
  • Advertisement

Archived

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

McZ

how to begin writing an engine?

This topic is 5224 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

where to begin? 1) first create small things like a camera&frustum class, vertex/vector and matrix classes and maybe some plane/AABBox visible check stuff. 2) or begin with the major thing like the RenderCore? then I would like to know how to decide what should be a new class? e.g. should I have the frustum and camera in two different classes or both in the same and so on.. what makes the rules when I should split one class into two? EDIT: and another thing.. what is the difference between an Interface and a class? [edited by - McZ on June 2, 2004 7:47:12 AM]

Share this post


Link to post
Share on other sites
Advertisement
You''re probably best off experimenting - there are no definitive rules on engine design. You''ll find that your engine changes considerably as you write different parts. But in answer to your questions, you should probably start with the more mundane stuff before starting on the renderer and such like - you''ll need a maths library to implement one anyway. As for questions like "Does the frustum go in the same class as the camera?" - things like this are probably best decided by yourself, depending on your engine design. Try it both ways, see what works.

Have a look at the Enginuity articles on GameDev for ideas on how to start, and have a look through some open source engines. There are also several old threads on the GameDev forums covering similar questions. Have a look through these.

Share this post


Link to post
Share on other sites
Basically the question you are asking is one of fundamental design: top-down or bottom-up. There are merits in both methods, and you will find that as you develop a design you will use a combination of both methods.

One thing I''d advise you to do is to draw out the overall design of your engine on paper, showing th communication pathways between each of the classes. The diagram in the enginuity series is a good start, try to plan the internal structure of each of the different sections such as rendercore/maths lib etc...

The difference between an interface and class: well the interface is the set of functions that are used to access the functionality of a module; it''s not necessarily a class, although quite commonly it is implemented as an abstract base class. A class also can include data as well as give a set of defined functions, so an interface can be implemented as a class(think of a class as a set of functions and data packaged together in a box, and interface as the set of functions) so a class always has an interface in the pure sense of the word, but what is often meant when talking about interfaces (Java included - and this is how Java qualifies lack of multiple inheritance), is to provide simply a definition of the functions and use dispatching to functions to provide the implementation.

Share this post


Link to post
Share on other sites
quote:
Original post by McZ
where to begin?

1) first create small things like a camera&frustum class, vertex/vector and matrix classes and maybe some plane/AABBox visible check stuff.



If you''re using OpenGL, I recommend:
http://graphics.cs.uiuc.edu/~garland/dist/libgfx-1.0.2-doc/index.html

If you''re already using DirectX, use D3DX

There, step 1 is done

Share this post


Link to post
Share on other sites
1) Write actual games and as you create your own useful helper classes, just polish them off and add them to your engine.

2) Make your engine different than the 100000000000000 already out there, focus on at least one thing none of the others do well. This may require some thought, but if you write games to "test" the engine, you will start coming up with ideas.

This is how I''ve come to figure out what my current engine actually needs, by writing a few games and figuring out what work I was having to do over and over again, and then figuring out how it could be done generically. Writing generic code is always a bitch, so make sure that its important code to write. Also, with the heaps and heaps of free libraries out there, you may be able to avoid writing code for things that have been done for free and written better than you are capable of. Reinventing the wheel is not particularly clever.

Share this post


Link to post
Share on other sites
Personally, I think it''s better to get some stuff down and dusted - get things on the screen... then take out resuable bits and refactor it for your next project.

If you don''t then you''ll constantly be second guessing yourself.

If you build a big V12 engine for a game that really only needs a 1 litre 4 banger, you are wasting a lot of effort. Conversly if you build a 1 litre and try to put it in a 10 ton truck, it aint going to go very fast.

I could wager you don''t have any design or analyis documentation done - so unless you really are going to bother with all that stuff then prototyping and developing bits as you need them is probably more suitable then creating a generic engine that is bound not to meet the requirements of every project you create without any tinkering.

Create an engine on the side - out of reusable bits of code you make - just get the game done in the mean time!

Share this post


Link to post
Share on other sites
I''m now on my fifth gametest application. Every time I start again it gets a bit better and more structured.

The first few attempts started with creating a window, a D3D device and a loop that rendered tiger.x and other things, and then I added to it. But that will never become a proper engine, you''re screwed from the start.

The last few attempts have been more structured, trying to divide the stuff into classes and separating game logic from game engine/graphics library, separate client and server to enable

To get something working I plan not to add anything complicated. I have defined a game where you control a 2D sprite on the screen, the game server moves 4 sprites randomly, if you touch one it''s game over. From this concept I''ll make the game and a decent engine, nicely separated, separate client and server so you can play either locally or over the network with multiple clients.


Share this post


Link to post
Share on other sites
An Interface in C++ is an abstract method or entire class.
A pure interface has no implementation.
A lightweight interface may have some implementation that "marshals" data) (Visual Studio creates these for COM / ActiveX controls).
But in essence interfaces allow a contract for a class responsibilities to be drawn up - many different classes can implement the same interface with different things going on in the background.
It is important for an interface not to change once it is widely used - it can be extended into another interface but the original should not be changed. This is infact how DirectX does things (so a DirectX7 game can ask for DirectX7 interfaces from DirectX9 and still work - the game doesn''t care it''s DirectX9 as it all works like the contracts drawn up in DirectX7 through the DirectX7 interfaces).

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!