Sign in to follow this  

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

This topic is 3857 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
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
Richard himself thinks Enginuity is really bad, so you're already starting from a bad place, and you don't have the experience to discern bad from good yet.

Hold off on it for a while until you can see more glaring flaws with it. There are quite a few.

Incidentally, I'd love to see you re-invent SDL's wheel. Their HID joystick interface code is several thousands of lines long, refined over several years and it's still pretty buggy. Hubris.

Share this post


Link to post
Share on other sites
Quote:
Original post by smr
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.


I don't need a community to do that, I already take care of that myself :P This is what I refer to when I mentioned 'hardcore/perfectionistic.' I'm just that.

@ Rayv, few other people that mentioned it:

I never said Enginuity was perfect and always the best solution for something at any given time. In fact I find quite a few of the systems very unwieldy. I believe I already mentioned the memory manager and pointer interface, but I've also done quite a number on most of the other core functionalities during my learning phase, such as modifying/extending console/setting variables and their storage, lots of kernel/task code, and a good amount of multithreaded design. I've read some pretty good articles on the basic ideas behind the whole separation of tasks concept, such as making a dedicated physics, AI, logic, etc. thread and then periodically grabbing recent data off the 'top.' Syncing with other systems for MP becomes a bit more difficult, granted, but asking yourself "I'm a server/client trying to do X. How do I go about doing that?" is of great use there, as always. Try it yourself if you don't already.



I also think pretty much everyone misunderstood my 'writing' statement up top-- I've gone and done quite a few scratchbuilt engines myself, (but I think you may have concluded that, hopefully, from earlier in the post) the core theory's ridiculously simple, if overwhelming at first. One of the main reasons I decided to consider writing this is for community input-- often times people will have better/faster/simpler ways to go about it. I welcome the chance to improve my work in whatever way possible. Goes with the perfectionist thing.
(although it poses problems for deadlines, I will admit :) )

I also remember what it was like to read 50 different tutorials on how to do X and Y and getting horribly lost as to "why do I stick this here?," "Does it matter if I do things this way?" and of course the favorite "That's all fine and dandy, but how do I get it to play nice with all the other things?"

Argh. Show a little faith, at the very least I can understand and have a decent conversation about potential shortcomings. Hopefully that at least says something. *shrug*

Share this post


Link to post
Share on other sites
Quote:
Original post by mikeman
Quote:

I've gone and done quite a few scratchbuilt engines myself...


All that in 1 year? Cool. Screenshots/Downloads?


Sure. Visuals aren't overly impressive seeing as a decent amount were done for text-based stuff, but the graphics don't make the game, or so I would hope. If you want some more pretty-pretty stuff I think I could probably whip something up, I have a barebones DX9-based variant on my general-purpose renderer class I guess you could have a look at. If you aren't looking for craploads of features, I could probably throw in an OpenGL and maybe even a DX10 version too. Gotta love class clusters :) Need to transfer a good amount of stuff off of the school servers, but I s'pose examples of my style of coding would definitely be a good idea. I'll get back to you on that.

And it's 1.5 years, sheesh :P

Share this post


Link to post
Share on other sites
All I'm trying to tell you is that just because you've read many articles about engines and whatnot, doesn't mean that you're ready to write articles of that calibour yourself. If that was enough, I would be writing books about superstrings theories. And personally, I find it a bit funny how you're trying to present yourself as an accomplished scientist("My particular areas of specialty are general computer graphics(yet you don't have any interesting screenshots to show) and AI(anything to show here?)"). There's just not enough time in 18 freaking months man to reach a level where you can say "my areas of specialty". Please.

If I were you(actually I were you some years ago), I would concetrate on still learning, read articles and books by those great authors and programmers you mentioned, and just work on my own projects,leaving articles to those with way more experience than 1.5 years. But suit yourself, man. *shrugs*

Share this post


Link to post
Share on other sites
Quote:
Original post by InvalidPointer
I don't need a community to do that, I already take care of that myself :P This is what I refer to when I mentioned 'hardcore/perfectionistic.' I'm just that.

And how does this ensure that you learn the *right* things from your mistakes? The problem with trying to use yourself as a teacher is that you've got a teacher who shares the exact same weaknesses as you do. Someone who won't be able to tell you that "this is a really bad idea because...", and someone who won't be able to tell you "a good solution to your problem might be to..."

From someone wanting to help educated newbies, I think it's a really bad start to say "I don't need other people to learn".

Quote:
I never said Enginuity was perfect and always the best solution for something at any given time.

