[EDIT]First draft of Introduction is now open for comment[/EDIT] [EDIT2]The revised architecture diagram is now open for comment[/EDIT2]
The Big, Strange How-To has been the standard (and, er, only) textbook on Strange since its inception. But with the exception of a handful of corrections and the addition of a couple of new features, it has remained largely unchanged since it was first written way back alongside v0.5. With the upcoming release of v1.0, I reckon that it’s high time for a proper update.
With the benefit of hindsight and whisky, I’m looking at everything in the BSHT to see what needs updating, adding, or even removing. And that’s where you come in, my friends!
What could we explain better? What has frustrated you most, especially when you were first learning? I especially want to concentrate on the new user: what can we do to flatten the steepness of our learning curve?
Here are my ideas so far. Please leave comments below and I’ll keep this post updated with your input.
Things to add to the Big Strange How To
Re-work the Introduction
- Make the tone easier and more approachable
- Add a reference to list of supported platforms
- Add reference to Is Strange Right for You?
New section: opening Strange for the first time (walk-through)
- Explain the broad structure of the repo.
- Walk-through of MyFirstProject project
- Walk-through of MultipleContexts project
Updated section: Signals
- Beef up the Signals section.
- Add explanation for the (new to v1.0) ListensTo feature.
- Change all examples (across all of BSHT) from EventDispatcher to Signals.
Updated section: Mapping across Contexts
This section is really thin. Let’s clarify the concept and the execution. Particularly, explain the reasoning behind multiple Contexts, along with practical info on how to structure them.
Updated section: Reflection
I don’t want to confuse a new user with too much about this…but then the understanding the principles is important.
New section: Pools
Explain how the Pools extension works
New section: Promises
Explain the (new to v1.0) Promises package
New section: Implicit Bindings
Explain the ImplicitBind package
New section: runtime bindings
Explain the (new to v1.0) feature runtime bindings
New mini-section: Strange for extending Unity
A mini-section because it will essentially just link to a separate document specifically about using the (new to v1.0) Editor extension. The current plan is for the Editor extension to live outside the main Strange repo as an optional plug-in.
New section: Testing tutorial
Explain how to run unit tests and write your own.
Enumerate Exceptions for each package
In each package, list and explain each of the thrown errors. In an appendix at the end of the document, put all Exceptions in one place for easy reference.
Replace artwork
All that pesky text art (—–>). Let’s grow up and use PNGs or SVGs or something.
Tutorial
Lots of people asking for something more like a step-by-step tutorial. Particularly questions about uGUI. Should this be here or a separate document?
New Section: Platform Specific Issues
A request in the comments to explain iOS trampolines. Compile a set of other platform-specific gotchas?
New Section: Best Practices
Some cohesive section on Dos/Don’ts when using Strange.
Errata
Add named injection for constructors
How this will work
I’ll going to create the new BSHT as a Google Doc at first. I’ll edit this post and provide a link so everyone can weigh in. In the meantime, feel free to leave comments and ideas.
StrangeIoC 
It’s been awhile since I last looked at the guide, so forgive me if this is already covered, but I would delve further into how to organize a Unity project using Strange, specifically different examples of how you can use multiple ContextViews. When I first started using Strange, I always thought you could only have one ContextView per scene, which isn’t the case.
Maybe the example project highlights this well enough? Anyways, that’s my immediate suggestion. I’ll try to come up with more.
Thanks Neeko! Excellent suggestions. I’ll see what I can do to include this.
This is awesome! So I would recommend talking about how to actually wire your Strange views to Unity’s new UI and how to deal with events dispatched from them. What I do is create a view class without a mediator, add that view class to the gameobject/prefab, add public methods to the view class like OnDrag, OnPointer, etc.., add an event trigger component to the gameobject, and then point the event triggers to those public methods in the view class which when the event is triggered, the view class sends the appropriate signals out. I have been using strange since 9/14 so I am not an expert, nor am I sure if I am doing everything correctly but I can say things are working pretty well so far.
I would also talk about A) what the hell is a trampoline B) how to adjust this for iOS and C) best ways to mitigate this getting out of control. I have had to up my trampolines twice because my app kept crashing. I am still unsure what these even mean myself.
I will post more suggestions if I come across something else. Thanks again for creating this and updating it 🙂
Great ideas…particularly about explaining trampolines. The new UI stuff is (to my thinking) not really any different than dealing with any other bit of standard Unity code…but lots of people ask about it, so you’re probably correct. See also my reply to Baca below about adding a “more complete example.”
The BSHT is my bible for a while. And like in the holy bible, it is not always easy to get concrete answers.
As you says, get in StrangeIoC could be… well, strange. Principally because the inversion of dependences is a big step in the developper toolbox.
Last time I had to embrace a such concept was on AngularJS+MeteorJS. All their concepts are really disruptive for classical webdev but I found their tutorial (http://angularjs.meteor.com/tutorial) really well explained. The goal is to make a real app, with real life features (social media login/signup, user profil, google map, etc.)
That makes the learning step very concrete and the fact is I could instantly use their tutorial for my own app. Just in one pass.
So one thing I think that could be very very very helpful is the real game case with a real life UI (nested views, multi templates per views, nGUI, uGUI…), real services (multiplayer service, twitter connect, fb connect) and real models management (factory, pool, collections of collections, properties mapping).
My 2cts.
I definitely agree to this although it’s a lot more work, but in the end very helpful.
I really like this idea…but it’s definitely a LOT more work. On the order of making a game AND a document AND a class syllabus. I think that in the interests of getting Strange v1 out sometime this year, I might have to keep the BSHT a little more restrained. But possibly post-release we could undertake a tutorial like this?
I had a hard time with cross-context bindings. I didn’t understand the underlying idea, and to be honest, I still don’t understand it very well, and I use them everywhere. The thing is, bindings disappear when loading a new scene, unless you persist the main context game object, binding all cross-context content to it. But then they all persist, even the ones that were bound from other, scene-specific contexts that have pertinence only to specific scenes.
What I’d like to have is a main context game object that persists through different scenes. It would be capable of cross-context bindings, which also persist if bound inside that context. But then there would be other contexts capable of cross-context bindings, which do not persist between scenes. For that, it seems, cross-context bindings would have to be stored in their own contexts, rather than all of them in the “firstContext.”
So is it the idea that I don’t understand (as in a better way of doing things), which should then be in the docs, or is it something that the library ideally should have? – that’s my big strange conundrum!
P.S. I had this question in the beginning, which may also help in clarifying the manual:
https://groups.google.com/forum/#!searchin/strangeioc/bijou$20trouvaille/strangeioc/92BVM8HfgX8/nxjDBbvsx_8J
I’m going to resist getting into technical details/explanations for this post (I want to keep it focused on things we can do better in the BSHT)…though I encourage you to get more clarification via the Google Group. But I’m sure we can do better around explaining Cross-Context Bindings. I’ll add that to the post. Thanks!
Yep, I agree with this, which sort of goes into my suggestion of how to organize multiple contexts. It seems like the easiest way of doing a Strange project, in this regard, is to actually maintain one scene entirely, and simply load/destroy contexts based on the current game state.
Anyways, I feel like we’re digressing!
Since you are at it, for GODS SAKE, please use proper C# naming conventions this time.
Each time I see lowercase namespaces or Java/JavaScript naming conventions, I want to rip out the eyes out of my head. I don’t care about your JavaScript or ActionScript background, when you write goddamn fucking C# code, use the god damn C# naming conventions
We’ve discussed it, but I think it’s unlikely to happen. It’s exceptioly hard to justify a big set of breaking changes, simply so a handful of standards-zealots are more comfortable. We’ve also discussed a variety of intermediate (non-breaking) steps, but none feel like they really address the core concern. I, too, would like to align with standards, as I’ve stated many times…but not at the expense of forcing our users into a difficult upgrade path.
So you rather like to break conventions for 1000s of developers with this slappy all-lower-case stuff? Rewrites/major versions are there to break stuff.
If you don’t do it know, you will later. And the longer you delay it the more people it will affect. I for sure won’t ever use a framework which can’t keep the basic naming conventions.
You are a saint with tons of patience.
Haven’t started using Strange (or any other similar system) yet. But keep reading about it every once in a while, and being daunted.
What I would love is to see in new support material is a walkthrough of how to translate a simple, but naively built, Unity game, to use Strange. Perhaps there could be a simple Unity project that users could download (Whack-a-mole? something like that), filled with brittle dependencies and tight coupling. The tutorial would walk through Strangifying it, and ideally explain the ‘why’ along the way.
I realise that a simple game might not be the best scenario to use Strange in, but nevertheless I feel as though something like this would be very valuable for me to get a grip on how things work.
We do have StrangeRocks (https://github.com/strangeioc/strangerocks), an asteroids-style game for exactly that purpose. Mind you, we don’t have an un-Strangefied version, and I like the idea of having that for comparison.
Lots of people are asking for a tutorial-style walkthrough…so I guess I’ll have to do it. 🙂 But in order to keep from holding up the release of V1.0, I think it’ll have to be in a separate document, released sometime later.
Yes I did see StrangeRocks. Which does go a good part of the way. I realise that this is a significant ask, I won’t mind waiting! Thanks for considering.
I’m just learning Strange right now and one thing I find to be unusual (strange) is with commands. They are presented as being the Controller in MVCS but are used in a more temporary/transient fashion like I would expect something called “command” to do. However, I frequently see controllers as being persistent logic. Are commands intended to persist for the duration of the View’s lifetime? Some clarity here would be good.
Thanks Michael, that’s an interesting observation. So as a quick answer to the question: no, Commands generally aren’t intended to persist. In fact, we generally suggest they be entirely stateless (though I’m a happy enough for them to be pooled, or to hang around long enough to handle a response from a server.
Commands aren’t intended to be tied to Views in any way. The View’s Mediator fires a Signal, which might possibly instantiate a Command (neither the View nor the Mediator have any idea). The Views/Mediators and Models persist. The Commands do not. This indirection helps maintain loose coupling.
Now, as to how I can explain that better in the doc, I’m not sure. You seem to be starting from a very different place than me, since I wouldn’t expect controller logic to persist. But then I’ve been building this way for a long time, so I’m biased in my thinking. Feel free to comment on the new doc as we go…maybe you’ll find a good spot where I can highlight this in a way that makes it clearer from your perspective.
Hi, I’ve been eyeing Strange IoC for some time as an alternative to my preferred (but as yet not practically implemented in any major framework) ‘true’ ECS architecture. Looking at IoC, it seems to solve a number of problems, but it’s really unclear on a fairly critical point: how does all this fit into Unity? What should be a persistent component, and what shouldn’t? Should Models be Components or just free-floating classes? (which, btw, anything that doesn’t inherit from Unity Object is known to be prone to GC conflicts and cascading performance problems when you get lots of them) How does Unity’s NetworkView fit into all this, and the fact that RPCs are bound to a component reference? Should a Service be bound to a GameObject when it needs to make RPCs? Would creating a separate Service component instance for each and every one of the 1000 soldiers on your battlefield so their movements and actions can be coordinated be appropriate? What if a Soldier needs to coordinate with the others around him for AI; if the persistent data isn’t in a game object, how does he get that data?
If there’s one thing I’ve learned about Unity, it’s that if you want it to help you, it’s Unity’s way or the highway, so any additional info on how IoC and Unity work together would be infinitely useful. I can think of plenty of workaround and ways to sidestep the Unity-isms, but the more you do that, the less useful it is to use Unity in the first place, and the more you should consider another, leaner framework. I think there’s enough theory; not to say a rewrite wouldn’t be welcome by any means, but I’m presently bogged down on practical application. I had even more questions before, and it’s taken me hours to track down resources for getting pretty much any answers to any practical questions. The link in the comments here was the first mention i’d come across of a real, full IoC game with open source even.
I would, however, like to close with this: Thank you for StrangeIoC! You have put a lot of hard work into what StrangeIoC is today, and it’s a very useful and powerful tool. I only take the time to write up feedback for things that I think really matter and could be downright amazing with the right support.
PS: Is there a StrangeIoC IRC by chance?
Thanks for all that. I hope you’ll understand that there’s way too much in this for me to comment on every bit it, but here are a few (hopefully useful) reactions. First, no, we don’t have an IRC. TBH, it’s all we can do to keep up with the blog, the repo issues, and the Google Group. I think an IRC would do us in altogether. Next, it’s true that we’re not operating in a pure Unity way. Unity’s top priority is to make things “easy”. That’s cool, to a point. But as devs build more and more complex/AAA/”big” applications with Unity, I think our way of doing things (or something like it) becomes preferable, at which point “easy” needs to be redefined. Hopefully as the new BSHT takes shape, we’ll be able to show how — while Unity and Strange definitely have their rough edges — the two approaches can synch up quite well to get you both a cool, performant game and a sound application architecture. We’ll definitely delve into how we leverage Unity-centered components into the Strange architecture.
Having been using strange on two separate projects. One single player and one multi-player. I am in love with it and is really good architecture to build a project from. The new guide will be welcomed to see if it covers anything that I may have overlooked on what strange can do or see if I’m doing some things the hard way. Other than that I would just love to see it in it’s google doc form before it is “published” if you could provide a link even when it’s in the early stages of being written that would be awesome. And keep up the solid work!
Pingback: v1.0 and BSHT latest | StrangeIoC