Analyser
Moderator: Moderators
Analyser
In order to simplify the process of finding out what and how people are using ZGameEditor, I'm writing a small browser-based "application" ( HTML5 + Javascript ) that takes a .zgeprog, analyses it, and generates a compact visual report.
Currently I'm assembling the following data ..
- Filename / Filesize / Last_Modified
- Component chart listing how often each Component has been used.
- Data chart listing the size of all imported Mesh / Bitmap / Sound Data.
- Script chart listing the number of characters used in ZLibrary / ZExpression / MeshExpression etc.
Anything else?
K
- Attachments
-
- WIP ( Needs color coding and scale indication )
- Report.gif (1.92 KiB) Viewed 30151 times
I've gone back and forth on horizontal / vertical bars a couple of times already Ideally the colors and fixed order of the components should eventually be enough, but we'll see ..
Depth might be a little tricky, since Events / Models / Groups / States etc would have to be excluded .. counting how many components are used in each individual Event ( OnLoad / OnUpdate / OnRender etc. ) is a excellent idea though ~
+ It's funny to see how various projects by the same person generate similar reports
K
- Attachments
-
- Ville.gif (5.73 KiB) Viewed 30121 times
- jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
@diki - Turned out that generating a depth chart wasn't all that difficult afterall ( and produces quite interesting results ). The only question is what filter rule(s) to apply exactly.
Right now I'm ignoring every non-Component* node that is empty or of which the parent doesn't have more then 1 child ( see attached for example, blue is a entry and red is a exception ) .. but I'd like some feedback on this.
*Also, I'm ignoring "Group" as a entry ( but it does count as 1 depth step ) .. but perhaps I should just completely ignore everything that's not a Component?
K
- Attachments
-
- Filter.gif (3.08 KiB) Viewed 30067 times
@y_offs_et,
You're right, it doesn't do anything for a game / application you make using ZGE, but the question is whether or not it should be represented in a depth chart. My initial thought was no as well .. on the other hand it does say something about how somebody structures their project.
Any opinions / idea's about the non-Component nodes?
K
You're right, it doesn't do anything for a game / application you make using ZGE, but the question is whether or not it should be represented in a depth chart. My initial thought was no as well .. on the other hand it does say something about how somebody structures their project.
Any opinions / idea's about the non-Component nodes?
K
hmmm, the 'Group' component is really mostly used to introduce a (functionally neutral) order/hierarchy into otherwise non-hierarchical collections (the Content-tree mostly ;)) ... i think it would be nice to get the option of having it counted; it could tell a lot about programming style.
regarding the depth-counting of non-component nodes: i think if you omit the 'Children'-node of the 'Group', you should also omit the 'OnTrue' & 'OnFalse'-nodes of the 'Condition' (and also other non-component nodes, like the different 'On...'-events in the 'Model'). when counting for depth, all they really do is increment the count for the containing components - depth count does not discriminate their functionality. since the contained components' depth is already properly incremented by counting the parent node, another increment is not necessary... i think ;)
about the layout: did you think about different ways of encoding the informations on 'depth' and 'event type' into the chart yet? one could imagine coloring the bars differently in the corresponding relations. you could also approach the data the other way and show how many of each component there are for each eventtype, or at each depth level... oh, the possibilities! data viz is such a cool thing to think about ;)
regarding the depth-counting of non-component nodes: i think if you omit the 'Children'-node of the 'Group', you should also omit the 'OnTrue' & 'OnFalse'-nodes of the 'Condition' (and also other non-component nodes, like the different 'On...'-events in the 'Model'). when counting for depth, all they really do is increment the count for the containing components - depth count does not discriminate their functionality. since the contained components' depth is already properly incremented by counting the parent node, another increment is not necessary... i think ;)
about the layout: did you think about different ways of encoding the informations on 'depth' and 'event type' into the chart yet? one could imagine coloring the bars differently in the corresponding relations. you could also approach the data the other way and show how many of each component there are for each eventtype, or at each depth level... oh, the possibilities! data viz is such a cool thing to think about ;)
True. So far as I can see, your project is about programming style, rather than functionality or efficiency.on the other hand it does say something about how somebody structures their project
True, however I have situations with two or three components activated with a single "on".depth is already properly incremented by counting the parent node, another increment is not necessary... i think
@y_offs_et : Yea it's about the source only .. not performance / efficiency ( unfortunately ). Such a tool would be great to have as well, but it would have to be build on top of the ZGE Engine to be accurate ( and thus written in Pascal ).
@diki : That's the difficulty .. choosing a standard of what data to show .. and how. When everybody starts using their own settings, it'll be impossible to easily compare results.
And I went with your suggestion to simply only include Components in the depth processing
K
- Attachments
-
- Depth.gif (3.05 KiB) Viewed 30040 times
kjell: i was tempted to link this earlier, but that last graphic is hitting the spot :) - edward tufte on the topic of sparklines. there are other interesting bits on tufte's site, too; some practices are questionable, though, so it's a good idea to trust your own viewing habits for guidance.