Quote:Original post by meeshoo
Well, the only thing i want is to for example to have a Rendering interface and more renderers that implement it (one for direct x, one for opengl, one for opengl es, etc). Of course, for start I'll have only one (direct x), but I want to keep it open for porting on other platforms. Same thing for the input system. I think this result can be achieved with static libraries, thanks for the tip.

First, I'd suggest dropping DirectX and go to OpenGL first if you really are worried about "other platforms", where the most common ones (linux, windows, iPhone/pad) all use OpenGL or the OpenGL-ES variant. (flame-war like subject... others will say stick with directX. You could port to the X-Box and it works under linux in wine, etc.)

Second, worry about hiding the graphics API from the game before hiding the graphics API from the engine. You should be making "models", "materials", "Effects" and other high level interfaces for the game to use. Then you can worry about being able to port those parts later.

Lastly, I'd say go look at SDL or Ogre or the like to take care of some of those abstractions for you.

Ty for the tip.

Well, I thought about opengl too, i mean I know way better the opengl api then the dx one, but dx has some very nice helpers like D3DX for doing the math, so i won't have to do a new math library for starters.

About ogre and the like, my point here is to learn to make a 3d engine by myself, so using an already made one won't help. I already have a license of C4 engine to make 3D games, but really what I want is to make a game with it's engine by myself. SDL might prove useful however for the input part.

Ok, I managed to integrate some modules that I have previously written for another application, like a direct input module and some direct 3d simple renderer, into the engine as static libraries, and I also managed to do this with cross-platform in mind, using a set of abstract interfaces.

Now I have another question:

Some game engines "are the game itself", they just load the actual game as a module and run it. I can think of Unreal, Crytek and others. It's like you develop the game in an editor that actually allows you to play the game inside already and it's WYSIWYG.

On the other hand there are these engines which are basically a big collection of very robust libraries that work together and the game itself is an independent application, one for each platform, that implements platform specific tasks like window creation and such, and this game uses the engine as a library of utilities and tools, nothing more.

Which do you think it's the best approach? Do the window creation and everything as part of the engine and run the game like it is some kind of plug-in, or have the engine considered a huge library and the game should just use whatever it needs from it?

Thanks,

I'd say it's up to you, really. There are obvious pros and cons to each approach, but neither is inherently "better" for a general-purpose engine.

I used to try to modularise common bits into libs in what I thought was a fairly sensible way - e.g. graphics.lib for looking after Direct3D.

What I found happened was that each project, I would need to make some seemingly minor adjustments to the library for that project's specific needs. This would then break all the previous projects that also depended on the lib.

What I've done the last couple of years is just literally copy-paste the .h and .cpp files from the last project into the new one and add them to the project. Now free to tinker at will.

I've been playing around with Direct3D for about six years now and still don't have any real idea how to create a general purpose library wrapper that would suit all my needs without being horribly bloated.

So my advice, for what it is worth, is to use third party libraries but just add your own code in text form to new projects. Yes, it takes me fifteen minutes or so to get a new project set up and running, but I've been working on my current game for well over a year now so that isn't really significant.

Quote:Original post by ApochPiQ
I'd say it's up to you, really. There are obvious pros and cons to each approach, but neither is inherently "better" for a general-purpose engine.

Ty for your opinion. I think I'll go for the "library collection", as it can always be transformed into the WYSIWYG approach.

Quote:Original post by Aardvajk

Well, I did this too in the past, but ultimately the goal is to obtain an engine, not really the game itself, so I'll try to stay as modular as possible. It can become bloated indeed, but I guess only if you try to support too many things at once. I guess all big engines are a bit bloated, but however you get to choose what to link and use for your own game, nobody forces the user to use all the libraries and stuff.

Here are some thoughts:

1)As already advised, building an engine without knowing what it's for is likely to be a never-ending project, unless you're experienced at planning large projects from the ground up. The urge to plan big and go for a generic engine with elegant architecture, rather than something simple that you tie to a game and work on as you go, is normally quite strong. But good software of this size is rarely designed up front and then brought to life, unless you know what this type of software should 'feel' like from working on similar things in the past.

2)How much experience do you have using game engines? I don't mean playing with them, but knowing in reasonable depth how they fit together - scenegraph, rendering engines, etc? Part of your research and design should definitely include looking at other engines like C4, Ogre, etc. You don't need to go into every line of source source, but understand how classes fit together and so on.

1) Agreed with you and this is why I have chosen a game project for it.

2) Not much of an experience, but I studied a bit their code and architecture and they are nice, although I have something else in mind for this one.

Btw, I have set up a blog about my progress (actually a long time ago, but haven't written anything since 3 years ago) so please check up my progress there, the last 3 or 4 posts are about my progress.

The address is here: http://mcozma.blogspot.com