headers
Jason McIntosh | 2 Jul 20:05
Picon

User departure, game suspension, and bot thoughts

Coding like mad, including my attempts to implement [[user departure]]
and its three possible outcomes (throw, suspend, bot). This leads to
some interesting thoughts, including some small protocol changes I
feel are necessary, and some related questions.

User departure stuff:

I think I am going to add suspend_game() and resume_game() to the core
protocol. These are natural complements to start_game() and
end_game(), and allow the client to react to these situations.

Originally I had throw_game() in there as well, to signal the
difference between a natural game-end and an abrupt one, but decided
it was better served by adding an argument to end_game(). That call
now accepts a boolean, and if it's false that means the game was
thrown. The effects are so similar for a user in either case that it
didn't seem right to make a new method for it. Maybe I am wrong.

I don't think any special calls are needed for when a bot replaces a
player. It's pretty self-evident, when it happens.

I have specified that game records can take an optional "finished"
boolean, signaling wether the game finished normally (true) or was
thrown or abandoned (false). (Assumed to have value "true" if not
defined.) Records of unfinished games do not affect players' rankings
for those games' rulesets. (They're still useful for other reasons.)

I grumbled for a while on "finished" versus "completed", because
"incomplete" implies that the game didn't end and never will, and
"unfinished" sounds more like it's in a state of suspended animation.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason McIntosh | 2 Jul 21:54
Picon

Byond: more competition

This somehow managed to escape any of us? Or me, anyway. A kind person
just dropped it in my lap.

http://games.byond.com/start/

Looks like it's got a year or two of lead on us.

