Relationship between GUI and logic?

J

John Salerno

I know that it is good programming practice to keep GUI and logic code
physically separate, by using XRC for example, but I'm wondering if it's
also good practice (and even possible) to keep them separate from an
implementation standpoint as well. Basically what I mean is, should it
be possible to write, for example, the logic for a strategy game without
even knowing what the graphics will look like or how they will work?

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?

Let's say I want to write a "move" function (or perhaps it would be a
method of a "Character" class) for moving the player around. Could you
really write this function without 1) knowing what the interface will
look like, and 2) integrating GUI code with the logic?

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?

Basically, the question is this: can you write the logic behind a
program (whether it be a game, an email client, a text editor, etc.)
without having any idea of how you will implement the GUI?

Thanks!
 
R

RPM1

John said:
Basically, the question is this: can you write the logic behind a
program (whether it be a game, an email client, a text editor, etc.)
without having any idea of how you will implement the GUI?

Chess already has at least two solutions that are in widespread use:

Winboard
UCI (Universal Chess Interface)

Basically you write your chess "engine" to speak either Winboard or UCI
and then you can "run" it in one of the various GUI interfaces, (such as
Shredder, Fritz, Arena, ...).

See:
http://www.playwitharena.com/

or the comparatively young:
http://pychess.googlepages.com/ (which is written in Python)


Patrick
 
A

alex23

Basically, the question is this: can you write the logic behind a
program (whether it be a game, an email client, a text editor, etc.)
without having any idea of how you will implement the GUI?

Hey John,

Are you familiar with the Model-View-Controller pattern? It
specifically addresses this issue, and is very common in game
development.

In your example of a grid-based game like chess, the board & the
pieces would all be defined in the Model. The board may be a 2D array,
so to move a piece, the piece only has to know how to address
locations within the array, or even better, only has to know how to
tell the board where it's moving to, so the pieces don't have to know
how the board is implemented.

The View interprets & displays the Model. You could represent each
square by a bitmap, draw a 3d object, or use ASCII etc etc.

The Controller maps user input to Model behaviour, so pressing 'up'
while a piece is highlighted may call something like
piece.move_north(), which updates the necessary entities in the Model
to reflect the move. It generally also passes information from the
Model to the View, although it's not uncommon for the View to just
refer to the Model separately.

So you can think of the Model as a simulation of the behaviour you
want, while the View is _a_ representation of that simulation. The
simulation doesn't care if you're displaying it in 2D or 3D, it cares
about pieces and board positions. By separating the Model & the View,
you also allow for multiple representations of the same data, such as
having a 2D overhead map and a 3D visualisation of the same
information.

- alex23
 
M

Marc 'BlackJack' Rintsch

I know that it is good programming practice to keep GUI and logic code
physically separate, by using XRC for example, but I'm wondering if it's
also good practice (and even possible) to keep them separate from an
implementation standpoint as well. Basically what I mean is, should it
be possible to write, for example, the logic for a strategy game without
even knowing what the graphics will look like or how they will work?

Yes, that's possible.
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.
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.

Ciao,
Marc 'BlackJack' Rintsch
 
B

Bruno Desthuilliers

John Salerno a écrit :
I know that it is good programming practice to keep GUI and logic code
physically separate, by using XRC for example, but I'm wondering if it's
also good practice (and even possible) to keep them separate from an
implementation standpoint as well. Basically what I mean is, should it
be possible to write, for example, the logic for a strategy game without
even knowing what the graphics will look like or how they will work?

Depends on your definition of "logic". The point is not "keep GUI and
logic code" separate, but to keep "domain" logic (as) separated (as
possible) from user-interface stuff.
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?

Yes : build a model of the board and pieces and functions/methods to
allow (code-level) interaction with it. Then your user interface will
just have to create a visual representation of this model (let's call it
a view) and present the user with ways (connected to things we'll call
'controllers') to call the interaction functions/methods.

Then : the view registers itself with the model, display itself, and
wait for user interactions. These user interactions are sent to the
appropriate controller, which will call on the model's interaction
functions/methods. Then the model updates itself and notify the view
that it's state has changed, so the view can refresh itself.

Ever heard of the "Model/View/Controller" pattern ?
Let's say I want to write a "move" function (or perhaps it would be a
method of a "Character" class) for moving the player around. Could you
really write this function without 1) knowing what the interface will
look like, and 2) integrating GUI code with the logic?

Yes. The move function will modify the state of the board/pieces
("character", whatever) model, which will then notify whoever is
interested that it's state has changed.
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?

Idem. State change, notification.
Basically, the question is this: can you write the logic behind a
program (whether it be a game, an email client, a text editor, etc.)
without having any idea of how you will implement the GUI?

s/GUI/ui/g

The user interface doesn't need to be graphical. There were games and
emails clients and text editors before GUIs existed, you know ?
 
I

inhahe

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.
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>
 
M

Marc 'BlackJack' Rintsch

