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.

  • 1
    \$\begingroup\$ Can you make an example? \$\endgroup\$ – Gustavo Maciel Feb 14 '12 at 0:27
  • \$\begingroup\$ you can create an observer for each rule, then attach them to game state. after each turn game state calls all the observers to check if any of those rules is applied. \$\endgroup\$ – Ali1S232 Feb 14 '12 at 7:23

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.

  • \$\begingroup\$ So your answer is basically "read the other answers and do clean code or you'll regret"... \$\endgroup\$ – kaoD Feb 15 '12 at 18:23
  • \$\begingroup\$ @kaoD: Yes. But also: your first coding attempt will probably be junk. (If it's not, you're not pushing yourself hard enough.) It will take a lot of hard work to pull it together, along with a bit of research and a lot of thinking. This is normal when writing an involved program. All effort expended in this manner will save time, effort, and grief in the long run (if the program is still there in the long run). And also: OOP helps big time if you can get the hang of it. (Best I can do without seeing the code.) \$\endgroup\$ – RalphChapin Feb 15 '12 at 18:38
  • 4
    \$\begingroup\$ Do you realize you're actually NOT answering the question? \$\endgroup\$ – kaoD Feb 15 '12 at 18:41
  • \$\begingroup\$ Actually, regardless of whether Ralph's post technically was an answer or not, I think Ralph's response spoke towards the OP's motive for asking the question in the first place. I believe it has much value for a coder who hasn't come to the realization that it is rare that you design your code best on the first try. Also, he offered an approach to dealing with it that seemed to be born out of Ralph's experience. \$\endgroup\$ – Steve H Feb 15 '12 at 21:05
  • \$\begingroup\$ @SteveH I think his answer is applicable to almost any software engineering process. You could copy and paste it anywhere and it would fit. \$\endgroup\$ – kaoD Feb 16 '12 at 0:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.