EntityXMLSpawn discussion
2 views
Skip to first unread message
Glidias
Jun 13, 2010, 4:47:30 AM6/13/10
to SWFt Game Framework
Basically, I had a Github mail conversation with Mike Cann about the
possibility of an entity serialization implementation in Swft,
somewhat inspired by PushButton engine's XML-serialization package,
but without the numerous inline property referencing (and inline node
properties) found in PushButton's serialization implementation.
The specs can be found here:
http://wiki.github.com/Glidias/CityFly/xml-serialization-and-fcss-specifications
In short, I came up with a system to allow spawning of entities via
XML configurations (and varying stylings through CSS property
settings, and the ability to add components to entities). However,
based on my experiences with this and what MikeCann said, it's obvious
that XML/CSS configurations will have a disadvantage when it comes to
type-safety, particularly during refactoring.
How I'd reply to such known aspects:
Yup, what you said clear pointed out a fact that it's easy to end up
having misspellings when writing class names in an external file.
Even though test-checks can be made at runtime to check the validity
of the XML and it's ability to spawn entities correctly, it's done at
runtime rather than compile time.
Generally though, when it comes to any dependency, it must always be
checked at runtime, that's why SwiftSuspenders will throw errors to
inform the user of missing dependencies. However, in the context of
Swft, we also need to know which entity is currently being tested. The
EntityMap doesn't really provide this functionality (and it shouldn't,
because it assumes all dependencies are met). Doing this in
EntityXMLSpawn isn't really required either, because one can use the
following method with try/catch as shown below to test that all of
your concrete entity classes can be created within Swft:
bc. public static function
testEntities(entityMap:IEntityMap, ...args):void {
for each (var classe:Class in args) {
var chkEntityClassName:String = getQualifiedClassName(classe);
try {
entityMap.createEntity( classe );
}
catch(err:Error) {
throw new Error("Entity creation failed for:
"+chkEntityClassName + "\n");
}
}
}
// And somewhere in your app, list out all your entity classes
testAllEntities(
entityMap,
ClassA,
ClassB,
ClassC
);
After all, eventually you'll need to list out all your coded classes
anyway in order for them to be compiled. So, doing testing in
EntityXMLSpawn (with it's initXML configuration) isn't really
required, through you can play around with varied stylings/component-
additions without having to recompile under a xml-based node id.
Generally, that's the purpose of EntityXMLSpawn, varying stylings/
settings without having to re-compile (which is actually the premise
behind F*CSS/Flash Camouflage) actually, which actually defers a lot
from what most RobotLegs people tend to prefer (which is compiled
configurations).
However, it's very true that with *any* given XML/CSS property
configuration, one of the issues often faced is that in the event you
refactor your classes ( change of variable/classnames names and
such...), your CSS properties would have to change to match those
values (Of course, F*CSS applicator provides hooks which you can
extend to throw runtime warnings/errors for unmatched CSS properties,
but again this only done at runtime), So, in the sense, hardcoding
operations/settings through extended classes or factory methods would
obviously provide type-safety at compile time. After all, why lose the
benefits of a compile-time language?
Additionally, in order to spawn an entity, you need to reference this
by some arbitrary id in your code. If you had a concrete factory
method for this, you get type-safety and clearly defined parameters,
albeit you have to spend time coding that process, it allows you to
clearly document the process of objection creation within the scope of
a factory method as well. When you have an external XML configuration
which is used for your "spawn" node implementation, it is assumed the
node id is already there. The coder would have to write
"spawn('someIDWhichIhopeDoesExists') within the code, and hope
everything runs fine "magically". If you change the XML configuration
ids, than your code would have to change as well. If you re-factor
your code, than the XML/CSS would have to change to match that. In
short, the benefits of custom coded compile-time classes/factory-
methods are too good to ignore. To some, the only reasonable basis for
XML configurations is to be done at the end of the app-development
cycle, where you just one a list of end-user settings to be used in
varied circumstances (saved games, user options, etc.), which are
simply tailor-made to the finalised game.
possibility of an entity serialization implementation in Swft,
somewhat inspired by PushButton engine's XML-serialization package,
but without the numerous inline property referencing (and inline node
properties) found in PushButton's serialization implementation.
The specs can be found here:
http://wiki.github.com/Glidias/CityFly/xml-serialization-and-fcss-specifications
In short, I came up with a system to allow spawning of entities via
XML configurations (and varying stylings through CSS property
settings, and the ability to add components to entities). However,
based on my experiences with this and what MikeCann said, it's obvious
that XML/CSS configurations will have a disadvantage when it comes to
type-safety, particularly during refactoring.
How I'd reply to such known aspects:
Yup, what you said clear pointed out a fact that it's easy to end up
having misspellings when writing class names in an external file.
Even though test-checks can be made at runtime to check the validity
of the XML and it's ability to spawn entities correctly, it's done at
runtime rather than compile time.
Generally though, when it comes to any dependency, it must always be
checked at runtime, that's why SwiftSuspenders will throw errors to
inform the user of missing dependencies. However, in the context of
Swft, we also need to know which entity is currently being tested. The
EntityMap doesn't really provide this functionality (and it shouldn't,
because it assumes all dependencies are met). Doing this in
EntityXMLSpawn isn't really required either, because one can use the
following method with try/catch as shown below to test that all of
your concrete entity classes can be created within Swft:
bc. public static function
testEntities(entityMap:IEntityMap, ...args):void {
for each (var classe:Class in args) {
var chkEntityClassName:String = getQualifiedClassName(classe);
try {
entityMap.createEntity( classe );
}
catch(err:Error) {
throw new Error("Entity creation failed for:
"+chkEntityClassName + "\n");
}
}
}
// And somewhere in your app, list out all your entity classes
testAllEntities(
entityMap,
ClassA,
ClassB,
ClassC
);
After all, eventually you'll need to list out all your coded classes
anyway in order for them to be compiled. So, doing testing in
EntityXMLSpawn (with it's initXML configuration) isn't really
required, through you can play around with varied stylings/component-
additions without having to recompile under a xml-based node id.
Generally, that's the purpose of EntityXMLSpawn, varying stylings/
settings without having to re-compile (which is actually the premise
behind F*CSS/Flash Camouflage) actually, which actually defers a lot
from what most RobotLegs people tend to prefer (which is compiled
configurations).
However, it's very true that with *any* given XML/CSS property
configuration, one of the issues often faced is that in the event you
refactor your classes ( change of variable/classnames names and
such...), your CSS properties would have to change to match those
values (Of course, F*CSS applicator provides hooks which you can
extend to throw runtime warnings/errors for unmatched CSS properties,
but again this only done at runtime), So, in the sense, hardcoding
operations/settings through extended classes or factory methods would
obviously provide type-safety at compile time. After all, why lose the
benefits of a compile-time language?
Additionally, in order to spawn an entity, you need to reference this
by some arbitrary id in your code. If you had a concrete factory
method for this, you get type-safety and clearly defined parameters,
albeit you have to spend time coding that process, it allows you to
clearly document the process of objection creation within the scope of
a factory method as well. When you have an external XML configuration
which is used for your "spawn" node implementation, it is assumed the
node id is already there. The coder would have to write
"spawn('someIDWhichIhopeDoesExists') within the code, and hope
everything runs fine "magically". If you change the XML configuration
ids, than your code would have to change as well. If you re-factor
your code, than the XML/CSS would have to change to match that. In
short, the benefits of custom coded compile-time classes/factory-
methods are too good to ignore. To some, the only reasonable basis for
XML configurations is to be done at the end of the app-development
cycle, where you just one a list of end-user settings to be used in
varied circumstances (saved games, user options, etc.), which are
simply tailor-made to the finalised game.
Glidias
Jun 13, 2010, 5:04:25 AM6/13/10
to SWFt Game Framework
The missing web links which might be of interest:
PushButton Serialization - http://pushbuttonengine.com/2009/02/components-and-serialization/
FCSS - http://fcss.flashartofwar.com/
__________
Also, corrections to the try/catch code sample in the first post:...
it should also trace out the original captured error message as well,
so we know what dependency errors might be found within the scope of a
particular tested entity class.
try {
entityMap.createEntity( classe );
}
catch(err:Error) {
throw new Error("Entity creation failed for:
"+chkEntityClassName + "\n" + err.message);
}
PushButton Serialization - http://pushbuttonengine.com/2009/02/components-and-serialization/
FCSS - http://fcss.flashartofwar.com/
__________
Also, corrections to the try/catch code sample in the first post:...
it should also trace out the original captured error message as well,
so we know what dependency errors might be found within the scope of a
particular tested entity class.
try {
entityMap.createEntity( classe );
}
catch(err:Error) {
throw new Error("Entity creation failed for:
}
Michael Cann
Jun 13, 2010, 10:48:19 AM6/13/10
to swft-fr...@googlegroups.com
Hi Glidias,
Cheers for bringing the conversation over to the list, I think everyone should benefit from hearing your thoughts and work :)
Just to reiterate what I have said before but for the benefit of the list:
I totally agree that there are benefits for having some sort of external settings file method for tweaking game properties without compiling. Be that with XML, FCSS, SQLite, AS3 Excel or just a simple ini file.
For larger projects with multiple people working at the same time it becomes essential that others can tweak properties while the coders work on implementing new features. For example, the game I am working on at work at the moment is a large semi-multiplayer Facebook game (think Farmville). The game has alot of content with hundreds of different entities with many components each with properties that need to be tweaked and modified continuously as the game is developed.
Obviously it would be a bad idea to compile that data into the client as custom components for each entity type so we decided to use the PBE reccomended system of using an external XML file for serialising entity templates. What we ended up with however is a very large number of XML files describing entity templates and the components that make them up. As the people doing the data tweaking tended not to be programmers it was very difficult for them to know which XML file to edit and then scroll through thousands of lines to find the xml-node they want to change.
So this was a problem. In the end what we decided to do was write an converter that took an Excel spreadsheet as input and then kicked out a single very large XML file that defines all the entity templates. It works, it means that the non-coders can now tweak their data to thier hearts content in the Excel spreadsheet, even write macros that change multiple values at once. It is however a rather convoluted system that involves many nasty hard-codes, duplicated code, magic strings and generally difficult to change. So for the next game (which I hope to base on swft) I hope to do away with the whole XML serialisation step and just load a compressed Excel document or SQLite DB into the game at runtime and do lookups as each entity is requested.
It appears I have gone off on a tangent a little. The point I was trying to make is that I agree games need some sort of game customisation for the non-coders to tweak but I dont think entities and components should be defined in the external files (as is done in PBE). Those sort of things should always be hard-coded as sub-types of Entity and dependencies satisfied at compile time.
As I have mentioned before I dislike magic strings which is why I prefer Signals over Events, RobotLegs over PureMVC and (hopefully) strict-typed SWFt over dynamic-name-lookup-PBE.
Despite all that however I think your work on the subject is excellent and there is still alot more that could be done. Do you think there are many use-cases for being able to define an entities component composition from XML over strict-typing it? Also do you think there are many many use-cases for having dynamic component addition / subtraction atall?
Cheers,
Mike
Jos Yule
Jun 13, 2010, 11:07:17 AM6/13/10
to swft-fr...@googlegroups.com
I just wanted to add a quick comment about this issue.
This is one place where i think PBE looses people. The XML file used for setup, while very powerful, is also very hard to figure out for new users.
I think having 1 way of defining the entities and components, so that the users of the framework know right away that these objects are created "in code", but there is the possibility to tweak their properties via external methods, is the way to go.
I love PBE's google spreadsheet plug-in - i think that is the bomb. Something like that for SWFt, but only for property definitions, would be excellent. Or, some method of allowing for that kind of externally settable values for entities, components, and their properties.
peace
jos
Wex
Jun 14, 2010, 5:38:06 PM6/14/10
to SWFt Game Framework
Having used XML myself internally for our studio I would massively
recommend using it to describe as much as possible about the game and
it's entities.
We've been developing tools and systems for a while now with this
approach and it has formed a very flexible system for the J2ME (mobile
phone) platform. We've also made good progress building the same
systems for Flash and iPhone; all of which use the same XML files.
Can't discuss details, but I can hopefully give some good pointers...
One of the most important steps in our toolchain is a program that
primarily 'composes' the source XML into final XML. Source XML is that
which is created by scripters, level designers, animators. All such
game-content in our system is described in XML. It's all human
readable and verbose, possibly with comments and other content that
isn't directly needed by the game. While editing it by hand is simple
it is also labourious, so a number of simple editors have been made
that load and save this Source XML. Being a standardised interface to
create the XML it's much more likely that it'll be well formed and
without structural human error.
The composing-tool takes the Source XML and performs all manner of
checks on it against set schemas giving useful errors and warnings
where nessecary. Then it takes a step particularly important for J2ME
which is the obfuscation of the xml. This means each node and property
is dropped down to at most two-letters (much smaler file size, and
faster loading). At the same time the composor also generates a static
class file with all the xml-tags names in it which can be used by the
engine and it's inheritors, this means that no matter what the tags
are refactored to; the values in static class file simply change to
reflect this.
This all, of course, requires recompilation of the engine when the XML
changes.
When I started designing the system a few years ago I thought that
recompiling all the time would be a major bottleneck for the XML-based-
developers. However, as it turns out it has proven to be an emergently
wise descision. Rather than shielding them from the engine as much as
possible it opens the engine up to them instead; giving much more
flexibility and knowledge distribution. Most of the engine code for
them is read-only, but at least they can read it and learn what's
going on. During development this can be much more valuable than a
precompiled library with 'documentation'.
Having the composure step also opens up possibilities such as pre-
processing within Source XML, allowing only certain tags to proporgate
through to certain platforms. On the other side it allows us to make
#define style preprocessing in the engine such that when a certain
node isn't used in the XML; it's code is processed out of the engine
(this has proved to be incredibly powerful). The composer can also
generate lists - quite often required by clients - of all the images
or text in the game because everything goes through it.
The system's still evolving though, and I've only covered a few bits
of it here. The XML schemas are the most recent addition and pretty
simple right now. In the near future I'll be expanding in this area
such that the schemas are generated from one XML file to describe
another. It all sounds a bit circular when I put it like that :/
though it fits together in my head okay ;).
In brief, I'd recommend:
+ XML to describe everything
+ Editor-Tools for complex or large files
+ Composure-Tool to move assets and content from original source into
engine
I don't mean to state that this is how SWFt should work; just giving
another viewpoint to mull over. I hope it proves useful.
--Wex
Technical Director
Creative North
recommend using it to describe as much as possible about the game and
it's entities.
We've been developing tools and systems for a while now with this
approach and it has formed a very flexible system for the J2ME (mobile
phone) platform. We've also made good progress building the same
systems for Flash and iPhone; all of which use the same XML files.
Can't discuss details, but I can hopefully give some good pointers...
One of the most important steps in our toolchain is a program that
primarily 'composes' the source XML into final XML. Source XML is that
which is created by scripters, level designers, animators. All such
game-content in our system is described in XML. It's all human
readable and verbose, possibly with comments and other content that
isn't directly needed by the game. While editing it by hand is simple
it is also labourious, so a number of simple editors have been made
that load and save this Source XML. Being a standardised interface to
create the XML it's much more likely that it'll be well formed and
without structural human error.
The composing-tool takes the Source XML and performs all manner of
checks on it against set schemas giving useful errors and warnings
where nessecary. Then it takes a step particularly important for J2ME
which is the obfuscation of the xml. This means each node and property
is dropped down to at most two-letters (much smaler file size, and
faster loading). At the same time the composor also generates a static
class file with all the xml-tags names in it which can be used by the
engine and it's inheritors, this means that no matter what the tags
are refactored to; the values in static class file simply change to
reflect this.
This all, of course, requires recompilation of the engine when the XML
changes.
When I started designing the system a few years ago I thought that
recompiling all the time would be a major bottleneck for the XML-based-
developers. However, as it turns out it has proven to be an emergently
wise descision. Rather than shielding them from the engine as much as
possible it opens the engine up to them instead; giving much more
flexibility and knowledge distribution. Most of the engine code for
them is read-only, but at least they can read it and learn what's
going on. During development this can be much more valuable than a
precompiled library with 'documentation'.
Having the composure step also opens up possibilities such as pre-
processing within Source XML, allowing only certain tags to proporgate
through to certain platforms. On the other side it allows us to make
#define style preprocessing in the engine such that when a certain
node isn't used in the XML; it's code is processed out of the engine
(this has proved to be incredibly powerful). The composer can also
generate lists - quite often required by clients - of all the images
or text in the game because everything goes through it.
The system's still evolving though, and I've only covered a few bits
of it here. The XML schemas are the most recent addition and pretty
simple right now. In the near future I'll be expanding in this area
such that the schemas are generated from one XML file to describe
another. It all sounds a bit circular when I put it like that :/
though it fits together in my head okay ;).
In brief, I'd recommend:
+ XML to describe everything
+ Editor-Tools for complex or large files
+ Composure-Tool to move assets and content from original source into
engine
I don't mean to state that this is how SWFt should work; just giving
another viewpoint to mull over. I hope it proves useful.
--Wex
Technical Director
Creative North
Jos Yule
Jun 15, 2010, 9:32:51 AM6/15/10
to swft-fr...@googlegroups.com
wow, you system sounds pretty amazing!
I love the idea of compiling the XML into class files - that's something i'd be interested in exploring myself.
However, i think the thing to keep in mind for SWFt is for it to allow for these kinds of tool-useages, but not be designed specifically for any one of them.
If i remember correctly, one of the goals for SWFt was to get away from magic-strings, and rely more on static compilation. Now, that's not to say that there isn't room for settable properties, or other factory like objects to be settable via XML (or any external data source), but the core "objects" were to be composed in AS files, rather then via XML. Again, this is only how i remember it, and this goal may have changed since.
My take is that SWFt wants to be "like" RL - a simple to understand framework for building component based games. Not a monolithic stack of complex tools. You might _get_ that toolset which builds on SWFt, in the same way that there are complex tools built on top of RL.
Once again, this is simply my two cents. And i would agree that having externalized data is key to being able to quickly turn around game tweaks and changes. I'm not sure that that should be "baked" into SWFt however.
j
ps. thanks for sharing how you use XML and the development of your tool chain - fascinating stuff!
Yuriy Kulkoff
Jun 15, 2010, 10:18:08 AM6/15/10
to swft-fr...@googlegroups.com
http://code.google.com/p/asaxb/
Here is something what about your discussion
--
С уважением,
Кульков Юрий
ICQ: 429-517-060
mail: mur...@gmail.com
Here is something what about your discussion
--
С уважением,
Кульков Юрий
ICQ: 429-517-060
mail: mur...@gmail.com
Michael Cann
Jun 15, 2010, 1:25:56 PM6/15/10
to swft-fr...@googlegroups.com
Ello All,
Cheers for that insight into how Creative North do things Wex. Sounds like you have a good scripting-like setup there. However it does rely on a good suite of home-grown tools to make it accessible for the non-coders especially if your game is very large like ours and your XML files size in the MBs not KBs :P
As Jos said however I think swft should aim to supply the means not the method. By that I think the SWFt core should be as lightweight as possible (very much like RL) and just provide a framework with which to base an engine ontop of. This means less code to think about, write and maintain. Also I would have to be very careful with how much actual functional engine code I could contribute due to being full-time employed in the industry.
That ASAXB lib looks interesting Yuriy. If I understand it correctly its just an XML serialiser / deserialiser nothing fancy?
2010/6/15 Yuriy Kulkoff <mur...@gmail.com>
Yuriy Kulkoff
Jun 15, 2010, 1:58:57 PM6/15/10
to swft-fr...@googlegroups.com
Yeah, it sims look like ASAXB can help store entities, vos ... etc in XML files and restore them back to not just plain Object or Array types.
So it not simple serializer/deserializer and can be helpfull for recreate classes without parsing XMLs "by hand".
So it not simple serializer/deserializer and can be helpfull for recreate classes without parsing XMLs "by hand".
15 июня 2010 г. 21:25 пользователь Michael Cann <mike...@gmail.com> написал:
Reply all
Reply to author
Forward
0 new messages