As a quick fun project, I tried writing a solitaire game. But when getting to writing up the rules systems, I felt dirty, because my code felt completely unstructured and inextensible, mainly because my game logic was complete spaghetti code.
I've run into this problem before, and always feel awkward when writing this part of my program, so I was wondering, are there any tried and tested best practices when it comes to defining rules in a game?
I don't think there is a unique solution since a lot of cosiderations come from the particular problem.
You can use the Model View Controller pattern: this moves (confinate) your problem to "how to implement a behaviour on the controller", a beahaviour that always follows the rules.
Unless we are talking about very simple rules, the way you organize them poses a problem of expressiveness. You always face the conflicting demands of being simple (structured) and being expressive (write fun rules).
Using the MVC simplifies your job because the model formalize a state i.e. the context in which the rules are enforced.
Said that, you may find it useful to implement the Controller using the Strategy pattern and/or the State pattern in order to compose a complex behaviour in terms of simpler switchable behaviors. A Chain-of-resposibility pattern can help you to express rules while a State machine should be used carefully because its "state" partially overlaps the model's meaning of "state".
Using the Command pattern within the Controller may be usefull to both reduce Controller resposiblities (the Command know how to deal with the model) and make it easy to add the undo/redo functions in the Controller.
At any rate, you should try use the design patterns as guideline: they are useful to avoid to reinvent the wheel, especially the square wheel, but not every problem's solution consists of a bunch of (round) wheels put together.
I'm not sure about being best or even good but I usually use Observer pattern. It worked well enough for me.
Unless you've done the job many times before, you'll always end up with spaghetti code. Actually, at this point, you've only just started: what you have is the rough draft of a preliminary spec. Check out some of the other advice here and do some serious rewriting. And then some more rewriting, and then.... Personally, I'm never sure whether I get my code into really great shape or just get sick of rewriting it, but I do seem to get it right eventually.
Tackle the problem from two ends. Try to get the overall design to make sense and pick small parts that handle simple chores and make them right. Then try to work your way from both ends towards the middle. And then work from the middle back towards both ends. Then from the top down, then from the bottom up. Then repeat the whole process.
Essentially, what you have is a collection of classes. Consider class A. If class A is built well, its the classes that use it will automatically work better, however good or bad they are. If class A uses classes well, those used classes will do more, however good or bad they are. So organize your classes as best you can, then make sure each is the best class it can possibly be.
It is important to get it as right as you can. Bad code will haunt you until the day you throw it out. With software, a bit of extra polishing always pays off. (Unless no one ends up using the code....)
To sum up: check out the actual advice given in the other answers, then rewrite your code till you get something you like.
