My friend and I want a chess game, using pygame as the GUI. Any help??
In general, it is unhelpful to yourself to ask for help without specifying what specific problem you have.- teachers don't like this for sure.
For coding programs, it is often helpful to solve the problem on paper, then think about what functions and logic you require, then have a go at putting it together.
I am unable to offer any specific advice, even if I did know anything about pygame.
At its core, chess is a heavily rules-based problem. Before you begin writing any code, you need to have a deep understanding of the rules which govern available moves for different kinds of pieces, and be able to specify those clearly - this also includes putting a lot of consideration into how you'd represent those rules, particularly including any data you need and its structure.
As far as your GUI is concerned, I'd strongly recommend that you treat this as an entirely separate problem.
Treating your chess 'rules' engine as an entirely stand-alone problem should help you focus on the real problem, and avoid getting caught up with any artificial constraints or quirks which might otherwise be introduced by the UI (or by pygame). Your chess engine will already be complex enough without getting caught up handling GUI concern
For example, a chess engine has no need to understand things like mouse and keyboard events or pixel coordinates on a screen because the game of chess itself has no concept of a "mouse", "keyboard" or "screen"; a real-world chess game is just an 8x8 board with pieces, players, a timer, etc.
Whenever you're building a simulation of something like a chess game, it helps a lot to distinguish between the aspects which exist for the sake of your program (e.g the GUI) versus those "core" elements which drive the underlying simulation logic/rules, otherwise you can easily find yourself dealing with a lot of unnecessary complexity which makes your core game logic harder to reason about.
The problem with having a GUI tied up together with core logic is that it's easier to end up with "tight coupling" which can result in your program feeling more like a game of "Jenga". (Jenga - a game where the objective is to pull out a brick from a strack and put that brick on top, at the risk of letting the whole stack collapse. The programming analogy is that your objective may be to pull out a line of code and put that line of code somewhere else while fixing a bug or adding a new feature, but in doing so, the whole program falls apart and you have to start again.)
Even if it means that you have to write more code for the GUI, that isn't necessarily a bad thing, and if it means the GUI is slightly more complex, that's not really a big deal either. You'll often find that the way to avoid "polluting" your core logic with GUI-related problems is to write some slightly bloated code for the GUI - that's a bit of a natural trade-off, but one which is worthwhile and very much the lesser-of-two-evils.