Kind of random thought but would there be any interest in a kind of reworking of the Enginuity articles? I'm considering writing something like that myself to solidify my already pretty decent understanding of most systems in your modern-day game engine as well as to give all of the n00bies someplace to start :D I remember when I first started out maybe a little less than a year ago, wondering how in hell one actually makes the components work with one another/play nice. I figure it's the least I can do! Aims would be pretty similar to the original Enginuity, i.e. decent multi-platform compatibility, use of several common APIs (although I personally prefer working with the native DX, OGL, OAL, so on, so forth as opposed to like SDL. Gives a muuuuuuuch better understanding of mechanics.) and even a few higher-level concepts such as multithreading with OpenMP. Seeing as I have a really hardcore/perfectionistic approach to feature design/implementation I would think each article would focus on a particular concept or feature, such as efficient/fast memory management, (which was a common complaint about Enginuity I-- nothing personal, Superpig, but it was a bit on the slow side. At that rate you may as well use Java *shrug*) building a robust mathematics engine, abstracting render settings/features from the renderer itself, and so on. Questions/comments/concerns are always welcomed, as are potential feature ideas :)

I think that a series of articles like that would be good as long as they were presented in the right way. The biggest challenge in creating a full-blown game engine is deciding how all the components should fit together and communicate. Once you've established the contract between all the components you can start getting into the details of a fast memory manager, advanced rendering system, etc...

Quote:Original post by Driv3MeFar
No offense, but if you are thinking about writing a series of articles like this, who are you and what qualifies you to write them?

I personally have no interest in seeing anything of the sort, and would be weary because poorly written ones could do more harm than good for a beginner.

No worries, I understand perfectly :)

While I wish I could say I've worked on 7 AAA-titles for over a dozen years, in actuality I'm a C++ programmer with about 1.5+ years (with C++ in particular. I've done game dev work since about the 7th grade. I'm now more or less a senior in high school.) of experience. My particular areas of specialty are general computer graphics (I 'spose I work with DirectX more than OpenGL, as I prefer HLSL to GLSL. I R HAET SOFTWAER RAYTRACERS!!!!1one :P) and artificial intelligence. I would hardly consider myself to be completely in the dark in regards to good design methodologies and/or practical previous experience, as I've done a good amount of work on general-purpose physics sims and have perused the works of such figures as Carmack/Duffy, O'Rorke and Newell as well as other slighly less well-known/emerging names like Jeff Orkin of GOAP fame. I also go through research papers like novels :D

But seriously I don't think I'd consider applying for such a role if I had doubts as to my own understanding of this. If there's anything else you'd like to know, feel free to ask, I don't mind :)

(although now that I said that I'm sure someone's going to post a big complicated mess of source code and ask me what it does. According to Murphy's Law, I will not be able to do so :P)

You're forgetting the most important thing, a working engine that you designed that we can have a look at.

Anyone without a working , completed, engine that they designed can't be considered qualified to write such an article. And even then it is questionable.


Regarding your topic title question:
I would be very interested in an enginuity like article series written by a competent enough programmer.

On the other hand I would be extremely interested in a series of enginuity like articles centered around how to design a good multi threaded engine designed to work with variable number of processor cores.

One and a half years of experience.

Uh, no.

Quote:Original post by issch

Quote:Original post by InvalidPointer
While I wish I could say I've worked on 7 AAA-titles for over a dozen years, in actuality I'm a C++ programmer with about 1.5+ years (with C++ in particular. I've done game dev work since about the 7th grade. I'm now more or less a senior in high school.) of experience. My particular areas of specialty are general computer graphics (I 'spose I work with DirectX more than OpenGL, as I prefer HLSL to GLSL. I R HAET SOFTWAER RAYTRACERS!!!!1one :P) and artificial intelligence. I would hardly consider myself to be completely in the dark in regards to good design methodologies and/or practical previous experience, as I've done a good amount of work on general-purpose physics sims and have perused the works of such figures as Carmack/Duffy, O'Rorke and Newell as well as other slighly less well-known/emerging names like Jeff Orkin of GOAP fame. I also go through research papers like novels :D

I don't mean to be rude, but I wouldn't count that as terribly experienced. I know theres people in the forums here with much, much more game programming experience who wouldn't consider themselves qualified enough to write an article about game engine programming.
If you do write an article, I'd possibly be interested in taking a look regardless, but as was said before, a badly written article often does more harm to a beginner than it does good and in my experience, there are countless bad articles written by people with only a number of years experience for every one good one.

I have to agree with the above poster. Simply put, anyone that doesn't have at least a few years working with a software team shouldn't be writing articles on software design. Simpy put, you don't have enough real world experience to know what's going to work and what will fail miserably.

If you are really interested in writing the articles, make a game engine and document it. Do a post-mortem on your engine, write about what went right and what went wrong. You aren't going to get a really good engine on the first try, and since you didn't list an engine in your credentials there isn't anything to suggest that you could properly write a series of articles on engine design.

I would warn anyone attempting such a thing to be very careful about who their audience is.

Roughly speaking, the potential audiences can be divided into four groups:
1) Complete beginners
2) Hobbyists
3) Advanced/indie hobbyists/semi-pro
4) Professional

I think that writing for either 1 or 4 is not a good idea. The question is, which of 2 and 3 do you go for? The two groups have somewhat different needs. The people in 2 can get stuff on screen, have probably done terrain or BSP or whatever, but are not particularly clear on how to link things together coherently. Their needs are simple, it's just a lack of structure that is problematic. The 3s, though, have typically gone through this a couple times and have their own ideas about what to do, though most of them haven't actually had the experience of building an actual game on their tech. These people tend to deal with more sophisticated rendering pipelines that can include material systems, streaming, etc -- concerns which need to be taken into account in the basic design of an engine, but concerns that are too complex for group 2.

I tend to think that 2 is the correct target, since 3 are generally on auto pilot and are better served by focused articles on specific topics, and can figure out the rest themselves.