> >> To be more specific, let's say I want to create a simple, 2D strategy >> game. It will have a board layout like chess or checkers and the player >> will move around the board. Let's say this is all I know, and perhaps I >> don't even know *this* for sure either. Is it possible to write the >> logic for such a game at this point? > > Maybe even this is possible. But here you are not only drawing the line > between GUI and logic but also within the logic part itself because the > board layout isn't (just) a GUI issue. If you have checkers, hexagons, or > other shapes also has influence on the logic part, because you need > slightly different algorithms for finding ways from tile `A` to tile `B`, > or to decide when a piece is blocked by others, and how the rules to move > pieces around look like. Just imagine how to modify chess rules to a > board with hexagonal patterns. It would severely change the logic part.
<purelyacademic>If the GUI defines that it's a board layout like chess or checkers and the player will move around the board, it's hard to say what's left for the "logic" part to do. I can't think of any generalization for the fact that it's a 2D strategy game. You could have a 2-dimensional array, the size of which is determined by the GUI, but even motion on it would have to be defined by the GUI, in which case the GUI would simply be using the "logic" part for storing the array and accessing it via index values. And then there's no reason not to put the array inside the GUI. Although it would help if only your "logic" part could provide persistence. Also, the "logic" part could provide many useful functions that games are likely to use, but then it's more like a library than anything else. Secondly, it's unclear whether the fact that it's a 2D strategy game was included in what he might not know, and in that possible case, strictly speaking, he didn't define anything that the logic part *does* know, and it being an example, one could theorize that that logically implies the "logic" part of the program is null. > >> Another example could be printing messages to the player. If I need to >> say "You killed the monster!", is there a general way to write this, or >> do I need to specifically refer to GUI widgets and methods, etc. in >> order for it to be displayed properly? > > The observer pattern can be used here. The GUI has to register a callback > function with your logic engine and every time you want to inform the > player about something, your game logic calls that function with the > message. It doesn't have to know if it will be rendered as graphic on > screen, displayed as text in a terminal, or synthesized as sexy female > computer voice. If the function name to register the callback function is hard-coded into the logic part and into the GUI, then so can the name of the callback function itself be, so that it doesn't need to be a callback, barring only the possibility of the callback function being changed from one instance to the next by the particular GUI, and even that can be done without a callback simply by reassigning the name, or in C++ you could cast a pointer to function within the hard-coded function and call it and and change that pointer when desired. Not that I know anything about MVC.</purelyacademic> -- http://mail.python.org/mailman/listinfo/python-list