attempting an actual game...

In article <277d7$439e23dc$ca83a645$13469@saipan.com>, cr88192
@NOSPAM.hotmail.com says...

> for the external interface, maybe something psuedo-oo makes sense?...
> widgets are objects, and can be manipulated as needed, or such?...

Yes, OO works well for GUIs.

> most effective likely from the perspective of actually using them, would be
> making basic internal properties (linking structure, location, size, ...)
> externally fairly explicit (my design aesthetic doesn't really like this,
> but this is likely required in the name of functionality...).
>
> for things like load/save dialogs, etc... it is more or less necessary to do
> things like modify the contents for list widgets or whatever. an explicit
> widget structure makes sense for this.
>
> summizing all this, probably linked lists of structs.

There are almost certainly a bunch of libraries out there that you can
use, if of course you are using OpenGL or something for the graphics.
Or you could just use ordinary Windows GUI, with a bit of graphical
modification.

- Gerry Quinn

Philippa Cowderoy <flippa@flippac.org> wrote in
news:Pine.WNT.4.61.0512111844200.1524@SLINKY:
> In my experience, OO methodology often doesn't provide
> sufficient tools to decompose properly and safely on its own -
> and sometimes actively gets in the way of using the right tools.
> Sometimes you /want/ the equivalent of a switch statement.
>

You could encapsulate Finite state machine into object, or simply use
switch statement. I don't recal where OO methodology forces you to
use only OO methodology.

On Tue, 13 Dec 2005, Raghar wrote:

> Philippa Cowderoy <flippa@flippac.org> wrote in
> news:Pine.WNT.4.61.0512111844200.1524@SLINKY:
> > In my experience, OO methodology often doesn't provide
> > sufficient tools to decompose properly and safely on its own -
> > and sometimes actively gets in the way of using the right tools.
> > Sometimes you /want/ the equivalent of a switch statement.
> >
>
> You could encapsulate Finite state machine into object,

Now there's an assumption - who said I'm doing FSMs?

> or simply use switch statement.

Much as I could simulate objects with untyped arrays and a big pile of
naming conventions, yes.

> I don't recal where OO methodology forces you to use only OO
> methodology.
>

The part where you're not doing OO methodology anymore and can't
effectively embed another methodology into it without building up cruft to
such an extent your project's liable to get swamped in an avalanche of it.

--
flippa@flippac.org

A problem that's all in your head is still a problem.
Brain damage is but one form of mind damage.

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1e08d9e7d6f05e7698a852@news1.eircom.net.. .
> In article <277d7$439e23dc$ca83a645$13469@saipan.com>, cr88192
> @NOSPAM.hotmail.com says...
>
>> for the external interface, maybe something psuedo-oo makes sense?...
>> widgets are objects, and can be manipulated as needed, or such?...
>
> Yes, OO works well for GUIs.
>
ok.

>> most effective likely from the perspective of actually using them, would
>> be
>> making basic internal properties (linking structure, location, size, ...)
>> externally fairly explicit (my design aesthetic doesn't really like this,
>> but this is likely required in the name of functionality...).
>>
>> for things like load/save dialogs, etc... it is more or less necessary to
>> do
>> things like modify the contents for list widgets or whatever. an explicit
>> widget structure makes sense for this.
>>
>> summizing all this, probably linked lists of structs.
>
> There are almost certainly a bunch of libraries out there that you can
> use, if of course you are using OpenGL or something for the graphics.
> Or you could just use ordinary Windows GUI, with a bit of graphical
> modification.
>
yeah.

I had started absorbing some of my old stuff, then ran into the thought "do
I even really need this anyways" after all, it seems fine for the style of
interface I was doing to have everything permanently stuck at fixed
locations on the screen (and only allowing 1 menu to be open at a time).

eg: I have a "currently open menu" value, that holds one of a few constants
(none, stats, inventory, dialog, ...).

so, I switch depending on the current menu value, call the appropriate draw
functions, and handle input with the appropriate input-handling functions.

though not particularly general purpose, this seems like a good enough
approach (and most games I have seen have done similar).

> - Gerry Quinn

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1e08d9237d5c80ba98a851@news1.eircom.net.. .
> In article <51894$439e23de$ca83a645$13469@saipan.com>, cr88192
> @NOSPAM.hotmail.com says...
>> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>
>> > The dialog request comes when the game is told that you have clicked on
>> > an NPC, and recognises that the correct action is to initiate a dialog.
>> > Probably a flag is set putting the game in dialog mode.
>
>> but, how this flag is relayed is the dubious part.
>
> It isn't relayed anywhere - the game logic class/module holds it.
> Anything that wants to know whether the game is in dialog mode asks the
> game.
>
makes sense.

> The fact that input will typically go to the dialog rather than the
> game window while it exists will be handled by your normal windowing
> system.
>
actually, usually I don't use the windowing system, rather I usually use
checks and only relay input to various areas depending on whether conditions
hold.
eg: if console is down, only the console gets input, otherwise, if menus are
open, they get input (and the world is suspended), otherwise, input is
handled by the world.

the issue was I had decided to keep the world and main loop seperate. "game
logic" is handled in the world, menus are done in the main loop. so,
basically, menus are seperate from the "game logic" per se.

at the same time, entities and a few other parts of the world are shared
with the main loop, so maybe I could reorganized a little.

> Of course you could have a system of non-modal dialogs as in Diablo 2,
> where the player can interact with one or more dialogs, or with the
> game environment, at his choice.
>
yeah, I opted, however, for suspending the world while menus are open
(allowing, eg, selecting items from inventory, ...).

> - Gerry Quinn
>
>

In article <72475$439f9629$ca83a645$11267@saipan.com>, cr88192
@NOSPAM.hotmail.com says...

> I had started absorbing some of my old stuff, then ran into the thought "do
> I even really need this anyways" after all, it seems fine for the style of
> interface I was doing to have everything permanently stuck at fixed
> locations on the screen (and only allowing 1 menu to be open at a time).
>
> eg: I have a "currently open menu" value, that holds one of a few constants
> (none, stats, inventory, dialog, ...).
>
> so, I switch depending on the current menu value, call the appropriate draw
> functions, and handle input with the appropriate input-handling functions.
>
> though not particularly general purpose, this seems like a good enough
> approach (and most games I have seen have done similar).

At a pinch, it's probably acceptable, especially if you don't have a
built-in WIMP system.

Seriously, doing this for a simple game will give you a lot of insight
into what is needed for the dream game. It will save you time, not
cost you.

- Gerry Quinn

In article <568ab$439f99ac$ca83a645$12203@saipan.com>, cr88192
@NOSPAM.hotmail.com says...
> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message

> > The fact that input will typically go to the dialog rather than the
> > game window while it exists will be handled by your normal windowing
> > system.
> >
> actually, usually I don't use the windowing system, rather I usually use
> checks and only relay input to various areas depending on whether conditions
> hold.
> eg: if console is down, only the console gets input, otherwise, if menus are
> open, they get input (and the world is suspended), otherwise, input is
> handled by the world.

In which case you've written your own windowing system. Keep its
responsibilities separate from the responsibilities of the game.

> the issue was I had decided to keep the world and main loop seperate. "game
> logic" is handled in the world, menus are done in the main loop. so,
> basically, menus are seperate from the "game logic" per se.

Sounds okay, in general.

- Gerry Quinn

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1e0a4ebc252e4d4098a855@news1.eircom.net.. .
> In article <72475$439f9629$ca83a645$11267@saipan.com>, cr88192
> @NOSPAM.hotmail.com says...
>
>> I had started absorbing some of my old stuff, then ran into the thought
>> "do
>> I even really need this anyways" after all, it seems fine for the style
>> of
>> interface I was doing to have everything permanently stuck at fixed
>> locations on the screen (and only allowing 1 menu to be open at a time).
>>
>> eg: I have a "currently open menu" value, that holds one of a few
>> constants
>> (none, stats, inventory, dialog, ...).
>>
>> so, I switch depending on the current menu value, call the appropriate
>> draw
>> functions, and handle input with the appropriate input-handling
>> functions.
>>
>> though not particularly general purpose, this seems like a good enough
>> approach (and most games I have seen have done similar).
>
> At a pinch, it's probably acceptable, especially if you don't have a
> built-in WIMP system.
>
yeah.

> Seriously, doing this for a simple game will give you a lot of insight
> into what is needed for the dream game. It will save you time, not
> cost you.
>
maybe, dunno.

"dream game?...".

ammusingly (or lamely) I don't so much imagine a dream game as a dream
engine. of course, an engine isn't that compelling without a game (and the
hopeful features list for said engine is pretty massive, even vs the
top-commercial engines in existance...).

for realisticness-sake, I need to aim a lot lower, which is where I am at
now. the temptation still exists though to obsess on misc details, and right
now my progress is a little lacking (more usenet, email, ... than actual
coding).


I might need to pull off something interesting eventually, partly because
recognition might be nice, and (eventually) I might need to go get a job (an
on and off thought for a few years, I am getting old enough now to where
likely I "should" be self-sufficient...).

for now though I guess I am ok.

> - Gerry Quinn
>

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1e0a4f5be53780ee98a856@news1.eircom.net.. .
> In article <568ab$439f99ac$ca83a645$12203@saipan.com>, cr88192
> @NOSPAM.hotmail.com says...
>> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>
>> > The fact that input will typically go to the dialog rather than the
>> > game window while it exists will be handled by your normal windowing
>> > system.
>> >
>> actually, usually I don't use the windowing system, rather I usually use
>> checks and only relay input to various areas depending on whether
>> conditions
>> hold.
>> eg: if console is down, only the console gets input, otherwise, if menus
>> are
>> open, they get input (and the world is suspended), otherwise, input is
>> handled by the world.
>
> In which case you've written your own windowing system. Keep its
> responsibilities separate from the responsibilities of the game.
>
well, it is not really much of a windowing system...

a windowing system implies a little more than a hard-coded, ad-hoc setup of
input passing and drawing code...

>> the issue was I had decided to keep the world and main loop seperate.
>> "game
>> logic" is handled in the world, menus are done in the main loop. so,
>> basically, menus are seperate from the "game logic" per se.
>
> Sounds okay, in general.
>
ok.

> - Gerry Quinn