52 cards, so each card can be represented by a byte.
Cards are arranged into 4 stacks of up to 13 cards each, 7 columns of up to 13 cards each, and a pile of up to 24 remaining cards. (You don't need two piles of remaining cards.)
That's 167 (4 * 13 + 7 * 13 + 24) bytes for the cards, 12 bytes to store lengths, and 1 byte to store the current index in the pile of remaining cards. It's a fixed number of fixed-length byte arrays and a fixed number of bytes to track lengths and one index.
No quite. The rightmost one initially has 6 closed cards and 1 revealed card which can be a king, so you can put 12 more cards on top of it, for a total of 6+13 = 19 cards. So I'd make 7 arrays for 20 cards each, just to be safe. Or just use 52-long arrays for every table slot, that too is an option.
> and a pile of up to 24 remaining cards. (You don't need two piles of remaining cards.)
Hm. True, but I'd still probably use two arrays/gap buffer instead of a single array with an index into it.
> 12 bytes to store lengths,
Eh, you can reserve a zero to be a "no card here" value and use NUL-termination instead; the card ranks start up from 1 (the ace) anyhow.
Also, don't forget to track card orientations: some of them are face down, some of them are face up. I usually do it by using the negative numbers for the cards face down :)
All in all, the whole game state fits into a L1 cache of any processor that even has an on-board cache, which is why card games has been around on pretty much every computer ever made.
I feel like Klondike, -should- be simple enough with a set of vectors/arrays/lists, the biggest thing is making sure you have the traversal logic right. [0]
[0] - I mean, here's an example in VB.NET, where a lot of the game logic is FBOW integrated into the form logic, but hey it apparently is NET8! https://github.com/DualBrain/Solitaire/blob/master/Solitaire...