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.
Sometimes you want to be able to refer to specific items in your collection by a key. The key could still be an index, but might be a scenario where your collection doesn’t include all of the indices – perhaps it didn’t start at zero or skips items. Alternatively you might want to map an item to something else, like a string of text. These are the kinds of cases where a Dictionary makes more sense than a List. Our final pooler and demo will be based on this use case.
In many scenarios, the collection of “Poolable” items itself is relevant to their use. If you want to think of the collection as having an “order” then the collection should probably be implemented as a “List”. Follow along and I will show another pooler based on a list along with a demo scene showing how to use it.
In some scenarios, the collection of “Poolable” items itself isn’t relevant to how you are using them. If you have no need of iterating over and applying logic to the entire group then you might be satisfied with using a simple “Set” to contain them. For example, an explosion might be pooled after its animation has completed and a bullet might be pooled after it hits an object or leaves a game zone. Scenario’s with event-based pooling might be a perfect fit for our first Pooler subclass.
After having used my pooling library for awhile I found myself putting similar implementation code all over my scripts. With a bit of thought I realized that I could eliminate a lot of the code by creating another component. Actually I will be creating several, but they all serve the same purpose of helping reduce the amount of code necessary to work with pooled items.
I am new to blogging (less than a year) and I don’t really have a good way to gauge success, but…
I’ve passed 25,000 views! Whoo hoo! I am very excited and have been having a lot of fun. Thanks everyone for sticking with me and for all the great comments!
I feel like now would be a good time to take a step back and ask how I’m doing. Are you enjoying the tutorials and project idea? Any suggestions for improvement or comments for the future?
Now that we have stats, we will need new ways to modify them. Of course one way is through leveling up your character, but a potentially more fun way is by items. Equiping a sword which is not only cool looking but provides a great bonus to your ATK (attack) stat can be very rewarding. Likewise, when you are damaged in battle a health potion might be in order to boost your HP (hit points) stat. In this lesson we will examine a few ways to create items, both consumable and equippable, as well as how to manage your equipment.