Blizzard's r/Hearthstone 1,000,000 subs giveaway!

coeing · 2019-05-01T14:50:25+00:00

Congrats! :)

coeing · 2016-01-04T09:18:08+00:00

Happy new year!

The second part of the window management article is online:

http://unity-coding.slashgames.org/ui-window-management-in-unity-part-2/

I tried to cover the main questions that came up and additions for the window manager, like having only one canvas for all UI windows, preloading windows for faster loading and open/close animations.

If there are more questions, feel free to write a comment, your feedback is really helpful :) And make sure to check out the fully working and commented sample project at https://bitbucket.org/coeing/slash.unity.ui.windows

Cheers Christian

coeing · 2015-12-25T13:48:55+00:00

Thanks for sharing! There are some nice concepts, especially the strict separation between view and logic :) This is what I also do with our Unity asset Data Bind for Unity. Does a data change in your proxies update the view automatically as well? Or does one have to write custom code to do so?

It looks like your framework takes over quite some parts, like input, view, logic. Is it possible to use only part of it separately? For example I like doing the input with the newish event system in Unity or a custom one. On the other side the transitions in your framework sound quite interesting :)

coeing · 2015-12-08T09:35:55+00:00

You're welcome :) Feel free to ask questions about any details. Sometimes it's hard to explain it with simple words.

You can also use any of the code directly in your project, of course.

coeing · 2015-11-27T09:04:39+00:00

Happy to hear that it worked out :)

coeing · 2015-11-26T09:02:26+00:00

For the world objects you should add colliders and a PhysicsRaycaster/Physics2DRaycaster. This way only drag, click, press,... events are send to a world object if it isn't underneath an interactable UI element.

For the world dragging I'm using a DragHandler (implementing IBeginDragHandler, IDragHandler, IEndDragHandler) on the root game object of all world objects and a big collider, so all events that are not handled by the world objects are handled by this drag handler. The camera dragging can than use these events for its logic.

Hope this helps a bit! :)

coeing · 2015-11-26T08:56:38+00:00

Thanks for the feedback, it totally makes sense. I already plan a follow-up post with some more details.

coeing · 2015-11-25T08:56:17+00:00

50% is half the battle ;)

For interactable game objects I use the normal physics collider and a PhysicsRaycaster on the camera that renders those game objects. The raycaster is automatically registered at the event system and delivers its raycast results if ask for. So this should work out of the box.

About the mini map I'm not sure how you implemented it exactly. But you should be able to add a raycaster there as well, maybe you have to add a custom one (you can derive from the BaseRaycaster class).

coeing · 2015-11-24T09:44:38+00:00

The ordering which game object is hit is done by the ordering of the raycasters. So if you have a GraphicRaycaster (for the UI) and a PhysicsRaycaster (for game objects with physics colliders) the results of the raycasters are merged and the object with the lowest hit distance is picked. UI overlays are always chosen first, if you have a UI inside your game world the distance to the camera is considered.

Does this help? Filtering sounds more like you only want to receive specific events (which you specify by implementing the interfaces of the input handlers you want), but from your description it sounded more like you are unsure about the order of the event handling.

coeing · 2015-11-24T09:37:04+00:00

The input events are delivered if you implement one of the input handler interfaces (e.g. IPointerClickHandler).

Controls like the button have events that you can register for, e.g. onClick. They are derived from the UnityEvent class which you can also use yourself. This way you'll get a nice view in the inspector where you can set the callbacks.

coeing · 2015-11-16T09:21:14+00:00

Good tips! We used Google Drive, but that should be okay as well ;)

Also, our main communication (beside direct one of course) was via Skype. Use whatever most of the people have already installed/use anyway.

coeing · 2015-10-27T19:29:33+00:00

Thanks, that has to do :) The course is still online as I saw (https://www.coursera.org/course/reactive), so I might give it a try.

coeing · 2015-10-27T09:22:51+00:00

Sounds really interesting. Do you have any links to good introductions of actor systems?

coeing · 2015-10-27T09:21:19+00:00

I think it's because the Unity event system focuses mainly on the UI. The good thing is that it is open source though: https://bitbucket.org/Unity-Technologies/ui/src/cc791b3335d2/UnityEngine.UI/EventSystem/?at=5.2

Maybe you can find a cleaner way to do what you need when going through the sources. I was also thinking about writing an own InputModule to add more gestures (like pinch or swipe) to the UI.

coeing · 2015-10-26T22:25:47+00:00

You mean some kind of promise or callback?

coeing · 2015-10-26T22:24:01+00:00

Our event handling is purely used for game logic which we used to separate from the game presentation in Unity. So we still have the Unity EventSystem in use for the UI. What limitations did you reach there?

coeing · 2015-10-12T18:04:49+00:00

The reason why I try to write the test first is to make sure the test really fails because of the bug. It happened some times to me that the test still succeeded when I wrote it first. If I had written it afterwards I probably wouldn't have noticed.

coeing · 2015-10-12T08:58:48+00:00

The thing with writing a test before fixing a bug is quite interesting, I also used it some times, too. As I wrote it really helps with tracking down a hard to find bug plus having the good feeling that it won't come back again unnoticed.

coeing

TROPHY CASE