   Enginuity Party 6?
  I've been reading/working through the Enginuity articles and are loving them.  Only problem is that it doesn't take long to be through the 5 that are out there.  When do we get a 6? And then a 7?  And then an 8?  ...and then the complete book reference and stuff. :)  ...wishful thinking.Anyways....it's great stuff, where's the rest?!   
  Basically, SuperPig dropped the series when he came to discover some severe shortcomings in the way things had been setup, essentially having painted himself into a corner. I don't believe there are any plans to continue the series.   ;  It would certainly be interesting to see a new series covering a more modern engine architecture (component-entity, scripting, etc.). I fear however that the number of people qualified to write such an article, and also with the free time required, is very, very small [wink]   ;  I'd also be interested in reading more from him. Even when the enginuity series *might* for some people be not very good, I think they are very instructive and enlightening.   ;Quote:Original post by swiftcoderIt would certainly be interesting to see a new series covering a more modern engine architecture (component-entity, scripting, etc.). I fear however that the number of people qualified to write such an article, and also with the free time required, is very, very small [wink]I couldn't agree more!  Does anyone know of any really solid books on the subject? Preferably with code snippets and real information as well as conceptual information.   ;Quote:Original post by HollandQuote:Original post by swiftcoderIt would certainly be interesting to see a new series covering a more modern engine architecture (component-entity, scripting, etc.). I fear however that the number of people qualified to write such an article, and also with the free time required, is very, very small [wink]I couldn't agree more!  Does anyone know of any really solid books on the subject? Preferably with code snippets and real information as well as conceptual information.Engine design is a tricky topic - David Eberly's books are really very good, but focus more on the technical side of things. I haven't found much else in the way of printed matter on the architectural issues, and the information on the web is fragmented at best.   ;Quote:Original post by swiftcoderQuote:Original post by HollandQuote:Original post by swiftcoderIt would certainly be interesting to see a new series covering a more modern engine architecture (component-entity, scripting, etc.). I fear however that the number of people qualified to write such an article, and also with the free time required, is very, very small [wink]I couldn't agree more!  Does anyone know of any really solid books on the subject? Preferably with code snippets and real information as well as conceptual information.Engine design is a tricky topic - David Eberly's books are really very good, but focus more on the technical side of things. I haven't found much else in the way of printed matter on the architectural issues, and the information on the web is fragmented at best.Yeah...I have his Game Physics book.  It really is a solid book.  Good for reading and for reference.  Would you say that the 3D Game Engine Design book is also good?  What sort of topics does it discuss?  Does it dig into the details like Enginuity did with the memory management and all of that or does it just talk about overall structure and necessary design implementations?   ;Quote:Original post by owlI'd also be interested in reading more from him. Even when the enginuity series *might* for some people be not very good, I think they are very instructive and enlightening.The problem is if they instruct and enlighten you to do things that, like SuperPig found out, end up with you painting yourself into a corner and having to drop the whole thing.The enginuity articles seem great, if you haven't actually implemented and tried to use the entire engine. So why should he continue a series of articles that actually lead you towards a broken engine?It has nothing to do with "for some people".Apart from that, most of the wise GD.NET gurus these days suggest to write games, not engines. (And they're not alone. Kyle Gabler (World of Goo) and Petri Purho (Crayon Physics) suggested the exact same thing at a talk they held about indie development a few weeks back).Basically, forget the entire notion of a single monolithic "engine" that offers all the functionality your game needs.   ;Quote:Original post by SpoonbenderQuote:Original post by owlI'd also be interested in reading more from him. Even when the enginuity series *might* for some people be not very good, I think they are very instructive and enlightening.The problem is if they instruct and enlighten you to do things that, like SuperPig found out, end up with you painting yourself into a corner and having to drop the whole thing.The enginuity articles seem great, if you haven't actually implemented and tried to use the entire engine. So why should he continue a series of articles that actually lead you towards a broken engine?It has nothing to do with "for some people".Apart from that, most of the wise GD.NET gurus these days suggest to write games, not engines. (And they're not alone. Kyle Gabler (World of Goo) and Petri Purho (Crayon Physics) suggested the exact same thing at a talk they held about indie development a few weeks back).Basically, forget the entire notion of a single monolithic "engine" that offers all the functionality your game needs.I agree that writing an engine is almost nonsense if you are trying to write a game, but you can't invalidate the fact that many games these days are produced by an engine and if that engine wasn't already there then making that game could have take much much longer.  For me, it's not so much trying to create an all-encompassing engine that will handle anything I can throw at it, but more like getting a very solid and very generic backbone already established so that prototyping a game wouldn't be difficult and would take little time. Then if the prototyped game is good, I can tweak it and remove engine parts that don't really matter.For example, in Enginuity they start everything out with a memory managed object pointer.  You can derive anything from the MMObject and then you can track its memory usage.  Another thing they start off with is a profiler that can tell you how much time was spent in a function and all of that.  This is all great for prototyping and for testing, but this isn't really the sort of code you'd want in a final game.[Edited by - Holland on June 14, 2009 1:43:53 PM];Quote:Original post by HollandFor example, in Enginuity they start everything out with a memory managed object pointer.  You can derive anything from the MMObject and then you can track its memory usage.  Another thing they start off with is a profiler that can tell you how much time was spent in a function and all of that.  This is all great for prototyping and for testing, but this isn't really the sort of code you'd want in a final game.It is also the sort of code that you are unlikely to finish your final game without...Memory management is a sticky issue in C++, and most sizeable code bases end up with some sort of fancy memory management scheme, with smart pointers, allocation pools, etc. Profiling is also essential, although I would generally recommend an external tool.   