Simple board game GUI framework

[Paul Moore]

On 11 September 2017 at 16:32, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
>         This leads to a subtle question... If the focus strictly on OOP, or do
> you intend to supply some precursor OOAD stuff. OOP is just implementation
> and usage, but without some understanding of OOAD the concepts may come
> across as just magic.
>
>         IE: classes are templates from which one instantiates objects;
> instances of a class share methods, but each instance has its own state.
>
> Just doesn't help in figuring out what qualifies for a class vs instance,
> what should be a method, and what is state.

That's a very good point - and not one I'd really thought about (this
isn't a formal training course, more of a set of mentoring and
knowledge sharing sessions where I'm helping this guy get into
"actual" programming rather than just hacking the odd VBA macro etc).
I'll make sure I cover some of the design aspects in my discussion.

>>OK. Replace that with "I think my student would find it motivating to
>>see a GUI style of behaviour, even if he had to take the
>>implementation of that part of the program on faith". He's used to the
>>idea of writing plugin code that fits into a framework, so this would
>>be a familiar idea to him.
>>
>         Unless the "game" is going to be playing Chess (in which case you are
> looking at way more than an intro to OOP), the GUI comes down to a grid of
> squares, sprites/icons for the pieces, and a way to select/move the
> piece...

Yep, that's about it. But the point is, that's the framework, not what
I actually want to get him implementing.

> And the only logic left to implement would be validation of the
> moves, and tests for capture when one moves into an occupied square. Not
> really that much left for the student.

I'm not looking at actually implementing chess. The idea was prompted
by a programming exercise my son was given, that was about programming
a series of classes modelling robots that know their position on a
grid, and when told to move, can do so according to certain rules. One
moves in a straight line till it hits the edge, one moves in a random
direction, some bounce when they hit an obstacle and some just stop,
etc. The idea is to demonstrate classes and inheritance to model
common behaviours and objects holding state that the behaviour acts
on.

The original exercise (which used Java) just had the program print out
the objects' co-ordinates at each step. I thought that visualising the
results by actually showing the objects moving would be better. (And a
quick discussion/demo with the guy I'm training showed me I'm right -
his reaction was "wow, that looks really impressive" :-))

>         Again, it sounds more like you need a language agnostic discussion of
> OOAD -- not language specific OOP.

Mostly agreed. But we have a tendency to spiral off into pure theory
far too easily - and then my student doesn't remember what we covered
because it wasn't grounded in anything practical. So I want to have a
practical (and better still, visual) example to keep us focused.

Thanks for the comments,
Paul