<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.

The logic part has the rules how you may move the pieces. The GUI
shouldn't have to know how a knight, bishop, or queen can move or
what castling is.
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,

No it isn't! The size is independent from the GUI. Most 2D strategy
games have maps that are way large than the GUI displays at once. You
almost always see just a portion of the model of the game world in 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.

There are plenty of reasons. You tie the game to one GUI this way. No
way to change the GUI toolkit or to split the game into server (game
logic) and client (different GUIs, web application).

Ciao,
Marc 'BlackJack' Rintsch
 
J

John Salerno

Bruno Desthuilliers said:
Ever heard of the "Model/View/Controller" pattern ?

Yes, I have, but I probably don't understand it well enough yet. For
example, I don't really know what is meant by phrases like "build a model",
"the view registers itself with the model", "interations are sent to the
appropriate controller" -- I may understand them literally, but I get the
feeling that the implementation of these ideas are beyond me. I think it's
mainly an issue of terminology, so probably I should just read up on MVC.
The user interface doesn't need to be graphical. There were games and
emails clients and text editors before GUIs existed, you know ?

Of course, but I'm specifically asking about creating a program that has a
GUI, and even more specifically it would be wxPython.
 
B

Bruno Desthuilliers

John Salerno a écrit :
Yes, I have, but I probably don't understand it well enough yet. For
example, I don't really know what is meant by phrases like "build a model",

An abstract, logical representation of your board and players, which
have a state (ie : board has X cells, player1 is on cell (x, y) and
player2 on cell (x', y')) and behaviour (ie : player2.move_to(x, y))
that changes the state.
"the view registers itself with the model",

This is the Observer pattern. The view is passed the model when
instanciated, and calls model.register(self). When the model changes
it's state, it calls back the '.notify()' method of each of the
registered views (a same model can have multiple views at the same time).
"interactions are sent to the
appropriate controller"

In a typical GUI, the controllers are the event handlers (or are called
from the event handlers - depending on how the GUI works). The system
dispatch the events to the appropriate event handlers.
-- I may understand them literally, but I get the
feeling that the implementation of these ideas are beyond me. I think it's
mainly an issue of terminology, so probably I should just read up on MVC.

Probably, yes !-)
 
B

Bruno Desthuilliers

David C. Ullrich a écrit :
I doubt that.

I've done things like this. I ended up with just a Model and a View,
no Controller.

In the code snippet you gave, you do have the controller part - it's
just merged with the view. Thruth is that the controller part does not
map to a single, explicit, obvious *component*. It in fact often
happens that the controller bits are handled by various components of
the system.

In the case of most modern GUI toolkits, the OS and GUI toolkit handles
the first part of the controller stuff : mapping user actions to
appropriate events, then mapping events to event handlers
functions/methods - which, since views and controllers are usually
tightky coupled, are most often than not methods of the view object
itself - either because the GUI toolkit requires it or because the coder
found it simpler and more obvious. Now even in the first case, you can
still factor the controller part out of the view, and have the view's
event handlers call on the controller. This may help unit-testing both
the controller and the view and avoid having too much logic into the
view itself.
 
M

Matthew Woodcraft

John Salerno said:
Basically, the question is this: can you write the logic behind a
program (whether it be a game, an email client, a text editor, etc.)
without having any idea of how you will implement the GUI?

You probably could, but it's best not to unless you're somehow forced
to.

In practice, the interface that you want your 'logic' layer to provide
to the GUI is likely to depend on some of the details of how the GUI
works.

If you did the lower levels first without having any idea at all of
what you were going to do with the GUI, it's quite likely that you'd
find you'd written a few functions which turned out not to be needed at
all, or that some functionality that the GUI needs to use very
frequently is rather slow to execute, or that some functionality that
you thought belonged to the 'logic' is really better done in the GUI
layer, and so on and so forth.

For example, if you were writing the 'logic' for a chess program you
might choose a way of modelling the board that can't represent a
position with more than one black king. And then when you got round to
doing the GUI you might find out that your users would like to be able
to have this temporarily when setting up a position.

-M-
 
M

Matthew Woodcraft

What you say may be true, but this doesn't seem to me like a good
example. Not that I see _why_ the player would want to have two kings
temporarily, but if so I wouldn't have the view report this state to
the model, I'd have the view wait until the player had decided on the
final configuration betore saying anything to the model. The model
should only deal with legal positions.


Then you end up implementing a second model of the board state in the UI
layer. And if it turns out that you want to support things like 'save
current position' and 'clone current position to a new window' during
setup, you might well find yourself putting so much logic in the UI
layer that some of what you already wrote in the 'logic' layer ends up
unused.

As for why you might want illegal positions during setup, imagine a UI
where you can click on a square repeatedly and it cycles through the
possible pieces (dunno whether this would be good in practice, but I do
know that guessing whether a UI is good without trying it is rather
unreliable).

-M-
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top