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.
Table View – Intro (Part 1 of 6)
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.
Poolers (Part 4 of 4)
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.
Poolers (Part 3 of 4)
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.
Poolers (Part 2 of 4)
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.
Poolers (Part 1 of 4)
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.
Tactics RPG A.I. Part 2
In A.I. Part 1, we added autonomous agents. Our enemy units could randomly move around the board and pick and use abilities with random targets. Now it is time to make them move and aim with a purpose. We need our enemies to be smart enough to hit multiple targets, attack from the best angles, and avoid friendly fire, etc. They should always act intelligently from the options which are available.
Tactics RPG A.I. Part 1
I’ve decided to split the A.I. implementation into two parts. This first part will cover the “what” as in “what ability do I want to use?”. This is the easier of the two problems. The next portion on “how” as in “how do I know where to move and aim to best use the ability?” is rather complex. Since this bit is easier, I will also include the code that ties the A.I. into the battle states, as well as adding another user interface view which shows the name of the ability that a computer controlled unit has chosen to use.
Tactics RPG Intro To A.I.
I’m currently hard at work preparing A.I. for this project. I was hoping to have it ready to share today – it works, but I am still polishing the code and working on writing the accompanying tutorial. While you wait, I decided I could share the decision making process I followed while architecting this portion of the project to help whet your appetite.
Tactics RPG Victory Conditions
Now that we have enemies, we can also provide an actual “goal” for the battle. First we must be able to actually defeat the enemies, as well as risk defeat for our own units. There needs to be a consequence for a unit’s hit points dropping to zero, so we will add a “Knock Out” status effect which disables a unit from acting or taking additional turns. Likewise there should be an effect for defeating all enemy units, or allowing all hero units to perish. These are sample “victory conditions” which we will track, and which will allow the battle to end. Continue reading