Major differences that I can spot from a cursory surf:
* Slick site that looks crammed with useful features, with a focus on
finding games to play right now, much like I had in mind for
volity.net. (Not so much a major difference as a "damn, we need
that".)
* A fairly rich community of game creators (ibid)
* All games are programmed in a single, project-defined, C++-like
language ("DM")
* Servers run on Windows or Linux/BSD/Darwin, but client appears to be
Windows-only.

Well, OK, that explains why I haven't run into this before, then.

This isn't the first similar project we've seen, but it's the first
one I've seen whose public website makes it clear that it too uses a
decentralized game-host approach, as well as boasting a vibrant and
active user community. Very interesting.

--

-- 
  Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jason McIntosh | 3 Jul 09:24
Picon

Re: Standing in the middle of a game

On 7/3/05, Jason McIntosh <zendonut <at> gmail.com> wrote:
> 
> I guess what I'm basically suggesting is that the only kind of
> seat-change permissible when a game is active are players stand()-ing
> themselves 

Oops, not quite true. Players "registered" with a seat -- that is,
those who have sat in that seat earlier in this particular game's
history -- should always be able to return to an old seat after
leaving for any reason. (You have to be sitting in a seat while the
game is active to register with that seat, of course. Config-mode
seating doesn't count.)

--

-- 
  Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Permalink | Reply | 0 comments |
headers
Jason McIntosh | 3 Jul 09:17
Picon

Standing in the middle of a game

Yes, more (rather specific) seat madness, which I welcome your thoughts on.

I don't think we ever talked about what happens when a player tries to
stand up while a game is active.

I see three ways to handle this:
(1) The ref simply shoots down the idea. The player remains seated.
And likes it.
(2) The ref allows the player to stand. If this causes the player's
seat to become unoccupied, the ref begins its user-departure
countdown, exactly as if the player had abruptly left the table
altogether.
(3) As above, except that the ref _immediately_ suspends the game,
resuming it when all seated players voice readiness, exactly as per
the "suspend" timeout reaction defined on [[user departure]]. It will
suspend the game even its its timeout reaction is set to "bot" or
"throw", since overturning the table the instant a player stands seems
obnoxious, and having a bot immediately leap into the seat only
slightly less so.

I think I like option (3) the best, since it involves stuff that the
ref sometimes has to do anyway (in the case of a user-departure
timeout), and doing a countdown while the player is (literally)
standing right there seems weird. Standing is a very deliberate action
(compared to a connection drop) and doesn't seem to fit the automated
response of a wait-for-return timer. Letting the players resolve the
situation seems more natural, to me.

It begs a few side questions, here with my summary answers:
* Can players call stand() on each other during an active game? (No.)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sgeo | 3 Jul 23:11
Favicon

About seats

What if a game is the sort of game that should allow players to enter 
freely?

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Permalink | Reply | 3 comments |
headers
Jason McIntosh | 4 Jul 01:25
Picon

Re: About seats

On 7/3/05, Sgeo <gmane.wiki.Sgeo <at> spamgourmet.com> wrote:
> What if a game is the sort of game that should allow players to enter
> freely?

Not sure what the context of your question is (feel free to give a
specific example) but we had talked about an open Blackjack table
earlier: http://sourceforge.net/mailarchive/message.php?msg_id=12062675

--

-- 
  Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Permalink | Reply | 2 comments |
headers
Andrew Plotkin | 4 Jul 05:21

Re: Byond: more competition

On Sat, 2 Jul 2005, Jason McIntosh wrote:

> http://games.byond.com/start/
>
> Looks like it's got a year or two of lead on us.
>
> Major differences that I can spot from a cursory surf:

...games use bitmap art, and are therefore ugly.

SVG is either going to make us unique, or (if it makes the client too 
slow) kill us dead.

Consequent thought: our demo games are going to have to look clean and 
elegant, if not professional.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Permalink | Reply | 3 comments |
headers
Jason McIntosh | 4 Jul 05:41
Picon

Re: Byond: more competition

On 7/3/05, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
> On Sat, 2 Jul 2005, Jason McIntosh wrote:
> 
> > http://games.byond.com/start/
> >
> > Looks like it's got a year or two of lead on us.
> >
> > Major differences that I can spot from a cursory surf:
> 
> ...games use bitmap art, and are therefore ugly.
> 
> SVG is either going to make us unique, or (if it makes the client too
> slow) kill us dead.

Hey, maybe we can compromise and settle for both? No? OK.

The subtext of what you say is: Our current demo games (that is, the
UI files as I have written them) look like crap, and Javolin remains
underdeveloped. I agree completely, and am antsy to turn my own
attention to the client side of things once I'm done with this
dad-blasted Frivolity update. (Soon! Soon!)

--

-- 
  Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Plotkin | 4 Jul 06:00

Re: Byond: more competition

On Sun, 3 Jul 2005, Jason McIntosh wrote:

> On 7/3/05, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
>> SVG is either going to make us unique, or (if it makes the client too
>> slow) kill us dead.
>
> Hey, maybe we can compromise and settle for both? No? OK.
>
> The subtext of what you say is: Our current demo games (that is, the
> UI files as I have written them) look like crap, and Javolin remains
> underdeveloped.

That was not the subtext, because I haven't looked at any of your SVG UI 
files and I haven't even downloaded Javolin!

Honest.

I've spent the past two months putting together a server/referee system. 
I intend to spent the next two months writing games and making sure 
Javolin can play them. That will involve a lot of client work and (I'm 
sure) a fair amount more server/referee work. I expect to help with the 
Javolin work, but I figured I wouldn't touch it until Frivolity was up to 
date. (That way we'd have a stable client to compare to... and, as Jason 
noticed this weekend, my referee isn't bug-free yet either.)

I'll at least download Javolin this week, but first I have to finish 
de-GPLing my Python code.

--Z
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Plotkin | 4 Jul 06:33

Re: Standing in the middle of a game

On Sun, 3 Jul 2005, Jason McIntosh wrote:

> I don't think we ever talked about what happens when a player tries to
> stand up while a game is active.

I mentioned it in a post at one point, I think.

> I see three ways to handle this:
> (1) The ref simply shoots down the idea. The player remains seated.
> And likes it.
> (2) The ref allows the player to stand. If this causes the player's
> seat to become unoccupied, the ref begins its user-departure
> countdown, exactly as if the player had abruptly left the table
> altogether.
> (3) As above, except that the ref _immediately_ suspends the game,
> resuming it when all seated players voice readiness, exactly as per
> the "suspend" timeout reaction defined on [[user departure]]. It will
> suspend the game even its its timeout reaction is set to "bot" or
> "throw", since overturning the table the instant a player stands seems
> obnoxious, and having a bot immediately leap into the seat only
> slightly less so.
>
> I think I like option (3) the best, since it involves stuff that the
> ref sometimes has to do anyway (in the case of a user-departure
> timeout), and doing a countdown while the player is (literally)
> standing right there seems weird. Standing is a very deliberate action
> (compared to a connection drop) and doesn't seem to fit the automated
> response of a wait-for-return timer. Letting the players resolve the
> situation seems more natural, to me.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane