K.I.S.S.

General stuff

I need to get better at only implementing changes that I plan when creating a new branch. For example, I created a branch to add the ability to play more than one hand... The same hand over and over and over lol and ended up adding:

• The initial draft of double click placement of cards.
• A couple of input options to force a win condition so we don't have to play all the way through the hand to test things that only happen once the table has been cleared.
• A couple of things I can't remember at the moment.

At the same time, I don't want to paint myself into a corner with the purpose of a specific branch of code. I also don't want the overhead of maintaining multiple branches of code, stashing changes or tons of rebasing and merging just to flip back and forth as needed depending on what I have going on.

I suppose I can use more generically named branches targeted at the next release and track what I am doing for the release notes (that I am not really doing at this point).

Game Dev Stuff

I am noticing as I go through this project that early implementations of some logic could definitely be improved. My brain gets locked into iterating over data looking for things, setting conditions, exiting early, etc... only to see several days later that it could have been implemented in a much simpler way.

The most recent example of this would be during the initial implementation of double-click card placement. When a card is double-clicked, I was iterating over all the card stacks to see if the card was playable on each card taking into account the potential playable locations status (face up/down, correct suit, value, blank location, etc...). That isn't a ton of work we are only talking about 51 cards and 16 or 17 stacking locations. In reality I only needed to look at the top card in each stacking location.

In Lua the data structure for the 'stacks' of cards is defined like this:

M = {
    stacks = {},
    foundation_count = 4,
    columns= 13
}
-- The following is a heavily trimmed version of what is in code just to demonstrate the structure
local mt_2D = {
    __index =
    function(t, k)
        local inner = {}
        rawset(t, k, inner)
        return inner
    end
}
M.stacks = setmetatable({}, mt_2D)
local c = 1
for i = 1, M.foundation_count do
    table.insert(M.stacks[c], { id = card, card_name = card_name, ... the other data})
    c = c + 1
end
c = 1
for i = 1, M.columns do
    table.insert(M.stacks[c + M.foundation_count], { id = card, card_name = card_name, ... the other data })
    c = c + 1
end

That gives us the ability to simply iterate through stacks looking at the last item inserted:

for i = 1, #M.stacks do
    if M.can_stack_card(card_id, M.stacks[i][#M.stacks[i]].id) then
        -- save this location for consideration
    end
end

This takes us from checking 68 (51 cards, 4 foundations and 13 tableau locations) items down to 17 (last position of 4 foundations + last position of 13 tableau locations).

Anyway, all that to say I need to keep my eye open for the simpler solutions and not get hung up on math and physics. Yes, I was going to make this all physics based, it was a nightmare. There are still physics involved. Each card has a collision object, each stack location (foundation and tableau) has a collision object which is basically a valueless card and the mouse cursor has a collision object.

You can't really tell but this is 'technically' a 3D game with an orthographic camera. Each card is .0001 units above the item under it. I am hoping to take advantage of the 3D nature of the game for the flip animations and other animations throughout the game.

That is probably enough for now.

One last parting thought; I am considering removing the key restriction to download this game. I have received some feedback from people who have seen and / or downloaded the game but I probably need about 20 times as much in order to surface the issues and get some recommendations for new features.