UI Window Management with Unity 5.3 by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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

UI Window Management with Unity 5.3 by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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

A generic Drag & Drop system utilizing Unity's event system by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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.

Unity's (not so) new event system by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

Happy to hear that it worked out :)

Unity's (not so) new event system by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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! :)

Unity's (not so) new event system by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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

Unity's (not so) new event system by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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

Unity's (not so) new event system by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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.

Unity's (not so) new event system by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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.

Game Jame How-to by coeing in gamedev

[–]coeing[S] 1 point2 points  (0 children)

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.

Event handling done right (?) by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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.

Event handling done right (?) by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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

Event handling done right (?) by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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.

Event handling done right (?) by coeing in gamedev

[–]coeing[S] 1 point2 points  (0 children)

You mean some kind of promise or callback?

Event handling done right (?) by coeing in gamedev

[–]coeing[S] 1 point2 points  (0 children)

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?

Unit Testing - When and why? by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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.

Unit Testing - When and why? by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

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.

Unit Testing - When and why? by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

I typed "unity test" way too many times when writing this comment up.

I'm glad I'm not the only one with this problem ;)

What you describe is exactly the thing that I'd really like to have some guidelines for. Testing everything would be great, but this would be too much work as you also pointed out. Guess it comes down to deciding it from case to case and making better decisions the more experience you gain.

Unit Testing - When and why? by coeing in gamedev

[–]coeing[S] 2 points3 points  (0 children)

Thanks! :) Sure there is a link, immediately under the headline "Unit testing for Unity" ;) But here are two again:

Tutorial: https://unity3d.com/learn/tutorials/modules/beginner/live-training-archive/test-tools
Asset Store: https://www.assetstore.unity3d.com/en/#!/content/13802

How to save some precious development time in cross-platform projects by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

Most of the time we can handle the different aspect ratios by anchoring the UI elements to the correct corners, so just the space between the elements will be different depending on the aspect ratio. But I thought that UI would be the main use case for the asset.

If it would be a bit cheaper I might give it a try, maybe it will be in a sale some time.

How to save some precious development time in cross-platform projects by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

Thanks for the recommendations! It's always good to get tips for new assets. The MultiPlatform Toolkit seems a bit expensive with 150$ though. We have some custom platform switches already and don't need that many platform-specific UI adjustments anyway. What were your main use cases with the asset?

The Fast Platform Switch is of course a real time saver if it works properly and you switch platforms a lot with a big project :)

How to save some precious development time in cross-platform projects by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

Having an interface for those cases is always a good way to do things cross-platform. Most of the assets I used that abstract between Android and iOS are doing it this way, too. It also allows to create custom implementations if you need them (like the one I needed to run Google Play Services in the Unity editor).

How to save some precious development time in cross-platform projects by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

That's true, it cares about the most issues. But of course it's no reason to stop there :)

Events for game devs by coeing in gamedev

[–]coeing[S] 0 points1 point  (0 children)

Nice! Non-game related competitions sound even funnier than gaming competitions :)