r/chessprogramming • u/tlostenjoyer • 12d ago
Technical What is enough for the frontend?
I am an absolute newbie, so this might be a dumb question, started on this 2 weeks ago. I got scared once I saw the UCI specification and decided to make a frontend part first, without UCI or evaluation, just playable board, but with legal moves, checks and checkmates.
I almost finished and after painfully slow perft testing I realized that I didn't even need to implement all that in the frontend? Like, should frontend be just the representation of engine state? Okay, maybe just the legal moves generation, so the player could only make legal moves. Making the whole system self-sufficient made me write some pretty bad code lmao (architecture-wise).
What is the right way to do it?
3
u/Glittering_Sail_3609 12d ago
I am currently working myself for UI for chess variant that CuteChess is not supporting yet so I think I can drop some tips.
- It will take way longer than you think it will. Here is a quote from chess programming wiki:
Beware that writing a GUI is between 10 and 100 times more work than writing an engine.
Don't use the same implementation of chess logic inside UI and in chess engine. For chess engine you typically will use trickier and error prone board representations that are focused on efficiency. In UI however, you are being IO bound anyway so you should focus on correctness and code maintainability.
If possible, implement your chess logic inside a separate library, not the UI directly. It will be easier to unit test it that way. Or simply don't bother doing the chess logic yourser for gui and use chess.h.
The chess logic that frontend would require consist of board/move representation, make_move function and move legality test. Move generator is optional though it is useful if you want to add any sort of visual ques for the user. You would also need to detect game's ending states: checkmate, stalemate, 3-fold repetition, insufficient material, 50-move rule and attempts of playing an illegal move by one of the players.
The chess logic itself will be the easy part. I have spent WAY more time writing fool proof game arbiter and engine/uci validation code. That involves handling timeouts, engine crashes, engine being stuck in infinite loop, engine having faulty uci implementation, uci handshake, pondering etc.
1
2
u/milesdavisfan12 12d ago
You can implement your own user interface (UI) if you want, but it’s much easier to just implement UCI and use an existing UI to visualize everything. Most engines that exist (including Stockfish) are console only. In my first chess engine, I tried to develop my own UI, but this took at least 25% of my total development time and I ended up having to implement a UCI version anyways to test new changes.
Don’t be scared of all the UCI commands, you don’t have to implement all of them to be functional. My current engine I’m working on only supports around 10% of the commands and it is enough to test against other engines and use any UI I want.
Also, there’s a bunch of options for UI out there and the one you choose is just a matter of personal preference. I use En Croissant because I think it looks good but others (such as CuteChess) are fine too.
Lastly, you’re right that debug stuff like perft is often not in the UI to my knowledge. My engineer just copies stockfish and uses a “go perft x” command in UCI.
1
u/tlostenjoyer 12d ago
I plan to implement the engine in UCI console format, I just wanted to make a separate program for UI first. Just because, you know how it is. Like, it feels better when you made everything yourself.
10% sounds very very good though, thanks :)
I needed perft since I generate legal moves to make sure the user can't choose them in the first place. My question was, is this enough for UI, should UI also keep track of all board state variables, check for checkmate and other stuff?
I guess I just need to implement basic UCI engine and I will get the answer :)
3
u/gamingdiamond982 12d ago
to be honest to me at least they sound like two completely different projects.
And UCI was written with that mentality, the role of the GUI from a UCI perspective is to be kind of like the arbiter in OTB chess, it should be able to verify move legality and if a position is checkmate or a draw.
Since it doesnt need to be as fast as an engine any naive attempt will suffice for a GUI, but you will have to implement something reasonably fast to get a halfway decent chess engine.
And that feeling of "I did all of this" is alot more satisfying with the engine, my current engine while not the strongest only uses the rust standard library.
2
u/tlostenjoyer 12d ago
Well, I wouldn't say completely different, but yes kind of. While I was implementing logic for UI I learned some approaches used in engines, but just chose the easiest ones and without any voodoo for understandable code, since performance isn't the concern.
Ok, so the UI actually has to have all the logic? Good to know, I don't need to scrap anything then, just refactor it and move on to UCI and engine. That's what I've been trying to understand, you gave a good analogy.
UI is also a part of chess programming, right? :)
2
u/gamingdiamond982 11d ago
UI is part or chess programming in my book, but I think you'll find most members of this sub focus on the engine side of things, I doubt very many people here (myself included) have written a UCI compliant UI
2
u/KaMaFour 12d ago
Minimal UCI specification:
go wtime <> btime <> winc <> binc <>
position startpos
position fen <fen>
quit
stop
uci
ucinewgame
isready
If your engine supports those commands (half of those are a simple answer) you are pretty much good to go for most usecases
3
u/joeyrobert 12d ago
IMO, Frontend should be downstream of UCI/xboard protocol implementation when implementing an engine. Focus on the protocol first and you can drop your engine right in CuteChess, Arena or Winboard for a GUI.