Include TacticsAlpha.jar in .gitignore.
Detailing the non-grid part of the display.

Borders are fancy. Menus don't take up 25% of the screen at all times. The message can say things like "Moving. Press ESC to cancel." so the player has some clue what's going on.
More UI cleanup.

Making the message that shows in the UI interactive and based on the current game state. Added the concept of a GameState. The Game.update method needs some heavy-scale refactoring. Things should be based on GameState first, and input second, not the other way around.
Rendering HP/MP bars when hovering over an actor

There has to be a better way/place to do all this font fidgeting and rectangle creation.
Refactoring as described in issue 14. I can't exactly remember why I wanted to do all this stuff, but I trust my past self. It is cleaner, overall.
Making the screen resizeable and keeping static constants private, passing around width and height instead. The screen must be at least 1024x768, but can be arbitrarily larger and will stretch the grid and information area to fit. The grid doesn't scroll or anything fancy yet.

Before the resize feature can be considered complete, we need to modify the bottom section to not waste so much room when expanding the screen (i.e. give it a static vertical size in pixels since we can't make the screen smaller anyway) and modify the grid to take advantage of the space it has or cope with the space it doesn't have.
While I'm changing so much rendering code, I figured I might as well clean up the way we handle colors a bit. I can't say this class is easy to read, but it's one tiny step closer.
Allows for resizing of the grid using = and - keys. Centers small grids on the grid space, and scrolls large grids on the grid space so that the selected tile is always centered, unless it is close to an edge, in which case it shows as much of the grid as possible while still showing the selected tile.
Basics of movement limitation.

Calculates and renders the limit for movement of an actor based on that actor's movespeed. The movement isn't actually limited yet, and the display doesn't go away after you move, but the calculation is correct.
Limiting movement based on calculated radius

Now the actor obeys movement restrictions and the target display disappears after the actor has moved.
Target display disappears on cancel.
Working attacks and damage.

I haven't tested with higher numbers, but this damage calculation is similar to what LoL uses, so it should scale well. This isn't where I want the damage code ultimately, but we'll deal with that once we add more than one kind of attack.

The strength of the attacking hero is randomized slightly, so the base damage of the attack between 90% and 140% of the attacker's strength.

The target's defense is then taken into account, so the target takes a reduced damage percent. The damage taken is multiplied by 100 / (100 + defense). For example, if the target has 10 defense, the target would only take 90.9% damage. If the target has 50 defense, he would take 66% damage. If the target has 150 defense, he would take 40% damage. It never completely mitigates all the damage, but like proven in all the LoL mathcraft, additional defense adds linearly to the effective hp of the defender.
Basics of equipment.

I'm not sure how much I like making one class per equipment type. I might make generic classes for types of equipment (weapon, shield, etc.) and make factories that generate weapons of certain enumeration types. Or something completely different. But this works for now, so it's good enough to get us to the next step.

We need to add code to unequip weapons from certain slots and to specify which hand to replace when equipping something to the hand slot. Right now, it always replaces the left hand if the right hand is already holding something, which is less than ideal.
Equip to specific slot

Modified the code to equip an item to be more generic and allow equipping to a specific mainhand/offhand slot.
More Actor Info

Rendering more actor info to the screen at a time. Speed, Strength, Defense, Agility, and equipped items. Also made the calculations for widths a little bit more robust by using exact text widths instead of approximating.
Move "Target Tiles" concept to the Grid instead of the Game.

The grid now keeps track of which tiles are targetable, rather than the game. The next step is to prevent selecting a tile outside the targetable area when relevant. This will also make the game logic dealing with movement and attacks much simpler.
Restrict selection to targetable tiles

When there is a targeting area displayed on the grid, now the selected tile can't be moved outside the target area.
General cleanup

The Slot enumeration is definitely better in its own file so that it can be referenced more easily.

Also removed some redundant checks now that the Game class limits target tile selection.

From here the work begins on spells and spell effects, including AoE targeting reticles based on relative positions to a selected tile. Attacking is going to be made into a generic spell effect, and I'll probably add more stats to represent offenseive/defensive magic power.
More advanced targeting mechanics

Now you can target yourself with attacks, and attacks automatically affect everything within the current area of effect specified for the Grid.java

The next step is to make applying the effect happen in its own class so that we can move that logic out of the Game class and into somewhere more generic. Basic attacks will be converted to an effect like that, and adding spells will be as simple as adding a new effect.
Making AoE code more robust

And added a new (tested and working) LineAOE. Moved a lot of code from the abstract class to the specific class. Each class should take care of its own code, because in the case of line attacks, the relative positions of affected squares could vary based on the position of the reference square.