I''ve recently finished the first in a series of articles on developing a game engine (that is, from scratch), which I planned on submitting to gamedev as something aimed at newbies. I showed the article to a couple of people, and it seemed there were quite a lot of problems (mainly with my explanations of the engine, rather than the engine itself). I''d like to get a wider sample of opinion. Have a read of the article and tell me what you think. (Please). Looking forward to your feedback - just how badly panned can I get, hmm? :D Superpig - saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.

As an "advanced newbie" I found the article very useful indeed. However, it does delve into quite a lot of detail that a "pure newbie" would have trouble with. I think you just need a couple of extra paragraphs on the overall engine you are planning before jumping into the first tier. Although I''m sure the rest of the series would explain it, remember that the newbie confusion over "engines" usually stems from not understanding what goes into one. Perhaps a quick overview of the engine you plan on making would help clarify the whole series at the start. A nice diagram would be luverly too.

Good article

pan narrans | My Website | Study + Hard Work + Loud Profanity = Good Code

OK. I was thinking a roadmap of the series would be a good idea. I guess I need to decide what I''m going to put into the rest of the series, then.

I''m actually building a game on top of the engine the series builds - so far I''ve added scripting support, sprites, and DirectShow->textures (so you can not only play movies, but use them as standard textures, too). Thus far, the foundation tier is supporting things beautifully.

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.

Oh, the logger is available - it''s available indirectly, via the ErrorMessage() functions on the CApplication object (which is globally accessible as a singleton). The advantages of that are

(a) I can very easily change the logging method from my CLog to, say, a std::stream, without having to change things throughout the engine
(b) All ''messages'' are done through the same mechanism - be they errors, warning, infos, or diagnostics.
(c) It allows for ''gestalt'' behavior. The application may not want anything being logged for some period of time (spurious example: it wants to minimise HD access) - this method gives it total control over the logging process. Passing a CLog object all around the place means that while it''s preserving the paradigm of object modelling, it also results in disjointed functionality - the app does not behave as a syncronised system (a ''gestalt,'' or ''whole'').
(d) it allows for the app to handle overloads. For example, the CLog class should not be responsible for the message table (because the same strings will be used for user and debug messages as for log messages), so either we have everything using the table call some kind of GetStringFromTable(STRINGID) function; or we just have it call an overloaded version as ErrorMessage(STRINGID, target).
(e) I like the idea of only having one ''CApplication'' singleton, through which you access all other Foundation Tier services.

OK, so they aren''t brilliant reasons. But it''s working fine for me like that.

I fully intend to have a downloadable source code zip, which will include the minimum of the external libraries needed to compile the code (headers, libs, and any required documents like the GNU license agreement).

You''re all right in that it needs more explanation. I might split all the theory and code into seperate sections, actually - cover what each section of the engine is going to do and how it''s going to do it, and then actually look through the code.

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.