But have you spotted the same glaring flaws and problems that Superpig/Richard himself have found since he wrote it?
I think there's a valuable lesson here. Richard is one of the handful of people around here I'd trust to write such an article. And even he failed (well, more or less. He doesn't like the articles, and a lot of beginners have copied its faults and design flaws). Now we have countless newbies reading the Enginuity articles and assuming "this is how it should be done". On the whole, would it have been better if the articles had never been written? I don't know, I won't judge that (I thought the articles were definitely worth reading), but if he couldn't make an article on the topic that clearly did less harm than good, then what are the chances of you doing better?

Quote:
One of the main reasons I decided to consider writing this is for community input-- often times people will have better/faster/simpler ways to go about it. I welcome the chance to improve my work in whatever way possible.

Er, wasn't that what you just said you didn't need the community for? [wink]
Anyway, that's definitely a worthwhile goal. But I'd do as people above have suggested, write the article, and let people criticize it before it's posted as a proper GD.Net article. And when the necessary changes have been made, when people run out of ammunition for shooting down your design, it would probably be a very good candidate for an article. (and by then, you and most others following the discussions will have learned a lot already)
But I wouldn't present it as a "newbies guide to engine programming" until it's been through a few bouts of being torn apart by the more experienced community members. [wink]

Quote:
Argh. Show a little faith, at the very least I can understand and have a decent conversation about potential shortcomings. Hopefully that at least says something. *shrug*

Well, as already said, that's a worthwhile goal, and I think that would be a very good idea. (and that way, it has the potential to be what Enginuity should have been)
What concerns most people here is more that it's very easy to teach the wrong things to a beginner, and much harder to afterwards make them realize that what they learned is actually a bad idea. So an article teaching beginners how to make an engine (or anything else) can do a lot of harm if it isn't a very high quality.

So start with writing the article, post a link to it here and let people tear it apart. Pick up the pieces, try again, and repeat ad infinitum...
At the very least, a lot of non-beginners, yourself included, will learn a lot from the discussions and criticism it earns, and at best, the end result will be an article that beginners can also learn a lot from.

All in all though, I'd love to read such an article. So go ahead and write it, to begin with, as a learning exercise, and to spark some engine-design discussions here. And maybe later on, as a "proper" article.

Good luck with it :)

Share this post


Link to post
Share on other sites
Just post it on your own site with a disclaimer. If it's something you really want to do just do it. I'm trying to write a very basic fps engine right now (I wont even pretend that its any good) and id like to see some articles about how to implement collision detection and space partitioning (bsp vs octree) for this type of game.

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Quote:
Original post by InvalidPointer
I don't need a community to do that, I already take care of that myself :P This is what I refer to when I mentioned 'hardcore/perfectionistic.' I'm just that.


From someone wanting to help educated newbies, I think it's a really bad start to say "I don't need other people to learn".

Quote:
One of the main reasons I decided to consider writing this is for community input-- often times people will have better/faster/simpler ways to go about it. I welcome the chance to improve my work in whatever way possible.

Er, wasn't that what you just said you didn't need the community for? [wink]

Nah, I just meant it's not anything new. Good point about that particular interpretation though. Good to see that there can still be some more, shall we say, less overbearing posts than the norm. It's interesting the amount of flak already sent my way for making a more or less HYPOTHETICAL suggestion about reworking what many (myself included there) thought was a pretty decent concept with some flaws in the execution. You'd think that I was drowning kittens and/or puppies the way some of the responses sound.

I also thought it was more or less assumed that it would be posted for peer revision. Of course I'm not going to be able to write everything/find every mistake in it. My mistake there, I guess that is what you get for not being with a community since the get-go.

@mikeman-- Hence the phrase "C++ programmer for 1.5 years, game dev work since 7th grade." (approx. 5-6 yrs, but I did do some simple BASIC about three years even before that) Just because I don't work with one particular language doesn't mean I don't understand or put time and effort into learning the math and theory behind graphics and AI techniques as well as coming up with potential ways to improve upon them. I just recently began spending time learning the specific implementation details. If you're having trouble visualizing this, think UML.

Share this post


Link to post
Share on other sites
Enginuity had a lot of errors, but it is an interesting project. I think you shouldn't start another article on same theme, you have allready 4 or 5 articles about it. If somebody want to learn, there are still enginuity articles.
If you are not too experienced you'll do more harm with articles than good.
Instead of that, open one open-source project with few programers, and make some simple engine with them, that will follow your guidlines on how should look that "simple" engine. And if there are errors in project, if it is open-sourced, better programmers will change your code, if they stumble upon on some errors.
And when you have well polished project, then start with your article.

Share this post


Link to post
Share on other sites
Quote:
Original post by InvalidPointer
Nah, I just meant it's not anything new. Good point about that particular interpretation though. Good to see that there can still be some more, shall we say, less overbearing posts than the norm. It's interesting the amount of flak already sent my way for making a more or less HYPOTHETICAL suggestion about reworking what many (myself included there) thought was a pretty decent concept with some flaws in the execution. You'd think that I was drowning kittens and/or puppies the way some of the responses sound.

