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.
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
Cool,. looks to be quite interesting. wundering if it could be integerated into the editor? or if you keep building nifty ZGE related web apps perhaps adding them all to a page somewhere., . are you working on some net based game project?
You could integrate it in a similar fashion as the help file, but i don't really see the point ... and it doesn't work online ( without uploading the .zgeproj at least, which is not what you want ).
Interesting, reminds me of heuristics used by virus analyzers to detect programs that are functionally but not syntactically duplicates. And yes, I seem to use the same style every time
@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?
I would agree that "Group" looks like a depth step in the project tree, but in the processing, is it really? I don't think grouping affects the hierarchy of processing, or anything, other than visually making order.
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?
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 ;)
@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
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.
Ideally the colors and fixed order of the components should eventually be enough, but we'll see ..
