So a while back I made the basics of a simple Chess framework, its not 100% complete but I figured I should release it here anyway.
It’s all inside of GUI, it is very modular.
Please note: This may not be the most beautiful thing that has ever walked the planet, there may be ways of doing things in a way simpler way, but I did it in a way that made sense to me. This is also a few months old now, and has been gathering dust.
Recently I was thinking about working on some games such as chess or card games(like GoFish)
and this is probably the first time I saw someone posting something related to this kind of project.
Amazing job!
Although I’m not going to make a chess game, it’s still awesome reading a script that someones made and learned something from it. Thank you
I learn new things from ModuleScripts. It was fun.
Other thing about RemoteFunction (Sorry to ask because I’m still learning about it)
-- LOCALSCRIPT
-- You call this with a table thingy "[1]"
if game.ReplicatedStorage.Chess.PlayerList:InvokeServer()[1] == game.Players.LocalPlayer then
isBlack = false
end
--SCRIPT
-- To get this
game.ReplicatedStorage.Chess.MovePieceFunction.OnServerInvoke = function(plr, a,b)
if lastTurn == plr or (plr ~= first and not lastTurn) then return end
lastTurn = plr
for _, v in pairs(game.Players:GetPlayers()) do
if plr ~= v then
game.ReplicatedStorage.Chess.MovePieceFunction:InvokeClient(v,a,b)
end
end
return true
end
Can I ask why? because this is my first time seeing a Remote having a table thingy.
if game.ReplicatedStorage.Chess.PlayerList:InvokeServer()[1] == game.Players.LocalPlayer then
isBlack = false
end
The serer is returning a list of players, I do it from the server to be sure the client isn’t listing them in a way that doesn’t make sense, by saying [1] I am getting the first player in the list it returns, and than comparing it to see if its the same player as the LocalPlayer. I used it to determine if you should be white or black.
The second block of code you sent from the server is not same RemoteFunction
If what I said didn’t make sense to read, lemme know
I understand it now, thanks for explaining. I can see a lot of features are still not created here maybe this is one of it. Anyways I can understand it now.
There are a few questionable design decisions that I would avoid using in a proper game.
Invoking the client
Invoking the client is a pretty bad idea. If you invoke the client you don’t know when you will get a response. 2 ms? 2 minutes? 2 days? No idea how long ur script is gonna yield which presents some narly problems.
Readability
There are some big problems when it comes to figuring out what your code is doing when you look at it for the first time.
Functions in tables look like this MoveTables[1](...) which is a little painful to comprehend.
I’d rather you use something like MoveTables.PawnMove(...) because it makes better sense
I see this array thing a lot which makes it pretty difficult to wrap my head around most of the code.
USE FEN NOTATION (something just chess related)
Fen notation makes your life much much easier when it comes with loading in a position
Instead of having to type in each position, the color that goes there and then the piece type very tediously like making a quad in opengl you just need a way to parse a FEN strings and you are set. Forsyth–Edwards Notation - Wikipedia
