Hi, There were some little interest for this in another thread here in boost. So, who has any experience in game programming, it would be interesting to layout some requirements for a new engine and complaints from other engines. See if we can find out how a game engine should really be. Regards, -- Felipe Magno de Almeida
On 7/17/07, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
Hi,
There were some little interest for this in another thread here in boost. So, who has any experience in game programming, it would be interesting to layout some requirements for a new engine and complaints from other engines. See if we can find out how a game engine should really be.
I have some experience with PC and Playstation 2 games, teaching at Full Sail (http://www.fullsail.com) and working in industry. Not nearly as much as some contributors I imagine. I'm no longer in the game industry, but work with "game-related" technology on a daily basis with more serious end results... Some complaints I have about other engines are: - Ease of extending the engine. For instance, if a new algorithm is developed for interpolating between animations, it's not usually easy to integrate without redoing most of (or all of) the animation code. - Not supporting context changes in an optimal manner (determining least number of context change commands given a set of "renderables") - Being tied to custom containers and iteration techniques instead of having STL style iterators and STD library containers used. - Not being able to change the underlying containers at compile-time. e.g. the Scene Graph will always be a tree where children are stored in custom doubly linked lists, instead of the Scene Graph is templated on storage types, and you can make it a tree of vectors, or lists (much like Boost.Graph) I'm sure others will chime in with their own complaints, but I think a Boost engine should aim for as much compile-time flexibility as possible, paired with run-time flexibility, which I sounds like it would make heavy use of Fusion. For instance, I may want to specify a renderer at compile-time that always does 3 passes - depth only with opaque objects, then opaque objects, then alpha (translucent) objects. At run-time, if it's determined that the graphics hardware is too old to have support for 2x speed up in the depth only pass, we could switch to a renderer that only did 2 passes, opaque then alpha. Obviously the sorting mechanism for both passes would be different too (and templated). Front to back for depth only and opaque, then back to front for alpha. There are lots of levels to a game engine. Perhaps it would be wise to break it up into separate libraries. I can envision a single library just for dealing with the OS + graphics hardware (setting up the window, changing resolutions, changing bit depth, querying capabilities, etc), and another for higher level scene management, much like nVidia has a separate Scene Graph library. There would also be some sort of API that is agnostic between OpenGL and Direct3D backends. Lots to think about... --Michael Fawcett P.S. - Where does the math part fit in? Another separate math library? Needs to be heavily optimized for speed, vectors and matrices need to be guaranteed contiguous in memory, need support for row major vs column major... Create from scratch? Wait for the Matrix Template Library 4.0 which is "coming soon"? (I don't know if it does what is needed) Modify/Extend Boost.uBLAS and Boost.Quaternion?
--- Michael Fawcett wrote:
On 7/17/07, Felipe Magno de Almeida wrote:
Hi,
Hello, all.
There were some little interest for this in another thread here in boost. So, who has any experience in game programming, it would be interesting to layout some requirements for a new engine and complaints from other engines. See if we can find out how a game engine should really be.
I have some experience with PC and Playstation 2 games, teaching at Full Sail (http://www.fullsail.com) and working in industry.
Ah, a fellow Full-Sailor! I'm currently *gaining* some experience here, enough to agree with you on the issues concerning other engines. On the bright side, I can say for a fact that more game developers are recognizing the need to write and maintain robust engine code, judging from the growing number of guest speakers singing the praises for the Boost software libraries. I'll help out when I can, but the same circumstances that endow me with much-needed wisdom also leave me with little free time to use it.
P.S. - Where does the math part fit in? Another separate math library? Needs to be heavily optimized for speed, vectors and matrices need to be guaranteed contiguous in memory, need support for row major vs column major...
Yeah, it's sad to see everybody making their own math libraries just because the ones "out there" don't take advantage of [M/S]IMD instructions provided by their favorite architecture, etc. Cromwell D. Enage ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367
On 7/17/07, Cromwell Enage <sponage@yahoo.com> wrote:
[snip]
Yeah, it's sad to see everybody making their own math libraries just because the ones "out there" don't take advantage of [M/S]IMD instructions provided by their favorite architecture, etc.
Does anybody have any experience with GPU calculations on DirectX 10? And how hard it is to provide some sort of library for this. Are GPU calculations still like before (API-wise)?
Cromwell D. Enage
Regards, -- Felipe Magno de Almeida
Felipe, Can't you create a thread somewhere - or a Yahoo Group - for this, so we can discuss it there and then take any concrete functionality or module back to Boost for RFC? Regards /David On Jul 17, 2007, at 6:51 PM, Felipe Magno de Almeida wrote:
On 7/17/07, Cromwell Enage <sponage@yahoo.com> wrote:
[snip]
Yeah, it's sad to see everybody making their own math libraries just because the ones "out there" don't take advantage of [M/S]IMD instructions provided by their favorite architecture, etc.
Does anybody have any experience with GPU calculations on DirectX 10? And how hard it is to provide some sort of library for this. Are GPU calculations still like before (API-wise)?
Cromwell D. Enage
Regards, -- Felipe Magno de Almeida _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
On 7/17/07, David Bergman <David.Bergman@bergmangupta.com> wrote:
Felipe,
Can't you create a thread somewhere - or a Yahoo Group - for this, so we can discuss it there and then take any concrete functionality or module back to Boost for RFC?
That was what I was gonna do first, but then there were requests to keep it here. And it seems to attract people from other domains too. So I really don't know what is best. Or would you like to create a group already to start developing this?
Regards
/David
-- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
On 7/17/07, Cromwell Enage <sponage@yahoo.com> wrote:
[snip]
Yeah, it's sad to see everybody making their own math libraries just because the ones "out there" don't take advantage of [M/S]IMD instructions provided by their favorite architecture, etc.
Does anybody have any experience with GPU calculations on DirectX 10? And how hard it is to provide some sort of library for this. Are GPU calculations still like before (API-wise)?
Nvidia has a library/compiler (CUDA) that compiles "C" to GPU's. (Not Cg). Perhaps that's something to look at? Hm. A Boost library for developing languages/compilers. :) That'd be kool. (Heck, todays C++ looks like Haskell already, execpt for all the syntactic cruft. ;-) Cheers, /Marcus
Felipe Magno de Almeida wrote:
Does anybody have any experience with GPU calculations on DirectX 10? And how hard it is to provide some sort of library for this. Are GPU calculations still like before (API-wise)?
In the near future, Mesa (Linux OpenGL implementation) should allow to run any C, C++, or even Python code on your GPU.
On 7/19/07, Mathias Gaunard <mathias.gaunard@etu.u-bordeaux1.fr> wrote:
Felipe Magno de Almeida wrote:
[snip]
In the near future, Mesa (Linux OpenGL implementation) should allow to run any C, C++, or even Python code on your GPU.
How is that possible? -- Felipe Magno de Almeida
"Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> writes:
On 7/19/07, Mathias Gaunard <mathias.gaunard@etu.u-bordeaux1.fr> wrote:
Felipe Magno de Almeida wrote:
[snip]
In the near future, Mesa (Linux OpenGL implementation) should allow to run any C, C++, or even Python code on your GPU.
How is that possible?
Presumably "any" doesn't really mean any, but just that you can write code specifically for the GPU using C, C++, or Python. It seems that the idea is to write a compiler for C, for C++, and for Python that generates suitable code for GPUs of various graphics cards. -- Jeremy Maitin-Shepard
There were some little interest for this in another thread here in boost. So, who has any experience in game programming, it would be interesting to layout some requirements for a new engine and complaints from other engines. See if we can find out how a game engine should really be.
I have some experience with PC and Playstation 2 games, teaching at Full Sail (http://www.fullsail.com) and working in industry.
Interesting idea - though I'm not sure the full fledged game engine is the way to go there is definetely scope for creating some of the components IMO. I have some experience of games from working in the industry - particularly Xbox and PC on the graphics side of things. Gladly give any help I can - though I'm far from an expert and (sadly) I'm not currently in the industry.
Yeah, it's sad to see everybody making their own math libraries just because the ones "out there" don't take advantage of [M/S]IMD instructions provided by their favorite architecture, etc.
I played around with a SIMD abstraction layer for a while - the goal being to create a thin wrapper around SIMD code to allow simple compile time switches between different archtechtures SIMD implementations (particularly x86 vs. PowerPC vs. Software - due to Xbox 360 and PC). I have the initial code lying around somewhere if anyone is interested in such a library - it certianly may smooth over some of the headaches of creating such maths libraries (although the performance characteristics may not be ideal). Iain
iain.denniston@blueyonder.co.uk wrote:
I played around with a SIMD abstraction layer for a while - the goal being to create a thin wrapper around SIMD code to allow simple compile time switches between different archtechtures SIMD implementations (particularly x86 vs. PowerPC vs. Software - due to Xbox 360 and PC). I have the initial code lying around somewhere if anyone is interested in such a library - it certianly may smooth over some of the headaches of creating such maths libraries (although the performance characteristics may not be ideal).
I'm not sure whether this would be the right level for architecture specific optimizations. Having a layer that provides access to SIMD instructions might smooth out issues between SSE and AltiVec, but programming Cell or perhaps CUDA is afaik a bit more involved. I would start with larger operations such as FFT, SVD or "multiply a set of vectors with matrix A". Given a portable C++-only implementation, you could then provide architecture specific implementations of these building blocks. Malte
On 7/19/07, Malte Clasen <news@copro.org> wrote:
iain.denniston@blueyonder.co.uk wrote: I'm not sure whether this would be the right level for architecture specific optimizations. Having a layer that provides access to SIMD instructions might smooth out issues between SSE and AltiVec, but programming Cell or perhaps CUDA is afaik a bit more involved. I would start with larger operations such as FFT, SVD or "multiply a set of vectors with matrix A". Given a portable C++-only implementation, you could then provide architecture specific implementations of these building blocks.
For game engines, the one you want to do first is the Runge-Kutta. That'll handle the big weight in physical simulations. Then Collision Detection methods. Later in the year I'll have some performance numbers to indicate where a normal desktop CPU's spending it's cycles in a game engine, if anyone wants to prioritize their work. If you can get these parallelizable over 6 SPEs (e.g. what you find in a Linux-loaded COTS PS3), 3 PPC cores (Xbox 360) or 2 R5900s (PSP/PS2), you're in fantastic shape. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech
iain.denniston@blueyonder.co.uk wrote:
I played around with a SIMD abstraction layer for a while - the goal being to create a thin wrapper around SIMD code to allow simple compile time switches between different archtechtures SIMD implementations (particularly x86 vs. PowerPC vs. Software - due to Xbox 360 and PC).
Most good compilers already have that kind of thing using built-ins. Here is how to do it with GCC for example: http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Vector-Extensions.html#Vector-Ex...
Heh - sadly when doing Xbox developement a good compiler is something you can only dream of...
Well, isn't it a x86 architecture?
Yes - but you're not allowed to use a different compiler (VC or the highway). Least we weren't - there was a nice vectorising compiler we wanted to give a go, but were told no (and MS told them they couldn't actually market it as an Xbox compiler if memory serves). Plus I imagine you might have a bit of a headache trying to get the supplied/required libs to work. Anyways they were pretty strict about what they let loose on the platform. Although I should note that we were published by MS, which might make a difference - also it was a few years ago now, maybe they've changed... Iain
On 20/07/07, iain.denniston@blueyonder.co.uk <iain.denniston@blueyonder.co.uk> wrote:
Heh - sadly when doing Xbox developement a good compiler is something you can only dream of...
Well, isn't it a x86 architecture?
Yes - but you're not allowed to use a different compiler (VC or the highway). Least we weren't - there was a nice vectorising compiler we wanted to give a go, but were told no (and MS told them they couldn't actually market it as an Xbox compiler if memory serves). Plus I imagine you might have a bit of a headache trying to get the supplied/required libs to work. Anyways they were pretty strict about what they let loose on the platform.
Although I should note that we were published by MS, which might make a difference - also it was a few years ago now, maybe they've changed...
Wasn't the XBox 360 PowerPC based?
Peter Bindels wrote:
On 20/07/07, iain.denniston@blueyonder.co.uk <iain.denniston@blueyonder.co.uk> wrote:
Heh - sadly when doing Xbox developement a good compiler is something you can only dream of... Well, isn't it a x86 architecture? Yes - but you're not allowed to use a different compiler (VC or the highway). Least we weren't - there was a nice vectorising compiler we wanted to give a go, but were told no (and MS told them they couldn't actually market it as an Xbox compiler if memory serves). Plus I imagine you might have a bit of a headache trying to get the supplied/required libs to work. Anyways they were pretty strict about what they let loose on the platform.
Although I should note that we were published by MS, which might make a difference - also it was a few years ago now, maybe they've changed...
Wasn't the XBox 360 PowerPC based?
360 yes, Xbox no.
Michael Fawcett wrote: <SNIP>
P.S. - Where does the math part fit in? Another separate math library? Needs to be heavily optimized for speed, vectors and matrices need to be guaranteed contiguous in memory, need support for row major vs column major...
Create from scratch? Wait for the Matrix Template Library 4.0 which is "coming soon"? (I don't know if it does what is needed) Modify/Extend Boost.uBLAS and Boost.Quaternion?
There is also the Vector Image and Signal Processing Library (VSIPL). The original VSIPL is a C library while the newer VSIPL++ is C++. VSIPL++ also supports both serial processing and parallel processing. It was originally meant for high performance signal processing (e.g. radars) but its actually a general purpose library. If you're interested have a look at www.vsipl.org Glenn Schrader - MIT Lincoln Lab
Glenn Schrader wrote:
There is also the Vector Image and Signal Processing Library (VSIPL). The original VSIPL is a C library while the newer VSIPL++ is C++. VSIPL++ also supports both serial processing and parallel processing. It was originally meant for high performance signal processing (e.g. radars) but its actually a general purpose library. If you're interested have a look at www.vsipl.org
<shameless.plug> Incidentally, Sourcery VSIPL++ is now being ported to the Cell B.E. (e.g. PS3), too. (http://www.codesourcery.com/vsiplplusplus/) </shameless.plug> Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
on Tue Jul 17 2007, "Michael Fawcett" <michael.fawcett-AT-gmail.com> wrote:
P.S. - Where does the math part fit in? Another separate math library? Needs to be heavily optimized for speed, vectors and matrices need to be guaranteed contiguous in memory, need support for row major vs column major...
Create from scratch? Wait for the Matrix Template Library 4.0 which is "coming soon"? (I don't know if it does what is needed) Modify/Extend Boost.uBLAS and Boost.Quaternion?
MTL status update: I got swamped and very little happened on my end. In the meantime, Peter Gottschling has been working on his version of that library and announced to me that it is near completion. I haven't had time to review his work. However, I have little doubt that it is far superior to uBLAS. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
On 8/8/07, David Abrahams <dave@boost-consulting.com> wrote:
on Tue Jul 17 2007, "Michael Fawcett" <michael.fawcett-AT-gmail.com> wrote:
[snip]
Wait for the Matrix Template Library 4.0 which is "coming soon"? (I don't know if it does what is needed) Modify/Extend Boost.uBLAS and Boost.Quaternion?
MTL status update:
I got swamped and very little happened on my end. In the meantime, Peter Gottschling has been working on his version of that library and announced to me that it is near completion. I haven't had time to review his work. However, I have little doubt that it is far superior to uBLAS.
Where can I find anything about it? I looked and couldn't find anything about a version 4 of MTL.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com
Thanks, -- Felipe Magno de Almeida
That would be interesting, but, honestly, what - if any - pieces would be relevant to Boost? In general, there are a few areas that might be concrete and reapplicable enough to warrant Boost inclusion (or at least discussion): 1. Graphical user interface library. Such as win32gui for all (well, at least Linux, OS X and Win32..) platforms. There are a lot of potential input/inspiration in the game developer communities here. The GUI of a game is general enough (buttons, overlays, text, scrollbar...) that it might be isolated. 2. Geometry. We already have uBLAS, but there are definitely other matrix operations that would be needed for a proper 3D (sub) engine, and other non-matrix geometric operations. 3. 3D Rendering. Would it be possible to build an Ogre-like (in functionality and scope) layer using modern C++? I would probably start with wrapping one of these "Ogre" libraries. 4. AI. Well, the AI in games do not really have time to use advanced AI, but there are a host of interesting AI models one can Boostify, such as support vector learning (or other kernel methods), GA or at least a basic perceptron library :-) I have a hard time visualizing a Boost.GameEngine library, but it could be a separate effort, using Boost and its principles, and *perhaps* being able to borrow the name "Boost" somehow, but that is obviously up to Management. /David On Jul 17, 2007, at 1:34 PM, Felipe Magno de Almeida wrote:
Hi,
There were some little interest for this in another thread here in boost. So, who has any experience in game programming, it would be interesting to layout some requirements for a new engine and complaints from other engines. See if we can find out how a game engine should really be.
Regards, -- Felipe Magno de Almeida _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
On 7/17/07, David Bergman <David.Bergman@bergmangupta.com> wrote:
That would be interesting, but, honestly, what - if any - pieces would be relevant to Boost?
In general, there are a few areas that might be concrete and reapplicable enough to warrant Boost inclusion (or at least discussion):
1. Graphical user interface library. Such as win32gui for all (well, at least Linux, OS X and Win32..) platforms. There are a lot of potential input/inspiration in the game developer communities here. The GUI of a game is general enough (buttons, overlays, text, scrollbar...) that it might be isolated.
2. Geometry. We already have uBLAS, but there are definitely other matrix operations that would be needed for a proper 3D (sub) engine, and other non-matrix geometric operations.
3. 3D Rendering. Would it be possible to build an Ogre-like (in functionality and scope) layer using modern C++? I would probably start with wrapping one of these "Ogre" libraries.
4. AI. Well, the AI in games do not really have time to use advanced AI, but there are a host of interesting AI models one can Boostify, such as support vector learning (or other kernel methods), GA or at least a basic perceptron library :-)
I have a hard time visualizing a Boost.GameEngine library, but it could be a separate effort, using Boost and its principles, and *perhaps* being able to borrow the name "Boost" somehow, but that is obviously up to Management.
I think that's a very good, obvious break up of what is involved. Each of those pieces is very applicable to areas other than games. For instance, I use path planning, but not for games. I also use 3D rendering, but not for games. Same with geometry and matrix operations...I'm pretty sure anyone in Robotics or Aerospace & Defense would be able to make use of the above components. --Michael Fawcett
On 7/17/07, Michael Fawcett <michael.fawcett@gmail.com> wrote:
[snip]
I think that's a very good, obvious break up of what is involved. Each of those pieces is very applicable to areas other than games. For instance, I use path planning, but not for games. I also use 3D rendering, but not for games. Same with geometry and matrix operations...I'm pretty sure anyone in Robotics or Aerospace & Defense would be able to make use of the above components.
That's what modularity is for. Surely this will be a main concern for a project like this. So I wouldn't worry about it now. Just laying requirements (independently what domain the requirements are for) are important now. IMHO.
--Michael Fawcett
-- Felipe Magno de Almeida
I think the biggest problem with existing game engines is that they are... well big. I really like the idea of building games out of libraries that work well together to form emergent behavior. For true flexibility and portability it should be adaptable to run well on a software rendered ARM mobile device, a PS3 cell architecture, and a modern multicore PC. Error handling must be robust and should use modern facilities. Classes and algorithms should document on their exception guarantees. The strong guarantee should be the target of all classes and only weakened when deemed too restrictive of performance or implementation. A strong logging facility is crucial to easy debugging and verifying correctness. Concurrency support is crucial. The free lunch is over. This is one area where most current game engines fail horribly providing only O(1) or O(K) concurrency. 0(N) concurrency support should be targeted. Extensibility without direct source modification should be possible. Possibly through scripting (maybe Python or Lua) or plugins like the SoC extensions project will provide. Tools should be able to be supported without adding needless complexity and overhead to the final product and without a large amount of duplicated code and logic. Reflection and serialization support here are key. Documentation needs to be easy to write, easy to maintain, and up to date. Examples in documentation need to be tested via automation. Matrix and vector libraries would be helpful. They should optionally be able to take advantage of concurrency or specialized hardware. They should work with any type modeling a Real concept (fixed-point, floating-point, large numbers, etc) and should have well specified overflow, underflow, and precision loss handling so they can be used in application with large areas and for physical simulations. 2d and 3d rendering libraries and abstractions should be provided with optional hardware optimization support. There are many more interesting libraries that could be created but a full game engine sounds monolithic. Every real world game engine I've used so far is just that. But there are dozens of new libraries that could work well together to form game easily that are generally useful themselves. There will probably be some concern for developing code that works well on closed systems that are used for game development. I don't feel availability will be much of a problem but licensing and NDAs might become an issue. This needs to be seriously looked at. An interesting route would be to create examples of how to wire existing libraries such as Boost.Python, Boost.Asio, Boost.GIL, etc together to form a simple game with minimal special case code. These examples could be the base for real games. Thanks, Michael Marcin
On 7/17/07, David Bergman <David.Bergman@bergmangupta.com> wrote:
That would be interesting, but, honestly, what - if any - pieces would be relevant to Boost?
In general, there are a few areas that might be concrete and reapplicable enough to warrant Boost inclusion (or at least discussion):
1. Graphical user interface library. Such as win32gui for all (well, at least Linux, OS X and Win32..) platforms. There are a lot of potential input/inspiration in the game developer communities here. The GUI of a game is general enough (buttons, overlays, text, scrollbar...) that it might be isolated.
Since you went there... I'd just like to make a request, that if you all go ahead with making a generic boost GUI library, could you please try to make some sort of a generic UI layer underneath that? My reasoning here is that if someone is making a generic library, or portable application, in a lot of cases they don't necessarily need to tie their communication with the user to a particular modality (like visual/graphics). I.e., if I'm a portable app, I want to say "inform the user that foo is bar", and then it is up to the available UI modules to decide, depending on the context, whether a fancy flashing display saying "foo is bar!" will appear, whether it will be announced over the speakers, or whether the device will place a phone call to my mother and tell her that it is of utmost importance that she informs me that foo is bar because i can't seem to be reached any other way. Of course, this is a huge thing to do in itself, and admittedly, the game engine scenario is one of the places where you really need GUI and don't necessarily care for a generic UI layer. But, you mentioned Boost GUI... and I had to throw this out :-) Stjepan
Stjepan Rajko said: (by the date of Tue, 17 Jul 2007 11:38:25 -0700)
or whether the device will place a phone call to my mother and tell her that it is of utmost importance that she informs me that foo is bar because i can't seem to be reached any other way.
if foo is bar, then you can use only one unique identifier to write short code snippets. Which makes it a bit more difficult :) Unless you start using baz. -- Janek Kozicki |
Felipe Magno de Almeida wrote:
Hi,
There were some little interest for this in another thread here in boost. So, who has any experience in game programming, it would be interesting to layout some requirements for a new engine and complaints from other engines. See if we can find out how a game engine should really be.
(Sorry for striking a negative tone here.. but.. ) I feel that boost is mostly a set of low-level libraries, not a complete "engine" or "framework". Boost should perhaps aim at providing isolated components useful for this or that, but IMHO labeling a complete framework (which a good game-engine is, make no mistake there) as "the boost game engine" would probably do more ill than good for the Boost "trademark". Also, there's no single engine design that will fit all games, period. Anyone who's been doing any sort of serious game programming knows that. (This has got to do with evolvment in gaming hardware, game design and software patterns.) Therefore, I think it's just a futile project to put under the boost umbrella. Just imagine, what needs to be done to code up a good game today, like your average MMORPRG or something. :) There are numerous such parts: * content/anim/rendering (best left to others) * networking (asio + levels on top of that) * low-level server work (clustering, load balancing, etc) * high-level server work (accounts, chat, database) * active framework system (game object mgmnt) * auto update/versioning * state distribution * scripting (python? lua? lang-bind?) * AI (state machines, micro-threads, fuzzy-logic? learning? etc) Consider also, that development hardware is not accessible to Boost (i.e. GameCube, Wii & PS3) because it's very expensive. Or, you could make a kiddy-game engine for ppl to learn with on their PC, but there are a few of those out there already, in various stages. So, in summary, it's a nice idea of course, and I like the enthusiasm, but I think there are other Open Source projects well ahead of boost in trying to make a good extendable framework for game development and other things. Contributing to those and perhaps refactoring out parts for introduction as separate libraries into boost is IMO time better spent for everyone. (Let's not forget that the boost communitiy can't find a consensus on how to best design a math lib for 3d-graphics. Now imagine a whole game engine. :) Cheers, /Marcus
On 7/17/07, Marcus Lindblom <macke@yar.nu> wrote:
(Sorry for striking a negative tone here.. but.. )
I don't think it's negative.
Just imagine, what needs to be done to code up a good game today, like your average MMORPRG or something. :)
There are numerous such parts: * content/anim/rendering (best left to others) * networking (asio + levels on top of that) * low-level server work (clustering, load balancing, etc) * high-level server work (accounts, chat, database) * active framework system (game object mgmnt) * auto update/versioning * state distribution * scripting (python? lua? lang-bind?) * AI (state machines, micro-threads, fuzzy-logic? learning? etc)
Do you not think each of those components is useful enough to be its own library? I for one would love a path finding library, a load balancing library, state machines (already being worked on in Boost), and fuzzy-logic library. There's talk of a Boost Database library as well. I agree that a Boost "Game Engine" is not appropriate. What *is* appropriate, IMHO, are all the tools necessary to create a good game engine. You listed some of them above.
Consider also, that development hardware is not accessible to Boost (i.e. GameCube, Wii & PS3) because it's very expensive.
I know of of developers that have access to all of those systems, and also use Boost.
(Let's not forget that the boost communitiy can't find a consensus on how to best design a math lib for 3d-graphics. Now imagine a whole game engine. :)
I alluded to this in one of my other posts on this thread. In summary, my enthusiasm is not for an entire Boost game engine, but rather to stay in the spirit of Boost, and offer libraries that aid in the development of a modern game engine. --Michael Fawcett
On 7/17/07, Michael Fawcett <michael.fawcett@gmail.com> wrote:
[snip]
In summary, my enthusiasm is not for an entire Boost game engine, but rather to stay in the spirit of Boost, and offer libraries that aid in the development of a modern game engine.
That's also what I was aiming for.
--Michael Fawcett
-- Felipe Magno de Almeida
Michael Fawcett wrote:
On 7/17/07, Marcus Lindblom <macke@yar.nu> wrote:
Just imagine, what needs to be done to code up a good game today, like your average MMORPRG or something. :)
There are numerous such parts:
[snip]
Do you not think each of those components is useful enough to be its own library? I for one would love a path finding library, a load balancing library, state machines (already being worked on in Boost), and fuzzy-logic library. There's talk of a Boost Database library as well.
Yeah. That's what I meant.
I agree that a Boost "Game Engine" is not appropriate. What *is* appropriate, IMHO, are all the tools necessary to create a good game engine. You listed some of them above.
Consider also, that development hardware is not accessible to Boost (i.e. GameCube, Wii & PS3) because it's very expensive.
I know of of developers that have access to all of those systems, and also use Boost.
Yup, but can/would they allow those to be used for testing to support as official platforms?
In summary, my enthusiasm is not for an entire Boost game engine, but rather to stay in the spirit of Boost, and offer libraries that aid in the development of a modern game engine.
Ok. That sounds like a good idea. (as it was pretty much what I was saying too. :) However, part of the point I wanted to make is that what makes a game engine sucessful is not only how good it's components are, but also how well they integrate and how good the overall design is. But Boost is known for making components that integrate well into "anything else" (like the rhubarb pie application, my favourite generic software :), so that shouldn't be a problem. Cheers, /Marcus
On 7/18/07, Marcus Lindblom <macke@yar.nu> wrote:
Michael Fawcett wrote:
On 7/17/07, Marcus Lindblom <macke@yar.nu> wrote:
Consider also, that development hardware is not accessible to Boost (i.e. GameCube, Wii & PS3) because it's very expensive.
I know of of developers that have access to all of those systems, and also use Boost.
Yup, but can/would they allow those to be used for testing to support as official platforms?
Probably not since they're company resources. I just meant that there were definitely developers with that kind of access that also use Boost. They could act as users, and informal testers, but would not be able to monopolize an entire dev system to run regressions. I wonder if any of those companies (MS, Sony, Nintendo) would either donate a system to Boost Consulting, or run regressions on a dev system themselves. The IBM XL C/C++ compiler development team is doing something similar. Perhaps someone could convince the big 3 console companies that it is in their best interest to have Boost working on their console. It would certainly help consoles like the PS3 which already ship with extremely minimal support in terms of their SDK. --Michael Fawcett
On 7/18/07, Michael Fawcett <michael.fawcett@gmail.com> wrote:
[snip]
Perhaps someone could convince the big 3 console companies that it is in their best interest to have Boost working on their console. It would certainly help consoles like the PS3 which already ship with extremely minimal support in terms of their SDK.
Maybe after some years of development. I doubt it would happen soon, though.
--Michael Fawcett
-- Felipe Magno de Almeida
participants (18)
-
Cromwell Enage -
David Abrahams -
David Bergman -
Felipe Magno de Almeida -
Glenn Schrader -
iain.dennistonï¼ blueyonder.co.uk -
Janek Kozicki -
Jeremy Maitin-Shepard -
Lally Singh -
Malte Clasen -
Marcus Lindblom -
Mathias Gaunard -
Michael Fawcett -
Michael Marcin -
Peter Bindels -
Shintaro Sakahara -
Stefan Seefeld -
Stjepan Rajko