As I said before, the purpose is to learn how to do it myself, not the game itself. The game will be a free one of course.

The C4 engine itself, while of an extraordinary design and containing some unique features (like their new terrain and some other ingenious stuff), it is not really ready for any game without a lot of tailoring and add-ons (for example it does not have a foliage sub system). I own that indie license since a long time ago, and C4 clearly has come a long way, but it did it on quite a slow pace and it is hard to say when the features I would need will be supported.

While this seems fit for a full team developing a game full-time, I think for me it is more suitable to make my own.

In addition to this, I have some interesting ideas which I want to try out regarding the architecture of the engine and C4, Ogre and others don't implement them.

NO game engine is ready for a game without writing your code... that's the point of the game, unless you're using a game-maker rather than a game-engine.

If you read carefully my previous post, you can see that I'm not complaining about having to write the game code, but some missing parts of the engine.

In that case I disagree. I've used Ogre and C4 on projects and it seemed the extra stuff we had to write would not be considered unusual.

I respect your opinion, as from what I discovered myself, there isn't really a definition or a clear concept for a game engine, so the features advertised by a 3rd party engine can match more or less the required list of features of a project.

Anyway, let's please stay on the topic, as it is clear to me that I want to learn how to program a lot of things by developing a game engine and a game, and not just the game itself, especially the hardest part, that is, the rendering/scene management part.

Now I'm studying terrain rendering methods, and I'm almost sold to geo clipmaps, but the problem is that I found out Carmack's megatextures are inspired by clipmaps, but are not really clipmaps, but are better, and I cannot find any resource related to how they do it (if it even exists, or it might be a company secret). Do you know any whitepaper about that?

I've been working on my own engine for the past year and I'll admit it is a complex task for one person to handle. In saying that though I have learnt a lot - not only about engine and graphics programming but a lot of general programming principles.

I think your best option if you want to complete something is define goals or a feature list and stick with it and once they are done you can add extras. I would probably start with working out the core components that make up an engine and put some thought into how they will link together.

The biggest task I've found so far is the Renderer and it's one of the most crucial, so I advise doing a lot of research and browsing this forum for information on how others have gone about their systems. Abstracting the Renderer isn't overly difficult, you just need to work out what resources (VB/IB/Shaders/Textures/Vertex Decl/etc) need abstracting and how your renderer interface will operate. Theres an article on gamedev about making an API independent renderer interface - it'll help you a bit I think.

As for libraries try find open source or free ones that will help save you time. For example, I don't plan on writing my own network or physics engine I will use an external library.

Hey, thanks for your reply. I will search for the article you mentioned, sounds very helpful.

Since my last posts here I've been researching a lot about what algorithms, techniques, 3rd party libraries and such I could incorporate in my engine and it's going pretty well so far. I have written a lot of interfaces, making sure the engine is modular and portable, but I have not implemented those interfaces yet (just what I needed to clear the screen with a color and have some keyboard and mouse input), and most of them are not even complete.

After some research on terrain rendering techniques and such, I've switched focus a bit to the content pipeline, as I want to nail down a general content flow from the software an artist would use to my game.

I also find very useful to keep a blog (or a diary or whatever) about my progress where people can read what I do, it's very good for motivation as it helps you somehow keep track of your work (for example even if for one week you did almost nothing as you are working on a very hard task, you can still look at your diary entries and say: "wow, look how much I've realized so far" :) ).

Read this.

Writing a game and extracting the engine is the only way to make something useful - if you lack experience.

It doesn't need to be a fully fledged game with great assets and interesting mechanics, but it must fully exercise the engine. If you design a tech demo that doesn't reflect real use then don't be surprised if the engine turns out to be poorly designed in the areas the tech demo didn't cover.

The fallacy of such an approach is frequently evident by many "engines" with pretty tech demos that never seem to grow into games.

You know yourself that you need experience to guide design. The designs you made at work would not have been possible had you done smaller scale design beforehand. Design is an iterative process (both during one project and between different projects), you cannot immediately jump to the deep end when you lack experience in a given domain.

Writing the game will give you this experience.

I had to say that I read your article in it's entirety and think it was very well written and I love the whole "well, duh" attitude behind writing it. I already know someone I NEED to send this to!