Better get used to it... People tend to be a bit... direct here. [wink]
That said, I don't think what you've been told so far is too bad. I mean, you haven't had any death threats, or even plain "No. Don't even think about it"'s.
Mostly just people saying you need to make sure you *really* know enough to start teaching clueless beginners.

Quote:
I also thought it was more or less assumed that it would be posted for peer revision. Of course I'm not going to be able to write everything/find every mistake in it. My mistake there, I guess that is what you get for not being with a community since the get-go.

Well, it also depends on the kind of peer review we're talking about. I don't think we're talking about pointing out typos or grammatical errors. Most likely, you'll get more than a few comments that more or less require you to scrap your current design and start over. And most likely have to do it more than once. [grin]

Share this post


Link to post
Share on other sites
Quote:
Original post by InvalidPointer
Nah, I just meant it's not anything new. Good point about that particular interpretation though. Good to see that there can still be some more, shall we say, less overbearing posts than the norm. It's interesting the amount of flak already sent my way for making a more or less HYPOTHETICAL suggestion about reworking what many (myself included there) thought was a pretty decent concept with some flaws in the execution. You'd think that I was drowning kittens and/or puppies the way some of the responses sound.


Keep in mind that no one (I hope) is attacking you personally. It's just that teaching beginners is not an easy thing to do, and bad teachers make bad programmers. When you even suggest that you'd like to write a series of tutorials, you will (rightfully so) be under a high level of scrutiny, because no one wants to see another set of badly written tutorials. It may seem harsh, but we all (again, I hope at least) mean well.

Share this post


Link to post
Share on other sites
Quote:
Original post by Driv3MeFar
Keep in mind that no one (I hope) is attacking you personally. It's just that teaching beginners is not an easy thing to do, and bad teachers make bad programmers. When you even suggest that you'd like to write a series of tutorials, you will (rightfully so) be under a high level of scrutiny, because no one wants to see another set of badly written tutorials. It may seem harsh, but we all (again, I hope at least) mean well.

I think if you look at how many recent articles that don't seem to be advertisments or target professionals(usually product sales lol) you'll find there are barely any. E.g lately many reviews(if that can even count as an article) have been about pretty expensive tools, or very basic articles that don't really help you make a game.

There used to be a lot of cool and interesting articles. What happened I do not know. It is not my position to speculate, however if I'm not somehow confused and indeed the amount of decent articles have moved towards zero I am greatly worried.

Also I think a beginner could write a nice article if they did some research beforehand. Anyone can write a basic tutorial about A*, if they study the algorithm first. Even a poorly written article could be nice if it causes an interesting discussion in the forum. Discussing coding issues can often make you realize things you did not realize before.

Share this post


Link to post
Share on other sites
Actually I think I'd be more interested in a set of post mortems on engines designed by gamedev members, with sources.

First of all I think it would be enlightening to see various peoples comments on their own systems, successes and failures. Even seeing the different methods people used to deal with aspects of their game would be interesting. You could even get another individual to take a detailed look at someone elses system and see what they think of it, a kind of external review as people tend to see their own creations in a different (and not always positive) light.

Game engines designed just to be a generic engine are far more challenging to write than just making a game and then extracting the "engine" bits and seeing if they have any value in later games.

I don't know how one would present such post mortems really, I don't know if they would merit individual articles or what.

Share this post


Link to post
Share on other sites
Just thought of a style/feature that hasn't been seen much, if indeed at all, in the collection of articles-- Suggestions/jumping-off points/frameworks for alternate implementations. If they're reasonable I think this could circumvent some of the "this is the one and only way to add feature X" problems that pervade most tutorials of a similar nature. Seeing as this is slightly more focussed on the architecture aspect it shouldn't be extraordinarily difficult to come up with a couple different possible methods of doing things.

It'd probably also help users construct an API that's intuitive for THEM-- what may be second nature to me can and quite often is very clunky for another person, especially considering how low-level a lot of this is.

I am pretty pleased with my most recent iteration of my memory pool/manager, though. I'll probably give that to the community to give an idea of how I think/my coding practices/demo article writing abilities.

@Spoonbender- Yeah, kind of like how review works for a lot of scientific publications-- you submit what you did to your peers and they check to see if your method(s)/results are valid and can be reproduced/extended upon. In terms of understandability I'm already learning firsthand how important it is to think about what you say-- people have already demonstrated lots of ambiguities/possible alternate interpretations in some phrasings of mine. Fortunately most code is much more structured and less prone to this, but it's still a pretty good reminder. Chalk it up to experience.

Share this post


Link to post
Share on other sites

This topic is 3857 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this