Game design question...

Hey, gang:

        I'm designing a game and have ended up with a structure like this:

1. The UI creates a command object.
2. The UI passes the command object to the game.
3. The game tells the command object to do its thing.
4. The command object invokes the appropriate method in the game.

        I didn't want to invoke the game's commands directly from the UI. I have  
two input systems, one that can build command objects through menus and  
one that can process a command string.

        I need step 2 to allow the game to validate or alter the command.

        Step 3, gives a separate object to handle its commands. Resolves any need  
for case-type statements.

        Step 4 actually calls the code that gets the job done.

I guess what I'm wondering is: Too much? It seems like a lot.

In the game, the code looks like this:

        aCommandObject := aGame process: commandText.
        aGame do: aCommandObject with: player.

In the game object, there's this in "do":

        aCommandObject doWith: player and: self.

and each command object calls back to game, like:

        aGame move: x@y

or:

        aGame strike: x@y with: value

Any thoughts?

        ===Blake===

i'd rather use blocks for this matter. like:

aGame do: myBlock withParams: { commandText. player }



btw, what game you designing?

On 07/05/07, Blake <[hidden email]> wrote:

On Sun, 06 May 2007 23:41:46 -0700, sig <[hidden email]> wrote:

> i'd rather use blocks for this matter. like:
>
> aGame do: myBlock withParams: { commandText. player }

Where do you get "myBlock" from, starting from the UI (which initiates the  
action)?

As for what game, I'm writing a (eventually large) number of small games  
to use as teaching tools. I hope to use the model for a number of them.  
Old-time stuff, like "Star Trek" and "Subhunt".

        ===Blake===

On 07/05/07, Blake <[hidden email]> wrote:
> On Sun, 06 May 2007 23:41:46 -0700, sig <[hidden email]> wrote:
>
> > i'd rather use blocks for this matter. like:
> >
> > aGame do: myBlock withParams: { commandText. player }
>
> Where do you get "myBlock" from, starting from the UI (which initiates the
> action)?
>
from any point you like to. I don't know how exactly your verification
looks like, i given this short code just to show, that you can encode
your action in a block(s) instead of cloning numerous subclasses of
CommandObject for each action type you may need.

On Mon, 07 May 2007 00:52:39 -0700, sig <[hidden email]> wrote:

I get the overall idea, I'm just trying to figure out the details.

So I have:

        aCommand := aGame processCommand: commandText.
        aGame do: aCommand.

And I think you're suggesting:

        myBlock := aGame processCommand: commandText.
        aGame do: myBlock withParams: {commandText. player}

and where I have an object with a do method:

        aGame move:player to:qx@qy sector:sx@sy

you'd skip that hierarchy and put a block, like:

        [|player quadrant sector|
         player := params at: 2.
  self parseLocation: (params at: 1) with: quadrant and: sector.
         aGame move:player to:quadrant sector:sector.]

Is that about right?

        ===Blake===

Be careful there. you might finish up with expired context mess!
Better call it from the place where you have block, do not return it
up the call chain.

yes, in general, you got my point.

Blake wrote:
Cool, Squeak need more games. Have you seen the games at
http://www.swa.hpi.uni-potsdam.de/projects/olpc/index.html

I been hooked on DiceWars for a few days now. It's a risk type game and
really addicting :-)

Anyway, a game framework for Squeak would be really nice. I've seen a
few attempts at it, but nothing that has come past the initial stages.

Karl

i might want to write a game too, when i finish my GLCanvas framework.
http://computeradvenrutes.blogspot.com.

On 07/05/07, Karl <[hidden email]> wrote:

On Mon, 07 May 2007 04:08:27 -0700, Karl <[hidden email]> wrote:

> Cool, Squeak need more games. Have you seen the games at
> http://www.swa.hpi.uni-potsdam.de/projects/olpc/index.html

No, that's very cool.

> I been hooked on DiceWars for a few days now. It's a risk type game and  
> really addicting :-)

I'm hoping to "wrap up" with an implementation of a "Chainmail" type game.

http://en.wikipedia.org/wiki/Chainmail_(game)

