Hey very nice! I made a 386+VGA Solitaire game a while back for a game jam https://horsedrawngames.itch.io/solitaire I always meant to go back and optimise it more because it shouldn’t require a Pentium!
Late (late.sh) has solitaire available to play over SSH (along with minesweeper, tetris, battleships, chess... and many more). You'd be surprised at how well a lot of games translate just fine to being rendered on a simple interface.
I like to think I'm decent with C, and I thought I would be able to make my own solitaire, but just trying to wrap my head around how in the world I was supposed to lay out all the cards in memory and keep track of all the different states had me giving up pretty quickly.
I'd start by identifying all the known boundaries:
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.
Not 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]
https://nanochess.org/klondike_in_c.html
https://news.ycombinator.com/item?id=48450024 - Klondike Solitaire game for curses in 5k of C (2026-06-08, 17 comments)
Check it out: https://solitairle.com
> NOTE: For DosBox users, DosBox doesn’t seem to support AT&T 6300 but the other modes work fine.
I'm pretty sure DOSBox supports the Olivetti M24 graphics mode.
As its been HN'ed
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.
Not 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...