Variations: The Vienna

Cart File | Forum Post |

	More cartridges by camp39

More Cartridges [View All]

 

Variations: The Vienna

by camp39

Cart #variations_vienna-4 | 2024-05-26 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

3

Variations: The Vienna

Description

16 variations of the Vienna opening played as white. These lines are chosen to be fun, for their attacking chances and dynamic play. They include common mistakes by black and how to punish them as well as how to respond to good play from your opponent. Practicing with this cartridge will give any player a good start to creating big problems for black with the Vienna!

Features

While none of white's moves are dubious, they are not necessarily the top engine recommendations. Because there is no 'right' move, a hint can be requested (see Controls). After completing a variation, the Stockfish evaluation is given. The player then has the options to either repeat the completed variation, move on to the next, or have the computer select a variation at random. The pause menu gives similar options but can be accessed at any time allowing the player to navigate to a specific variation or move to a new, random variation.

Controls

❎ select/de-select piece and move-to square
🅾️ hold down during white's move to show a hint

Interesting, and educational too!

I ran into this error on the third variation after playing the first and second:

@Verb thanks for checking it out and letting me know. I can't duplicate the error on my end. But I'll try and will fix it if I can figure out when it happens.

I did fix a separate bug that possibly fixed them both... but not sure.

@camp39 really educational I enjoyed it! ⭐♟

Ok so I've managed to reproduce the error shared by @Verb it's still there.
Repro steps:

• simply keep pressed the hint button while you confirm the last move of the variation.

Cause of error:
the last element in each variation object in moves table does not provide any .x/.y properties, they're [nil], hence the error while attempting to render the hint.

(unsolicited) Suggestion 🤭:
instead of using moves[move_num].x or y, I'd create a handy function like get_move_pos() returning the two values, in case they're nil, provide something offscreen like -64,-64
At the top of functions where you'd need x and y do something like:
local x,y=get_move_pos()
Otherwise, quickest fix is -in show_hint()- drawing the rect only if x is not nil:
if(x)rect(x,y,x+16,y+16,11)

@Heracleum
Fixed. I also noticed that pressing them together during any move caused the computer destination square to get the hint...which annoyed me so was also fixed.
I'm always interested in peoples' suggestions with regard to my code so thank you very much for looking at it and finding a fix. I will think about your function suggestion because I really ended up not liking the structure of my code and already trying to understand alternatives. For this one I went with the quickest fix possible though (lol!).
If you are a chess player stay tuned! Next month will be Smith-Morra Gambit.

@camp39 Great! Well, since you are interested in suggestions, I feel like the inhuman tokens usage to define moves data really needs a more sustainable approach.
I'm convinced using lots of tokens for game logic is good (and inevitable) but big data definition is a job for strings and characters, just a minimum of tokens for a dedicated function to parse the string and populate table objects (the moves table in your case).

So this is how I'd approach moves definition (tested, seems to work fine, using only variation 1 data as example):

function addvar(s)
    for ln in all(split(s,"\n")) do
        local v=split(ln)
        if v[1]==" var" then
            add(moves,{variation=v[2], name=v[3], eval=v[4], msg=v[5]})
        else
            local mv={x=v[1], y=v[2], piece=v[3], spritex=v[4], spritey=v[5]}
            if v[6] then
                mv.in_check=true
                mv.check_pieces=split(v[7],"|")
            end
            add(moves,mv)
        end 
    end 
end

moves = {}

addvar[[64,64,wp5,0,0
64,48,bp5,0,16
32,80,wn1,16,0
80,32,bn2,16,16
80,64,wp6,0,0
48,48,bp4,0,16
64,48,wp6,0,0
64,64,bn2,16,16
48,80,wp4,0,0
112,64,bq,64,16
96,80,wp7,0,0,in_check,bq
96,80,bn2,16,16
80,80,wn2,16,0
112,48,bq,64,16
48,48,wn1,16,0
96,64,bb1,32,16
96,96,wb2,32,0
112,112,bn2,32,16
32,16,wn1,16,0
48,0,bk,80,16,in_check,wn1
0,0,wn1,16,0
80,32,bp6,0,16
64,80,wb1,32,0
 var,1,vienna gambit,0.0,black played well]]

This way the function and whole definition for moves takes only 106 tokens (vs the current ~5000 tokens) regardless of how many variations you will put in the big string (characters will be the only limit).
addvar accepts a single argument (the virtually humongous big string with all the variations) so you don't need to use the parentheses.
The big string instead of the regular "x,y,z\nx,y,x.." is using the multiline string delimiters [[...]] every new line in the code will be a "\n" in the string and the function uses the newline \n as separator to split every move line, then every value (comma-separated, so you just need split, comma is the default separator) will be put in a table, the format (a "move line" or a "variation definition") depending on the first value (we'll use " var" to tell which table kind and paramenter names to use).
Let me know if you find anything else not really clear 👍

@Heracleum
Awesome! +100!

"I feel like the inhuman tokens usage to define moves data really needs a more sustainable approach."
YESSS... I knew this intuitively but didn't know what to do.

Can't wait to go over your code carefully and play in a test file to really understand the magic of saving so many tokens.

This forum is really something special. Everyone here has been not just helpful, but thoughtful. Thank you for your time and input! and thank you, @zep for this place.