Jump to content
  • Advertisement
Sign in to follow this  
InvalidPointer

Any interest in a 'new' series of Enginuity-like articles?

This topic is 4068 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

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 :)

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Write it as a learning exercise. After you're done, post them on your personal site. Post a link here. Be prepared to have your engine's design torn apart, your coding style criticized to oblivion, your grammar mocked, and your manhood called into question. At this point you'll either take the criticism and improve your article or you'll give up. Eventually it might be good enough to put in the GDNet articles. No matter what happens, you'll learn valuable lessons.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!