Page 1 of 2


Posted: Fri Jan 15, 2010 6:20 pm
by Kjell

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?


Posted: Fri Jan 15, 2010 9:23 pm
by diki
good idea!

how about:

- depth of parent/child hierarchy (min/max/avg), maybe different counts for functional & render trees?

also - wip of course, but - layout:
(please ignore text flip; the idea is to align the bar to the corresponding component)

Posted: Fri Jan 15, 2010 9:39 pm
by Kjell

I've gone back and forth on horizontal / vertical bars a couple of times already :wink: 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 8)


Posted: Sat Jan 16, 2010 5:31 pm
by y offs et
You can prog, but you can't hide.

Posted: Sat Jan 16, 2010 6:39 pm
by diki

this might also be a useful tool to remind us of scarcely-used components we might have forgotten about ;)

Posted: Sat Jan 16, 2010 7:51 pm
by jph_wacheski
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?

Posted: Mon Jan 18, 2010 6:10 pm
by Kjell

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 ).

Anyway, almost done :)


Posted: Mon Jan 18, 2010 7:28 pm
by VilleK
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 :)

Posted: Tue Jan 19, 2010 4:23 pm
by Kjell

@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?


Posted: Tue Jan 19, 2010 4:45 pm
by y offs et
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.

Posted: Tue Jan 19, 2010 6:24 pm
by Kjell

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?


Posted: Tue Jan 19, 2010 7:35 pm
by diki
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 ;)

Posted: Tue Jan 19, 2010 8:21 pm
by y offs et
on the other hand it does say something about how somebody structures their project
True. So far as I can see, your project is about programming style, rather than functionality or efficiency.

depth is already properly incremented by counting the parent node, another increment is not necessary... i think ;)
True, however I have situations with two or three components activated with a single "on".

Posted: Tue Jan 19, 2010 10:50 pm
by Kjell

@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 :wink:


Posted: Wed Jan 20, 2010 7:38 pm
by diki
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.