Singleton and Threading

I've realized that the best(only) way to correctly implement the MVC + Log design of RPChess is to have each part Model, View, and Controller as a separate thread. And have the log be a singleton that all of the classes have as a member. Now, the problem of thread safety. I could get away without thread safety (or threads) in the current implementation, since it will be turn-based (and non graphical). But for future implementations the 2D graphics, definitely the 3D graphics will need threads and thread safety. Who writes to the Log? Who reads from the Log? How often does everyone read and write from the log? To signal the need for an update when a move is added to the log, an event should be raised so all the threads update their perspective assets synchronously.

The other issue. Do I really need thread safety now? I'm starting to like Test Driven and KISS based methodology. Like Extreme Programming. It's all about getting results now. I've always had a problem with adding to many features. I recently removed the BoardVector constructor in the Movement class, because a) anything you can do with BoardVector you can do with BoardLocation and 2) I didn't need it, it was making things confusing and bloating the code. I already needed to have XML Documentation for all public things, I don't need to be writing documentation for a hundred things. The documentation for all the BoardVector methods paralleled the BoardLocation. I think I'll start by reading up on thread safety and singletons, as well as their implementations in C# and then I'll make a better decision. But I feel like at least I'll start on the singleton interface.

[Update]
The way I wanted to implement the singleton pattern is actually called a Monostate. Here there are many instances of Log, but the important member data is all static. I am not implementing thread safety.

Move: Attack or Travel?

Currently I have piece Abilities and piece Movement as two separate classes. But If you think about regular chess, All pieces move and attack in one step. Should there be a special class called capture? Should the Ability and Movement be merged? Or should the Move class have a damage property that can be used in case of the original Chess rules?

Capture Class: First, lets think about the special class. There is very low flex ability in that case. You can't make a special class every time somebody wants something strange. Although, movement and attack may be the one other case besides exclusive movement/attack that deserves a case. And If those three classes cover all the possible creative ways people can think up to move or attack with a piece (reasonably), then it may be worth it.

One Super Class: This would take a lot of work and pending changes brakes the OOP philosophy. But if done right there wouldn't need to be any changes in the future. Although, I don't currently have plans for stat adjustments, or lasting attack effects (i.e. poison) but there may be a need for it in the future thus making the SuperMove Class very large and hard to manage.


Move.Damage: This is a very lightweight solution. But it also breaks the OOP philosophy. It isn't very dynamic. Same as the SuperClass. It isn't the smartest choice. But it is the easiest.

I think the best currently would probably be to create a Move interface that both movement and Attacks must conform to, so that adding new classes will be easier. So that the move/attack lists can be simplified and the global move log will have a standard to be built from.