It’s finally time to see how everything works together. In this post we will review the “Table View’s” code. This complex component will utilize the TableViewCell, Spacer, Flow, and Container elements we have already discussed to complete a very flexible component which accomplishes every goal I set out to achieve.
The final “variable” implementation of our TableView helps to finish tying everything together. It breaks the four possible flows down into two categories: “Horizontal” or “Vertical”. You can think of this as a “Container”, because it causes the “Content” of the “ScrollRect” to adjust its size as necessary to fit all of the cells we have loaded. In addition, this script is responsible for deciding what kind of Flow to use based on the settings of the “Content” itself.
Just like we broke down the logic for determining the size and relative position of cells, we can also break down the logic for their flow. Should they be arranged from top-to-bottom, or bottom-to-top? How about right-to-left or left-to-right? In this lesson we will create a new interface so that we can easily support any of these options.
Making a scrolling list of cells isn’t that hard. Making a list that only creates as many cells as is necessary for display is slightly harder. Using a single component which can elegantly handle variations like whether or not the cell size can change or what direction the scrolling will occur, is pretty advanced. The best way to approach this kind of challenge is to break it down into manageable pieces.
A lot of the hard work performed by a table view is related to the reuse of its cells. We will need a component that will help ease the process of positioning those cells once they have been added to the table view. It will also need a way to animate into and out of the table view.
I’ve been hard at work creating a prototype for what I hope will be my next blog project – a networked multiplayer card game like Hearthstone. Creating enough menus to build and manage decks has resulted in the need to make a bunch of table views (scrolling lists of items whether cards, heroes, decks, etc). Although Unity has some pretty nice new tools for UI, there are still improvements I felt compelled to address.
In this post I will present my own implementation of a component-based architecture which closely mimics Unity’s implementation. It really isn’t as hard as one might think. Why would I ever do such a thing? I think I have plenty of good reasons, but I’ll let you decide whether or not its all worth it. As always, feel free to critique!
I’ve received some feedback regarding using event-based architecture in my recent post on my Tactics RPG State Machine. The concern is that because events cause extra memory allocations it could have an affect on performance. I’ve used events heavily in every project I’ve worked on and to date have never observed a performance problem on their account. Still, I was curious to run some tests and see just how bad it might be.
In the first part of this series, I introduced easing equations and created a control which wrapped a lot of typical animation related functionality into a reusable control. In this post, we will create some extensions and a convenience class so that implementation of common animation tasks can be done with a single line of code.
Unity has some pretty decent animation abilities built into the engine with which you can keyframe the position of entire hierarchies of objects. If you were animating a walk cycle or a bouncing ball, it works great. Other common use cases, like animating the move of a UI element when supporting multiple screen aspect ratios, are another issue. When you don’t know what the size of your screen will be, you can’t keyframe an animation for it. There are plenty of plugins on the asset store which solve this problem, but if you are like me and want to know how it all works, or you simply don’t want to spend money, read along and we will create our own solution. Continue reading