Re: Reflection in game engine (c++)
Douglas Cox <[email protected]> Tue, 19 Mar 2013 16:40:14 -0400
| Newsgroups | gmane.games.devel.sweng |
|---|---|
| Message-ID | <CA+i4re6_-sfYRWHKdOFyO-SbRTk=FBUBmWA1mCsWZoyes7+dpA@mail.gmail.com> |
--===============0521798487== Content-Type: multipart/alternative; boundary=047d7b33ca20ce38f204d84d1c92 --047d7b33ca20ce38f204d84d1c92 Content-Type: text/plain; charset=ISO-8859-1 "That system continues to work with dlc and patches, but if your patch needs to change a type, you'd probably be sending new data files using that type anyway." You'd think so, but we've had a few examples of this already in the last few years. Only a few new instances needed to override a default value. "We usually read these files on a separate thread, and it's comforting not to be making lots of allocs that might fragment memory if interleaved with allocations that might happen on other threads." This seems like it would happen regardless unless your main 'runtime' allocations are coming from a different memory pool. I probably should have mentioned that I was also talking about overriding values on 'prefabs' with this same system. So when we override just a few position/rotations it is saving considerably more than flattening the entire prefab into the level file for instance. Sorry I should have made this a separate thread. -Doug On Tue, Mar 19, 2013 at 4:02 PM, Adrian Stephens <[email protected]>wrote: > > We flatten our data, so reading data in-game is just a question of > allocating enough space (from the different flavors of memory - normal, > video, sound, etc) reading the data and patching the results. During > development there is the possibility of reading some out-of-date types, and > those need to be converted during the patch-up, which means they do take > extra memory. The shipped code shouldn't have to do that. > > That system continues to work with dlc and patches, but if your patch > needs to change a type, you'd probably be sending new data files using that > type anyway. > > We usually read these files on a separate thread, and it's comforting not > to be making lots of allocs that might fragment memory if interleaved with > allocations that might happen on other threads. > > Regarding storage space - if you compress your binary files, as we do, any > often-used default values are likely to compress away very easily; and > since our data is flattened and compressed during development, there's no > additional code to worry about. > > Adrian > > On Mar 19, 2013, at 9:09 AM, Douglas Cox wrote: > > One issue that we were thinking about after coming up with a file format > using reflection that allows for data-derivation, versioning, etc., and > that basically looks like "field name + field type + value" (only > overriding/saving values that were changed) was: "Is it worth trying to > optimize or flatten this for final builds?" > > At first we were just going to write a different serializer and write out > a flattened set of in-order values thinking that our types would never > change. But with DLC and patches, this is not the case. We may release a > patch that changes a type (adds or removes a field) and existing > (non-patched) data files would fail to load. > > Another reason to not flatten is that it is quite possible that the final > data in the 'overrides only' format would be much less storage than the > flattened format. And of course not having to write additional code that's > only run in final builds is a plus. > > Anyone else have thoughts on this or do it differently? > > -- > And as far as the debate over where to put the type info, all I can say is > that having the compiler generate it and having 1 file (a single ".x" > instead of ".h" and ".cpp" and ".inl") for code has been great. I > definitely do not miss bouncing back and forth between .h and .cpp files. > So if you do start wandering into the land of making your own language for > just reflection, you might see what other benefits you can get from doing > more in it than just that. > -- > > -Doug > > > On Tue, Mar 19, 2013 at 12:07 AM, Mike Shaver <[email protected]>wrote: > >> I wanted to just have one place that things were declared, and for that >> to be with real code rather in a separate "please don't edit this no matter >> how much VC++ tells you this is the definition" file. >> >> My point is really that it's over-constraining the problem to choose one >> format that is both fast+compact enough for runtime use, and >> flexible+straightforward enough to bend into all the parts of the tool >> pipeline. >> >> It's the work of 5 lines of Python to go from JSON to XML or CSV or .ini >> files or whatever. That someone has linked the format parser into a dozen >> different software environments is indeed an advantage that I would take >> seriously. I generally don't know what my tools are going to be until I've >> written them, so free option value is pretty nice. >> >> I've done the "IDL to headers and packed metadata files" thing, and it >> was pretty annoying (and error-prone) to wire it into even a half-dozen >> straight-C tools. I may be overreacting to that experience, but mutatis >> mutandis I very much prefer one tiny exporter and then letting tools >> transcode however they want. >> >> Mike >> >> phone-typed >> >> On Mar 18, 2013, at 7:58 PM, Adrian Stephens <[email protected]> >> wrote: >> >> >> So you're writing macros to turn your C structures into data, building >> them into a library, linking it with your exporter and running the exporter >> to generate a script-format of the structures. Which, then has to be >> parsed by your tools. I honestly didn't mean that to sound so negative, >> but wouldn't it have been easier the other way round - start with a simple >> domain-specific language to define your types and spit out C header files? >> >> The PHP thing works because you're proposing outputting JSON, which >> somebody presumably has already linked into it. If that sort of thing is >> difficult you could certainly output JSON at the same time you output C >> header files, or I suppose you could probably even use JSON *as* your >> script format. >> >> >> On Mar 18, 2013, at 5:26 PM, Mike Shaver wrote: >> >> When I did this for a non-game app, I defined it with self-aware, >> strong-AI macros, and compiled the resulting data into a shared library. >> The app (game) linked against the library, as did one important tool: the >> exporter. It was a wee little program that dumped the compiled metadata to >> an interchange format. Today I would choose JSON or XML. The build process >> would regenerate metadata.json whenever metadata.so changed, and extending >> it to multiple libraries/output files was straightforward. >> >> Runtime reflection formats have many constraints that tool-interchange >> formats don't, and tool formats often want things the runtime abhors. Put >> the line-numbers in the output and remix with git-blame output to tell you >> who last changed an entity? Sure. Web explorer of the resources, without >> linking the parser library into PHP...I'll be over here. >> >> I would similarly not use Collada files at runtime. >> >> phone-typed >> >> >> On Mar 18, 2013, at 4:30 PM, Adrian Stephens <[email protected]> >> wrote: >> >> >> I'm glad we're still talking about this - I think it's important and I >> wanted to add my own observations: >> >> The macro/template approach to reflection only applies to one side of the >> data/code interface. If all you need to do is serialize runtime data to be >> read back in by runtime code, then you're ok; but if you want to access >> that metadata from an external tool, you either have to recompile the tool >> or plugin when anything changes, or write something that parses that code. >> >> If you're going to have to write a parser anyway, it seems to me you >> might as well use it for both code and data views. Which means you can use >> a more natural syntax for your structure definitions that even >> non-programmers can use. >> >> To map this back into your C++ code, you can pretty trivially write out >> header files containing typedefs that correspond to the metadata, and >> generate whatever you need to allow the runtime to interpret serialized >> data. This also address the separation of code and assets: we don't want >> artists having to sync the code, and this keeps the data definitions with >> the assets that they define. >> >> This is what I do, anyway. I have a data language, which defines types, >> and which can also be used to define data, and all data is stored using >> these definitions. This includes bitmaps, sounds, models, etc. The data >> language is separated from the data representation so this doesn't imply >> that bitmaps are stored in a script-like array of colors - but it does mean >> that tools can use the reflection system on more classes of data than just >> small gameplay entities. And when distinctions like that are removed, and >> all things are treated the same way, lots of clever things just fall out. >> >> Some other random thoughts: >> As far as I can see, all C++ needs to allow full reflection is some sort >> of fieldsof(T) operator that enumerates the fields of a structure. e.g. >> (typed straight into email, so probably bollocks - and not representative >> of my actual system!) >> >> struct metadata { >> enum TYPE {INT, PTR, ARRAY, STRUCT} type; >> metadata(TYPE &_type) : type(_type) {} >> }; >> template<typename A, typename... B> struct md_fields : md<A>, >> md_fields<B> {}; >> template<typename T> struct md : metadata, md_fields<fieldsof(T)> { md() >> : metadata(STRUCT) {} }; >> template<typename T> struct md<T*> : metadata { md<T> t; md() : >> metadata(PTR) {} }; >> template<typename T, int N> struct md<T[N]> : metadata { int n; md<T> t; >> md() : metadata(ARRAY), n(N) {} }; >> template<> struct md<int> : metadata { md() : metadata(INT) {} }; >> >> template<typename T> metadata *get_md(const T &t) { static md<T> m; >> return &m; } >> >> >> >> Adrian Stephens >> >> On Mar 18, 2013, at 10:45 AM, Douglas Cox wrote: >> >> That sounds pretty similar to the goals of the engine that we're working >> on -- basically faster iteration times for everyone (this includes engine >> programmers as well). >> >> All of our code (including the compiler) is written in a C#-like >> language, so we have perfect reflection from that. Attributes are pretty >> much required for providing additional information to property editors for >> things like valid ranges of a field or notifications of a property change >> (most of which can go away in Final builds). >> >> Another thing to consider may be allowing for data derivation. This can >> save quite a bit of work when the need for copies of objects come up that >> only need one or two properties changed. If you pick a serialization >> format for the editable data that knows about the data (fieldtype + >> fieldname + value), it makes it a lot easier to get this working. >> >> In the past, we've used Macros and they worked fine. They're a bit more >> annoying to extend with optional parameters and you have to repeat the >> field/property name, but that's not terrible since you can generally get it >> down to compile-time errors if you get something wrong (other than >> forgetting to add a new field). >> >> -Doug >> >> >> >> On Fri, Mar 15, 2013 at 3:45 AM, Tinco Andringa <[email protected]> wrote: >> >>> I think the point of the discussion is to not just assume C++ isn't >>> going to do it. As far as I understand the goal is to have the ability >>> to develop tools that aid programmers and artist in iterating rapidly. >>> This means for artists that they can swap artwork in at runtime or >>> quickly boot the game from a serialized state with new artwork, not >>> just on his/her own computer but also over a network to perhaps a >>> console. For programmers this may mean that they can view the game >>> state easily, launch the game in various states easily, swap in/out >>> scripts easily, maybe even change code without fully recompiling or >>> even restarting the game. >>> >>> Am I missing something important? >>> >>> On Fri, Mar 15, 2013 at 8:33 AM, Massimo Del Zotto <[email protected]> >>> wrote: >>> > I have limited experience but I have been very impressed by the >>> separation >>> > provided by scripting languages. >>> > Considering the goals: >>> > >>> > My goal is to have fast iteration times, both artists and programmers >>> > >>> > It appears to me C++ isn't going to do it. Especially on the artist >>> side of >>> > the thing. >>> > >>> > By the way, I would like to have an insight on how this reflection >>> > information is to be used. If it is used to simulate duck typing I'd >>> use a >>> > tool which supports duck typing natively. >>> > >>> > Massimo >>> > >>> > _______________________________________________ >>> > Sweng-Gamedev mailing list >>> > [email protected] >>> > >>> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com >>> > >>> _______________________________________________ >>> Sweng-Gamedev mailing list >>> [email protected] >>> >>> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com >>> >> >> _______________________________________________ >> Sweng-Gamedev mailing list >> [email protected] >> >> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com >> >> >> _______________________________________________ >> Sweng-Gamedev mailing list >> [email protected] >> >> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com >> >> _______________________________________________ >> Sweng-Gamedev mailing list >> [email protected] >> >> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com >> >> >> _______________________________________________ >> Sweng-Gamedev mailing list >> [email protected] >> >> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com >> >> >> _______________________________________________ >> Sweng-Gamedev mailing list >> [email protected] >> >> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com >> >> > _______________________________________________ > Sweng-Gamedev mailing list > [email protected] > http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com > > > > _______________________________________________ > Sweng-Gamedev mailing list > [email protected] > http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com > > --047d7b33ca20ce38f204d84d1c92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">"<span style=3D"font-family:arial,sans-serif;font-siz= e:13px">That system continues to work with dlc and patches, but if your pat= ch needs to change a type, you'd probably be sending new data files usi= ng that type anyway."</span><div> <span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di= v><div style><span style=3D"font-family:arial,sans-serif;font-size:13px">Yo= u'd think so, but we've had a few examples of this already in the l= ast few years. =A0Only a few new instances needed to override a default val= ue.</span></div> <div style><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>= </span></div><div style><span style=3D"font-family:arial,sans-serif;font-si= ze:13px">"</span><span style=3D"font-family:arial,sans-serif;font-size= :13px">We usually read these files on a separate thread, and it's comfo= rting not to be making lots of allocs that might fragment memory if interle= aved with allocations that might happen on other threads."</span></div= > <div style><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>= </span></div><div style><span style=3D"font-family:arial,sans-serif;font-si= ze:13px">This seems like it would happen regardless unless your main 'r= untime' allocations are coming from a different memory pool.</span></di= v> <div style><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>= </span></div><div style><span style=3D"font-family:arial,sans-serif;font-si= ze:13px">I probably should have mentioned that I was also talking about ove= rriding values on 'prefabs' with this same system. =A0So when we ov= erride just a few position/rotations it is saving considerably more than fl= attening the entire prefab into the level file for instance.</span></div> <div style><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>= </span></div><div style><span style=3D"font-family:arial,sans-serif;font-si= ze:13px">Sorry I should have made this a separate thread.</span></div><div = style> <span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di= v><div style><span style=3D"font-family:arial,sans-serif;font-size:13px">-D= oug</span></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmai= l_quote"> On Tue, Mar 19, 2013 at 4:02 PM, Adrian Stephens <span dir=3D"ltr"><<a h= ref=3D"mailto:[email protected]" target=3D"_blank">adrians@isopodlabs.= net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div style=3D"word-wrap:break-word"><div><br></div><div>We flatten our data= , so reading data in-game is just a question of allocating enough space (fr= om the different flavors of memory - normal, video, sound, etc) reading the= data and patching the results. =A0During development there is the possibil= ity of reading some out-of-date types, and those need to be converted =A0du= ring the patch-up, which means they do take extra memory. =A0The shipped co= de shouldn't have to do that.</div> <div><br></div><div><div>That system continues to work with dlc and patches= , but if your patch needs to change a type, you'd probably be sending n= ew data files using that type anyway.</div></div><div><br></div><div><div> <div>We usually read these files on a separate thread, and it's comfort= ing not to be making lots of allocs that might fragment memory if interleav= ed with allocations that might happen on other threads.</div></div></div> <div><br></div><div>Regarding storage space - if you compress your binary f= iles, as we do, any often-used default values are likely to compress away v= ery easily; and since our data is flattened and compressed during developme= nt, there's no additional code to worry about.</div> <span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Adrian</= div></font></span><div><div class=3D"h5"><br><div><div>On Mar 19, 2013, at = 9:09 AM, Douglas Cox wrote:</div><br><blockquote type=3D"cite"><div dir=3D"= ltr">One issue that we were thinking about after coming up with a file form= at using reflection that allows for data-derivation, versioning, etc., and = that basically looks like "field name + field type + value" (only= overriding/saving values that were changed) was: "Is it worth trying = to optimize or flatten this for final builds?"<div> <br></div><div>At first we were just going to write a different serializer = and write out a flattened set of in-order values thinking that our types wo= uld never change. =A0But with DLC and patches, this is not the case. =A0We = may release a patch that changes a type (adds or removes a field) and exist= ing (non-patched) data files would fail to load.</div> <div><br></div><div>Another reason to not flatten is that it is quite possi= ble that the final data in the 'overrides only' format would be muc= h less storage than the flattened format. =A0And of course not having to wr= ite additional code that's only run in final builds is a plus.</div> <div><br></div><div>Anyone else have thoughts on this or do it differently?= </div><div><br></div><div>--</div><div>And as far as the debate over where = to put the type info, all I can say is that having the compiler generate it= and having 1 file (a single ".x" instead of ".h" and &= quot;.cpp" and ".inl") for code has been great. =A0I definit= ely do not miss bouncing back and forth between .h and .cpp files. =A0So if= you do start wandering into the land of making your own language for just = reflection, you might see what other benefits you can get from doing more i= n it than just that.</div> <div>--</div><div><br></div><div>-Doug</div></div><div class=3D"gmail_extra= "><br><br><div class=3D"gmail_quote">On Tue, Mar 19, 2013 at 12:07 AM, Mike= Shaver <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>I wanted to just have= one place that things were declared, and for that to be with real code rat= her in a separate "please don't edit this no matter how much VC++ = tells you this is the definition" file.</div> <div><br></div><div>My point is really that it's over-constraining the = problem to choose one format that is both fast+compact enough for runtime u= se, and flexible+straightforward enough to bend into all the parts of the t= ool pipeline.</div> <div><br></div><div>It's the work of 5 lines of Python to go from JSON = to XML or CSV or .ini files or whatever. That someone has linked the format= parser into a dozen different software environments is indeed an advantage= that I would take seriously. I generally don't know what my tools are = going to be until I've written them, so free option value is pretty nic= e.</div> <div><br></div><div>I've done the "IDL to headers and packed metad= ata files" thing, and it was pretty annoying (and error-prone) to wire= it into even a half-dozen straight-C tools. I may be overreacting to that = experience, but mutatis mutandis I very much prefer one tiny exporter and t= hen letting tools transcode however they want.</div> <div><br></div><div>Mike<br><br>phone-typed<div><br></div></div><div><div><= div>On Mar 18, 2013, at 7:58 PM, Adrian Stephens <<a href=3D"mailto:adri= [email protected]" target=3D"_blank">[email protected]</a>> wrote:= <br> <br></div><blockquote type=3D"cite"><div><div><br></div><div>So you're = writing macros to turn your C structures into data, building them into a li= brary, linking it with your exporter and running the exporter to generate a= script-format of the structures. =A0Which, then has to be parsed by your t= ools. =A0I honestly didn't mean that to sound so negative, but wouldn&#= 39;t it have been easier the other way round - start with a simple domain-s= pecific language to define your types and spit out C header files?</div> <div><br></div><div>The PHP thing works because you're proposing output= ting JSON, which somebody presumably has already linked into it. =A0If that= sort of thing is difficult you could certainly output JSON at the same tim= e you output C header files, or I suppose you could probably even use JSON = *as* your script format.</div> <div><br></div><br><div><div>On Mar 18, 2013, at 5:26 PM, Mike Shaver wrote= :</div><br><blockquote type=3D"cite"><div dir=3D"auto"><div>When I did this= for a non-game app, I defined it with self-aware, strong-AI macros, and co= mpiled the resulting data into a shared library. The app (game) linked agai= nst the library, as did one important tool: the exporter. It was a wee litt= le program that dumped the compiled metadata to an interchange format. Toda= y I would choose JSON or XML. The build process would regenerate metadata.j= son whenever metadata.so changed, and extending it to multiple libraries/ou= tput files was straightforward.</div> <div><br></div><div>Runtime reflection formats have many constraints that t= ool-interchange formats don't, and tool formats often want things the r= untime abhors. Put the line-numbers in the output and remix with git-blame = output to tell you who last changed an entity? Sure. Web explorer of the re= sources, without linking the parser library into PHP...I'll be over her= e.</div> <div><br></div><div>I would similarly not use Collada files at runtime.</di= v><div><br>phone-typed<div><br></div></div><div><br>On Mar 18, 2013, at 4:3= 0 PM, Adrian Stephens <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> wrote:<br> <br></div><blockquote type=3D"cite"><div><div><br></div><div>I'm glad w= e're still talking about this - I think it's important and I wanted= to add my own observations:</div><div><br></div><div>The macro/template ap= proach to reflection only applies to one side of the data/code interface. = =A0If all you need to do is serialize runtime data to be read back in by ru= ntime code, then you're ok; but if you want to access that metadata fro= m an external tool, you either have to recompile the tool or plugin when an= ything changes, or write something that parses that code.</div> <div><br></div><div>If you're going to have to write a parser anyway, = =A0it seems to me you might as well use it for both code and data views. = =A0Which means you can use a more natural syntax for your structure definit= ions that even non-programmers can use.</div> <div><br></div><div>To map this back into your C++ code, you can pretty tri= vially write out header files containing typedefs that correspond to the me= tadata, and generate whatever you need to allow the runtime to interpret se= rialized data. =A0This also address the=A0separation of code and assets: we= don't want artists having to sync the code, and this keeps the data de= finitions with the assets that they define.</div> <div><br></div><div>This is what I do, anyway. =A0I have a data language, w= hich defines types, and which can also be used to define data, and all data= is stored using these definitions. =A0This includes bitmaps, sounds, model= s, etc. =A0The data language is separated from the data representation so t= his doesn't imply that bitmaps are stored in a script-like array of col= ors - but it does mean that tools can use the reflection system on more cla= sses of data than just small gameplay entities. =A0And when distinctions li= ke that are removed, and all things are treated the same way, lots of cleve= r things just fall out.</div> <div><br></div><div>Some other random thoughts:</div><div>As far as I can s= ee, all C++ needs to allow full reflection is some sort of fieldsof(T) oper= ator that enumerates the fields of a structure. =A0e.g. (typed straight int= o email, so probably bollocks - and not representative of my actual system!= )</div> <div><br></div><div>struct metadata {</div><div><span style=3D"white-space:= pre-wrap"> </span>enum TYPE {INT, PTR, ARRAY, STRUCT} type;</div><div><span= style=3D"white-space:pre-wrap"> </span>metadata(TYPE &_type) : type(_t= ype) {}</div> <div>};</div><div>template<typename A, typename... B> struct md_field= s : md<A>, md_fields<B> {};</div><div>template<typename T>= ; struct md :=A0metadata,=A0md_fields<fieldsof(T)> { md() : metadata(= STRUCT) {} };</div> <div>template<typename T> struct md<T*> : metadata {=A0md<T&= gt; t;=A0md() : metadata(PTR) {} };</div><div>template<typename T, int N= > struct md<T[N]> : metadata { int n; md<T> t; md() : metada= ta(ARRAY), n(N) {} };</div> <div>template<> struct md<int> : metadata { md() : metadata(INT= ) {} };</div><div><br></div><div>template<typename T> metadata *get_m= d(const T &t) { static md<T> m; return &m; }</div><div><br> </div><div><br></div><div><br></div><div>Adrian Stephens</div><br><div><div= >On Mar 18, 2013, at 10:45 AM, Douglas Cox wrote:</div><br><blockquote type= =3D"cite"><div dir=3D"ltr">That sounds pretty similar to the goals of the e= ngine that we're working on -- basically faster iteration times for eve= ryone (this includes engine programmers as well).<div> <br></div><div>All of our code (including the compiler) is written in a C#-= like language, so we have perfect reflection from that. =A0Attributes are p= retty much required for providing additional information to property editor= s for things like valid ranges of a field or notifications of a property ch= ange (most of which can go away in Final builds).</div> <div><br></div><div>Another thing to consider may be allowing for data deri= vation. =A0This can save quite a bit of work when the need for copies of ob= jects come up that only need one or two properties changed. =A0If you pick = a serialization format for the editable data that knows about the data (fie= ldtype + fieldname + value), it makes it a lot easier to get this working.<= /div> <div><br></div><div>In the past, we've used Macros and they worked fine= . =A0They're a bit more annoying to extend with optional parameters and= you have to repeat the field/property name, but that's not terrible si= nce you can generally get it down to compile-time errors if you get somethi= ng wrong (other than forgetting to add a new field).</div> <div><br></div><div>-Doug</div><div><br></div></div><div class=3D"gmail_ext= ra"><br><br><div class=3D"gmail_quote">On Fri, Mar 15, 2013 at 3:45 AM, Tin= co Andringa <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">I think the point of the discussion is to no= t just assume C++ isn't<br> going to do it. As far as I understand the goal is to have the ability<br> to develop tools that aid programmers and artist in iterating rapidly.<br> This means for artists that they can swap artwork in at runtime or<br> quickly boot the game from a serialized state with new artwork, not<br> just on his/her own computer but also over a network to perhaps a<br> console. For programmers this may mean that they can view the game<br> state easily, launch the game in various states easily, swap in/out<br> scripts easily, maybe even change code without fully recompiling or<br> even restarting the game.<br> <br> Am I missing something important?<br> <div><div><br> On Fri, Mar 15, 2013 at 8:33 AM, Massimo Del Zotto <<a href=3D"mailto:ma= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<b= r> > I have limited experience but I have been very impressed by the separa= tion<br> > provided by scripting languages.<br> > Considering the goals:<br> ><br> > My goal is to have fast iteration times, both artists and programmers<= br> ><br> > It appears to me C++ isn't going to do it. Especially on the artis= t side of<br> > the thing.<br> ><br> > By the way, I would like to have an insight on how this reflection<br> > information is to be used. If it is used to simulate duck typing I'= ;d use a<br> > tool which supports duck typing natively.<br> ><br> > Massimo<br> ><br> </div></div><div><div>> _______________________________________________<= br> > Sweng-Gamedev mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a><br> > <a href=3D"http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-m= idnightryder.com" target=3D"_blank">http://lists.midnightryder.com/listinfo= .cgi/sweng-gamedev-midnightryder.com</a><br> ><br> _______________________________________________<br> Sweng-Gamedev mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a><br> <a href=3D"http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnig= htryder.com" target=3D"_blank">http://lists.midnightryder.com/listinfo.cgi/= sweng-gamedev-midnightryder.com</a><br> </div></div></blockquote></div><br></div> _______________________________________________<br>Sweng-Gamedev mailing li= st<br><a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a><br><a href=3D"http://lists.= midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com" target=3D"_= blank">http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightry= der.com</a><br> </blockquote></div><br></div></blockquote><blockquote type=3D"cite"><div><s= pan>_______________________________________________</span><br><span>Sweng-G= amedev mailing list</span><br><span><a href=3D"mailto:[email protected]= idnightryder.com" target=3D"_blank">[email protected]</= a></span><br> <span><a href=3D"http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-= midnightryder.com" target=3D"_blank">http://lists.midnightryder.com/listinf= o.cgi/sweng-gamedev-midnightryder.com</a></span><br></div></blockquote></di= v> _______________________________________________<br>Sweng-Gamedev mailing li= st<br><a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a><br><a href=3D"http://lists.= midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com" target=3D"_= blank">http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightry= der.com</a><br> </blockquote></div><br></div></blockquote><blockquote type=3D"cite"><div><s= pan>_______________________________________________</span><br><span>Sweng-G= amedev mailing list</span><br><span><a href=3D"mailto:[email protected]= idnightryder.com" target=3D"_blank">[email protected]</= a></span><br> <span><a href=3D"http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-= midnightryder.com" target=3D"_blank">http://lists.midnightryder.com/listinf= o.cgi/sweng-gamedev-midnightryder.com</a></span><br></div></blockquote></di= v> </div></div><br>_______________________________________________<br> Sweng-Gamedev mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a><br> <a href=3D"http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnig= htryder.com" target=3D"_blank">http://lists.midnightryder.com/listinfo.cgi/= sweng-gamedev-midnightryder.com</a><br> <br></blockquote></div><br></div> _______________________________________________<br>Sweng-Gamedev mailing li= st<br><a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a><br><a href=3D"http://lists.= midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com" target=3D"_= blank">http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightry= der.com</a><br> </blockquote></div><br></div></div></div><br>______________________________= _________________<br> Sweng-Gamedev mailing list<br> <a href=3D"mailto:[email protected]">Sweng-Gamedev@list= s.midnightryder.com</a><br> <a href=3D"http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnig= htryder.com" target=3D"_blank">http://lists.midnightryder.com/listinfo.cgi/= sweng-gamedev-midnightryder.com</a><br> <br></blockquote></div><br></div> --047d7b33ca20ce38f204d84d1c92-- --===============0521798487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sweng-Gamedev mailing list [email protected] http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com --===============0521798487==--