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.
We’ve been modifying stats for a while now, but it’s not very desirable to have to switch the inspector to debug mode just to see their values. In this lesson, we will go ahead and create a Stat Panel view, which shows an avatar along with his or her name and a few important stats. There will actually be two of these panels, one for the currently active (or selected) unit and a second for the target of an action.
In this post we will continue to flesh out the UI by adding the Ability Menu. This menu will allow the user to determine what phase of a turn is active- such as moving, attacking, etc. as well as what to do during a turn- such as what kind of skill to use during an attack. We will actually implement the menu where possible (Move), and anything we haven’t gotten to yet will use placeholder content (Attack, Magic etc). We will also see how to support canceling a move and be able to restore an earlier state.
The user interface (UI) is one of those areas you always end up spending a lot of time implementing, and every game needs one in some form or fashion. I have built up a variety of reusable libraries in the past, but with Unity’s new UI tools I find myself starting over again. If you’re like me, the anchor and pivot system provided by a RectTransform may have been a bit confusing. I like working with it pretty well in the inspector, because I can modify the anchors and pivot to any corner for easy placement. In code, it wasn’t quite as easy, so this lesson is dedicated to the creation of a few reusable components which will, hopefully, make all our lives easier for awhile.
I’ve been experimenting with the UI tools Unity just released in version 4.6. I am very happy so far, so for this post, I am going to use it to create the interface for our Text based RPG game. Continue reading