Draft for review: Unity Scene Queries: A Fluent Interface Experiment

[Yggy King]

Hi folks,

I've been messing around with fluent interface design in C# with Unity, and would love to hear what you think about this so far ...

Unity Scene Queries: A Fluent Interface Experiment

I've worked through various gotchas in wrapping a fluent interface around Unity's various "Find" and "Get" methods for scene traversal. Results are tested and demonstrated with Unity's NUnit test tool framework. Next steps are to add more of the code and start poking under the hood at performance and memory allocation.

The draft is a google doc -- for feedback you can either reply to this email, or select a bit of text in the document and press Ctrl-Alt-M to add a comment. (And if anyone has tips for cleanly converting a google doc to WordPress I'd love to hear!)

Feedback welcome!

many thanks,

Yggy

[Francisco Tufró]

As part of Fowler's advocates I love the idea!

I'm eager to see the performance tests! Let me know when you continue working on the post.

--
You received this message because you are subscribed to the Google Groups "AltDevAuthors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Francisco Tufró

Indie Game Developer / CSD / Musician

in...@franciscotufro.com
http://franciscotufro.com

http://stillbeingsimple.com

http://simplex-engine.com

[rf...@tbrf.net]

So, this is interesting from a technical point of view, but the biggest
problem you've got IMO is applicability. I mean, take the example query
you give near the beginning of the document:

"Find me all sibling objects that have a child called 'myChild' and a
parent with a BoxCollider."

For starters, if these are sibling objects then they all share a parent
so there's no point testing the parent of each one. But beyond that, I'm
having trouble thinking of queries in my codebase that are this complex.
We deliberately *avoid* making them this complex because we generally
don't want behaviour that's based on setup spread across multiple
objects, mixing names/tags/components, etc. It's too error-prone.

I imagine that this was a constructed example, designed to show off a
complex query - but I think you need to use a more real-world example.
Otherwise it looks like you're building all this up to solve a
complexity problem that doesn't actually exist in the real world.

- Richard

On 2014-07-13 08:20, Yggy King wrote:
> Hi folks,
> I've been messing around with fluent interface design in C# with
> Unity, and would love to hear what you think about this so far ...

> Unity Scene Queries: A Fluent Interface Experiment [1]

>
> I've worked through various gotchas in wrapping a fluent interface
> around Unity's various "Find" and "Get" methods for scene traversal.
> Results are tested and demonstrated with Unity's NUnit test tool
> framework. Next steps are to add more of the code and start poking
> under the hood at performance and memory allocation.
>
> The draft is a google doc -- for feedback you can either reply to
> this email, or select a bit of text in the document and press
> Ctrl-Alt-M to add a comment. (And if anyone has tips for cleanly
> converting a google doc to WordPress I'd love to hear!)
>
> Feedback welcome!
>
> many thanks,
> Yggy
>

> --
> You received this message because you are subscribed to the Google
> Groups "AltDevAuthors" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to altdevauthor...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout [2].
>
>
> Links:
> ------
> [1]
> https://docs.google.com/document/d/1bIem71QT7_p61NtfOmrXyly49sp7yPvUyB9Q743cc1A/edit?usp=sharing
> [2] https://groups.google.com/d/optout

[Yggy King]

Good point Richard, I will admit that the example is contrived ... and not particularly well-contrived. I'll try and contrive a better one ;-)

I also agree that this is a solution looking for a problem. I didn't admit that in the post, but as long as I call it an "experiment" I felt like I could get away with it. To be totally honest I'm more interested in the fluent interface design process, and in learning to analyze and eliminate spurious allocations from enumerators than in the final API itself.

That said, I hope that once I have a robust search interfaces I will find uses for it. One possibility that crossed my mind is to data-drive the queries as part of a visual design toolbox such as uScript -- "find all enemies with 10m of the blast impact and deal 20 damage." Another potential application is data validation -- "find all animation components beneath a game object with a rigid body and ensure there is a forward, back, left and right animation clip attached".

But yeah, it is a bit of a science project. Does that make it wrong? Should I pitch it differently?

Thanks again for taking the time to provide feedback.

cheers,

Yggy

send an email to altdevauthors+unsubscribe@googlegroups.com.

 For more options, visit https://groups.google.com/d/optout [2].


Links:
------
[1]
https://docs.google.com/document/d/1bIem71QT7_p61NtfOmrXyly49sp7yPvUyB9Q743cc1A/edit?usp=sharing
[2] https://groups.google.com/d/optout

--
You received this message because you are subscribed to the Google Groups "AltDevAuthors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthors+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Galanakis]

While as Richard points out, complex queries are a significant code/design smell when designing or working in a realtime system (especially when performance is important), the ability to robustly query has equally huge implications for tooling and offline work. In my experience, few things have led to the development of better tools (and more robust content) than the ability to query data easily. This is true of engine tools that work with rendering data, to asset metadata systems, to even PyMEL in Maya which allows modern programming patterns. So I'd focus the benefits mostly on the tooling and data/asset management side.

[Yggy King]

Thanks Rob, that's a good suggestion.

I'm also considering splitting the article into pieces, as it feels like it will grow rather long, especially if I include a useful amount of code.

Something like this ... 

Part 1 - fluent interface intro, Linq as an example, applicability of Linq to a Unity scene enumerator

Part 2 - building a fluent Unity query API with custom enumerators and predicates

Part 3 - performance and memory analysis and optimization

and with Rob's encouragement:

Part 4 - automated data validation with scene queries and Unity Test Tools

Thoughts? Do you prefer big articles that cover everything or multi-part articles that go step by step?

Thanks all,

Yggy 

On Sun, Jul 13, 2014 at 7:40 PM, Rob Galanakis <rob.ga...@gmail.com> wrote:

While as Richard points out, complex queries are a significant code/design smell when designing or working in a realtime system (especially when performance is important), the ability to robustly query has equally huge implications for tooling and offline work. In my experience, few things have led to the development of better tools (and more robust content) than the ability to query data easily. This is true of engine tools that work with rendering data, to asset metadata systems, to even PyMEL in Maya which allows modern programming patterns. So I'd focus the benefits mostly on the tooling and data/asset management side.

--

You received this message because you are subscribed to the Google Groups "AltDevAuthors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthor...@googlegroups.com.

[Adam Martin]

Likewise, I saw a inferior solution to an already-solved problem, and stopped reading. I think it would help enormously to be more explicit about your "not solving the problems, rather: playing around with new techniques" aspect.

As it stands, in the examples you start with it quickly appears to be hard to read and very hard to debug (both with and without debugger), which is enough for me to thibk:

"I will never use this. Too difficult, too error prone, too dangerous. I already have super-simple query systems to hand that are fast and logical, and better than this"

...and move on without ever appreciating the rest of it.

To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthor...@googlegroups.com.

[Richard Fine]

On 14/07/2014 09:35, Adam Martin wrote:

I think it would help enormously to be more explicit about your "not solving the problems, rather: playing around with new techniques" aspect.

I agree. I think it's fine to write stuff that is just playing around with new techniques, and you stand to cover some interesting details in the process (regarding stuff like allocations), but a lot of readers are going to interpret the article as implying that this is something that should be implemented on their own projects. You don't want that implication. You might want to state not just that this is you playing around with a technique, but even some reasons why you might *not* want to build this sort of thing in a real-world scenario.

This said, I think you might immediately get more applicability if you step back from the method chaining aspect - keep it as a design goal but don't spend a lot of time on it - and instead focus on building the individual map/filter aspects as efficiently as possible. While I don't want to build a query like your example one at the beginning, I do want to build simpler ones, and the individual pieces of your larger chains can still be useful at that level.

You do need to make a clear case for your approach over existing LINQ-based approaches, though. Is "Where(Has.Tag("Player"))" really so much better than "Where(t => t.gameObject.CompareTag("Player"))" that it's worth doing a load of work? Are there benefits to be had beyond readability? Is it, at least, no *worse* than the current approaches in terms of memory and CPU usage?

BTW, if you weren't aware, using 'foreach' with Unity's C# compiler always allocates a small amount of GCable heap memory (about 48 bytes, IIRC). I've been working with them on a patch to fix this but it's not live yet. So, be careful... you may want to either avoid foreach, or compile your query library in Visual Studio instead and just drop it into Unity as a DLL.

- Richard

send an email to altdevauthor...@googlegroups.com.

 For more options, visit https://groups.google.com/d/optout [2].


Links:
------
[1]
https://docs.google.com/document/d/1bIem71QT7_p61NtfOmrXyly49sp7yPvUyB9Q743cc1A/edit?usp=sharing
[2] https://groups.google.com/d/optout

--
You received this message because you are subscribed to the Google Groups "AltDevAuthors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "AltDevAuthors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yggy King]

Good feedback, thanks Adam and Richard. I will work up another draft that either finds compelling uses or focuses on the exploratory nature of the investigation and lessons learned. Regarding the foreach garbage generated by Mono, I am aware, but generally I compile in Visual Studio. While I'm looking into IL analysis I'll touch on that issue, thanks for the reminder.

cheers,

Yggy