Can I ask for feedback on a list of ideas and thoughts, and the pros and cons I could think of, about designing a chess game?

Question

I'd like to try coding a program to play chess. Therefore, to help myself, I'm writing down some possible choices that I will have to make to design the program (e.g. what data type for the chessboard, what for the pieces, ...).

Is it ok to ask here feedback on these kind of things?

I've seen there's a similar existing question here on meta, but it's as general as the title reads (Where can I ask for feedback on my concept?), so I think I could get a more fine grained answer to my meta-question, as I'm specifying exactly what kind of program I want to write. (I guess based on this meta question, you could already imagine what the actual question will look like.)

To give more detail. My question would be structured as follows, and I would ask if what I write makes all sense, if I'm neglecting something important, if I'm creating a terrible design flaw...

• For the board I could use

  • a 8 by 8 array representing ...

    • pros: ...
    • cons: ...

  • a 2 by n array representing ...

    • pros: ...
    • cons: ...

• For pieces, I think they should

  • necessarily contain: ...
  • could contain: ...

• I could represent the moves as ...

  • pros: ...
  • cons: ...

Answer 1

Our community does not regard pro-con questions as a good fit for this site, so I would expect a question of this form to be closed quickly.

Instead, you can try to implement a prototype of your data structures, ideally with some code using them, then ask for a design review. Still, there is a certain risk for such a question of getting perceived as too broad for the Q&A format of this site (see Are Design Review questions on-topic? and Why questions about “the correct way” are too broad). It is usually more successful to focus on one - and only one - aspect of your problem and ask a specific question about it.

Moreover, our community expects askers to do some research on their own before asking, show us what they found, and why it did not suit their needs. Chess programming is an extensively studied topic, and I am sure you will find tons of resources at the web, especially about the pros and cons of different data structures for modeling chess. For example, it took me less than a minute to find this Wikipedia page about chess board representations.

Hence, I would recommend to invest an hour or two into searching the Web. When you found something, tried it out and run into a specific conceptual issue, then you are at the point where it starts making sense to ask a question on this site about that issue.

Finally, don't overestimate the importance of picking the "ideal data structures" right from the start. Chess boards, pieces and moves contain only a handful of attributes. Optimizing their "internal representation" should be kept exactly this - internal - so one can change them later, if required. This is often just micro optimization. Though this can definitely be useful in chess programming, it can still usually be done afterwards, and should not be the basis for conceptual decisions.

The exception may be the case of an algorithm which requires to store millions of boards in memory. However, for this situation, it is viable to use two different data structures for such cases, one optimized for storage and one for fast processing. This approach avoids the need for designing a "perfect all-in-one data structure" up-front, which often does not exist.

Answer 2

Without seeing a specific example question, I'd lean toward the thinking that these types of questions would be closed, most probably as needing details or clarity, needing focus, or opinion-based. Generally speaking, questions asking for feedback often fall into the category of questions that should be avoided, specifically open-ended and hypothetical questions or cases where multiple answers are equally valid.

Specifically, when it comes to design, we do have guidance for design review questions. Similar rules can be applied to other question types as well.