I've been fooling with a Seaside interface for online multiplay.

Basically, what I've been doing is writing little games like I the ones I  
copied from Ahl's books:

http://www.atariarchives.org/basicgames/

then using them to explain some aspect of Squeak and/or programming in  
geneal. It's been educative, to say the least. Those old BASIC games were  
inscrutable from a distance. This is one of the better ones:

http://www.atariarchives.org/basicgames/showpage.php?page=79

But, man, they were compact and to the point. I also miss being able to  
see a complete listing so much that I've considered building an editor  
that shows Smalltalk code in a scrollable format and allows editing it  
that way. (Or hoping such a thing exists already.)

Of course, it's so much easier to actually expand a game when it has a  
good design. With the very limited forms of structure available, my old  
BASIC programs used to collapse under their own weight (and sometimes  
they'd just collapse because I'd filled the 120K disk with code, heh). I  
used to say to myself, "Wow, wouldn't it be great if I could call the same  
routine, but with different variable sets, and it could call different  
routines based on what those sets represented...." I was quite  
disappointed when I couldn't say "GOSUB SomeVar$".

> Anyway, a game framework for Squeak would be really nice. I've seen a  
> few attempts at it, but nothing that has come past the initial stages.

Probably a different beast from what I've been doing--although if a get a  
really good command structure going, it could be part of a framework--but  
I agree it would be nice. I've done game frameworks before. I broke them  
up into different types of games (1D, 2D, 3D maps/1D, 2D, 3D  
graphics/real-time vs. turn based, etc. etc. etc.)

        ===Blake===

Blake wrote: Brings back memories from typing in program listing from magazines :-)
Those where the days...
>
> But, man, they were compact and to the point. I also miss being able
> to see a complete listing so much that I've considered building an
> editor that shows Smalltalk code in a scrollable format and allows
> editing it that way. (Or hoping such a thing exists already.)
You could of course use the fileout format and write the whole thing in
a workplace ;-)
2D would suffice I guess, classes for graphics handling,  etc. I have
never made such a framework. I'll look around a little on the net and
see what I can come up with.

Karl

On Mon, 07 May 2007 11:56:47 -0700, Karl <[hidden email]> wrote:

> Brings back memories from typing in program listing from magazines :-)  
> Those where the days...

I've often felt that the Apple ][, with all its crudeness and limitations,  
came very close to Alan Kay's notion of a machine you could understand  
 from top to bottom.

I suppose some people just typed in the listings and played them as-is.  
But I ultimately ran into a significant subset of all the problems I've  
ever encountered hacking those things.

> You could of course use the fileout format and write the whole thing in  
> a workplace ;-)

Heh. Not quite what I had in mind. Visual Basic had a thing where it set  
up lines between subroutines. I didn't like it there because VB code is  
one big text dump. But someting like that in ST could be useful. I find I  
end up with half-a-dozen browsers open to get a fraction of the info a  
listing would give.

> 2D would suffice I guess, classes for graphics handling,  etc. I have  
> never made such a framework. I'll look around a little on the net and  
> see what I can come up with.

Well, I always liked to distinguish between the gameplay dimensions and  
the graphics dimensions. Like, Monopoly is what I would call a 1D game. A  
unidirectional 1D game, even. (You can only move along one axis and only  
in one direction along that axis). But there are 3D representations of it.

But that's a whole nother story.

