Relationship between GUI and logic?

Discussion in 'Python' started by John Salerno, May 23, 2008.

  1. John Salerno

    John Salerno Guest

    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!
     
    John Salerno, May 23, 2008
    #1
    1. Advertising

  2. John Salerno

    RPM1 Guest

    John Salerno wrote:
    >
    > 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
     
    RPM1, May 23, 2008
    #2
    1. Advertising

  3. John Salerno

    alex23 Guest

    On May 23, 1:37 pm, John Salerno <> wrote:
    > 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
     
    alex23, May 23, 2008
    #3
  4. On Thu, 22 May 2008 23:37:45 -0400, John Salerno wrote:

    > 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
     
    Marc 'BlackJack' Rintsch, May 23, 2008
    #4
  5. 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 ?
     
    Bruno Desthuilliers, May 23, 2008
    #5
  6. John Salerno

    inhahe Guest

    >
    >> 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>
     
    inhahe, May 23, 2008
    #6
  7. On Fri, 23 May 2008 07:14:08 -0400, inhahe wrote:

    > <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
     
    Marc 'BlackJack' Rintsch, May 23, 2008
    #7
  8. John Salerno

    John Salerno Guest

    "Bruno Desthuilliers" <> wrote in
    message news:4836747b$0$15488$...
    > 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.
     
    John Salerno, May 23, 2008
    #8
  9. John Salerno a écrit :
    > "Bruno Desthuilliers" <> wrote in
    > message news:4836747b$0$15488$...
    >> 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",


    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 !-)
     
    Bruno Desthuilliers, May 23, 2008
    #9
  10. David C. Ullrich a écrit :
    > On Fri, 23 May 2008 09:13:50 -0400, "John Salerno"
    > <> wrote:
    >
    >> "Bruno Desthuilliers" <> wrote in
    >> message news:4836747b$0$15488$...
    >>> 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 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.
     
    Bruno Desthuilliers, May 23, 2008
    #10
  11. John Salerno <> wrote:
    > 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-
     
    Matthew Woodcraft, May 23, 2008
    #11
  12. David C. Ullrich <> wrote:

    > Matthew Woodcraft <> wrote:
    >> 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.


    > 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-
     
    Matthew Woodcraft, May 24, 2008
    #12
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ken Cox [Microsoft MVP]

    Re: Relationship between IIS Sessions and ASP.NET Sessions?

    Ken Cox [Microsoft MVP], Aug 8, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    5,423
    Luther Miller
    Aug 8, 2003
  2. =?Utf-8?B?QmlsbCBCb3Jn?=

    What relationship between cookie and ticket expiration?

    =?Utf-8?B?QmlsbCBCb3Jn?=, Dec 22, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    398
    =?Utf-8?B?QmlsbCBCb3Jn?=
    Dec 23, 2004
  3. Steve M
    Replies:
    3
    Views:
    27,554
    dar7ren
    May 27, 2009
  4. RichRich
    Replies:
    0
    Views:
    795
    RichRich
    Nov 24, 2003
  5. spike
    Replies:
    8
    Views:
    1,546
    Steve Holden
    Feb 9, 2010
Loading...

Share This Page