Blake wrote:
> On Mon, 07 May 2007 11:56:47 -0700, Karl <[hidden email]> wrote:
>
>> Brings back memories from typing in program listing from magazines
>> :-) Those where the days...
>
> I've often felt that the Apple ][, with all its crudeness and
> limitations, came very close to Alan Kay's notion of a machine you
> could understand from top to bottom.
I barely understand most stuff in those old machines, I can get a little
glimpse of what goes on but I don't really understand. More advanced
machines I'm just happy as long as they work, the complexities
underneath the hood is just too much for mere a mortal :-)
>
> I suppose some people just typed in the listings and played them
> as-is. But I ultimately ran into a significant subset of all the
> problems I've ever encountered hacking those things.
That is true. What they also got 'right' in a way was that you had less
distractions from computing. No widows or menus or anything just a
blinking cursor and a manual. It was less daunting than starting to
learn to program a computer now, in many ways. But much worse from a
productivity perspective.
>
>> You could of course use the fileout format and write the whole thing
>> in a workplace ;-)
>
> Heh. Not quite what I had in mind. Visual Basic had a thing where it
> set up lines between subroutines. I didn't like it there because VB
> code is one big text dump. But someting like that in ST could be
> useful. I find I end up with half-a-dozen browsers open to get a
> fraction of the info a listing would give.
There are other browsers out there that you could try, StarBrowser and
whisker comes to mind. I often miss a tabbed browser so I could keep the
number of windows down. Cool, I have never thought about it like that. I looked around a little
and downloaded Eddie Cottongims Wargame again. I think it can be a nice
starting point.

Karl

Karl

On 5/7/07, Blake <[hidden email]> wrote:
> Hey, gang:
>
>         I'm designing a game and have ended up with a structure like this:
>
> 1. The UI creates a command object.
> 2. The UI passes the command object to the game.
> 3. The game tells the command object to do its thing.
> 4. The command object invokes the appropriate method in the game.

This is probably overkill if you are making single person games.  But
if you are making multiplayer games then this is a very good design.
Each person is running an image that has a copy of the game in it.
When either one of them makes an action, the system sends a copy of
the command to the other image, and both images execute the command.
This is by the far the easiest way to make a turn-based, multiplayer
distributed game like most card games or chess or Risk or ...

-Ralph

On Mon, 07 May 2007 13:19:17 -0700, karl <[hidden email]> wrote:

> I barely understand most stuff in those old machines, I can get a little  
> glimpse of what goes on but I don't really understand. More advanced  
> machines I'm just happy as long as they work, the complexities  
> underneath the hood is just too much for mere a mortal :-)

I think building a virtual CPU would be instructive for all programmers.  
<s>

> That is true. What they also got 'right' in a way was that you had less  
> distractions from computing. No widows or menus or anything just a  
> blinking cursor and a manual. It was less daunting than starting to  
> learn to program a computer now, in many ways. But much worse from a  
> productivity perspective.

Another thing I'd kill for is a text-mode Squeak. Cross-platform, able to  
deal with the screen like a 80x25 (or 80x50, or whatever) character grid.  
Not enough hours in the day...

> There are other browsers out there that you could try, StarBrowser and  
> whisker comes to mind. I often miss a tabbed browser so I could keep the  
> number of windows down.

Yeah, I need to look around. But something like all the methods for an  
object in one window, you could open a tab for a new class...

> Cool, I have never thought about it like that. I looked around a little  
> and downloaded Eddie Cottongims Wargame again. I think it can be a nice  
> starting point.

As I said, a whole 'nother story right there. The nature and history and  
programming of games....

Ralph,

> This is probably overkill if you are making single person games.  But
> if you are making multiplayer games then this is a very good design.
> Each person is running an image that has a copy of the game in it.
> When either one of them makes an action, the system sends a copy of
> the command to the other image, and both images execute the command.
> This is by the far the easiest way to make a turn-based, multiplayer
> distributed game like most card games or chess or Risk or ...

Well, that's reassuring. I =am= making a sigle-player game but I wanted to  
make it easy to convert into a multiplayer game. Also, I wanted to be able  
to construct an AI that would play the game as though it were another  
player.

Thanks.

        ===Blake===

On May 7, 2007, at 2:03 PM, Ralph Johnson wrote:

Sounds like Croquet.

Josh



> This is by the far the easiest way to make a turn-based, multiplayer
> distributed game like most card games or chess or Risk or ...
>
> -Ralph
>

Blake wrote:
> Another thing I'd kill for is a text-mode Squeak. Cross-platform, able
> to deal with the screen like a 80x25 (or 80x50, or whatever) character
> grid.

what about an Emacs mode interacting with an headless Squeak via TCP/IP
? this should not be difficult to do once one knows how the text display
is supposed to behave.


Stef