[9front] new game: battleship (aka sink the fleet)

[9front] new game: battleship (aka sink the fleet)

[rgl]

hello everyone!

some of you may remember i started working on yet another game during
the hackathon, an online multiplayer version of Battleship (better
known to some of us as Sink the fleet/Hundir la flota).  well,
yesterday i finished the final touches and i wanted to share it with
you.  now instead of resolving an argument by playing rock, paper,
scissors till exhaustion, you can take the fight to the
(international) seas.

you can pull it from http://shithub.us/rodri/battleship/HEAD/info.html

i set up a server at tcp!antares-labs.eu!3047 for you to play right
now, without having to worry about infra.  if you like it and want to
extend it, feel free to fork and run your own instances all over the
world.

there's also a little howto guide in the readme file.
any bug reports or feedback, please, send directly to me.

hope YOU GUYS enjoy it \:D/


have fun!

-rodri

Re: [9front] new game: battleship (aka sink the fleet)

[qwx]

On Sat Sep  2 17:19:12 +0200 2023, rgl@antares-labs.eu wrote:
> hello everyone!
> 
> some of you may remember i started working on yet another game during
> the hackathon, an online multiplayer version of Battleship (better
> known to some of us as Sink the fleet/Hundir la flota).  well,
> yesterday i finished the final touches and i wanted to share it with
> you.  now instead of resolving an argument by playing rock, paper,
> scissors till exhaustion, you can take the fight to the
> (international) seas.
> 
> you can pull it from http://shithub.us/rodri/battleship/HEAD/info.html

How do you feel about adding this to /sys/src/games?  Me and others
would love to see this added, we lack online multiplayer games.

The *.man files seem to be missing from the repo, so the `all' target
fails.  You should also account for mouse movement while a key is
held; using a trackpoint, if trying to rotate a ship at the start with
mmb, it will keep flipping until your finger is perfectly still, etc.
There's some other small things that aren't bugs that could be
discussed.  Over all, pretty nice :)

Do you plan on adding more stuff?  I'd personally love to see AI
opponents and games with more than 2 players (your code doesn't
entirely assume only two), replays/demos, perhaps spectators, etc. :)

There's other games out there which could be added, so I'd encourage
people to submit stuff (that works and is reasonably complete).  More
games!

Cheers,
qwx

Re: [9front] new game: battleship (aka sink the fleet)

[rgl]

hi qwx!

> How do you feel about adding this to /sys/src/games?  Me and others
> would love to see this added, we lack online multiplayer games.

i appreciate your interest, and i'd love that, but it definitely needs
some polishing before we push it.  :)

> The *.man files seem to be missing from the repo, so the `all' target
fails.

yeah, i started writing a manual for both client and server.  that
will be done soon!

> You should also account for mouse movement while a key is
> held; using a trackpoint, if trying to rotate a ship at the start with
> mmb, it will keep flipping until your finger is perfectly still, etc.

indeed, it sucks.  it was previously implemented using menuhit(2), so
that didn't happen, but then based on some feedback i decided to get
rid of it and forgot to take care of the resulting misbehavior.  i'll
fix it.

> There's some other small things that aren't bugs that could be
> discussed.

there's actually a bug that i want to investigate before i continue
adding stuff.  i found it while adding the user tags, and it's not
pretty; it has to do with some stack overflow and libthread, and i
don't understand it.  increasing the mainstacksize doesn't solve it,
so it seems like a deeper issue.  you can reproduce it by removing the
static attribute from threadmain:user, after which you won't be able
to place the fleet because the Mousectl.xy coordinates go through the
roof (you can see this in real-time by placing a print(2) in /^mouse\(
).

leak(1) points to the getenv("user") that first sets the variable, and
moody also told me to add a watchpoint to &mc->xy, and catch who's
writing on that memory.  i'll dive into this when i have more free
time, probably next weekend.

> Do you plan on adding more stuff?  I'd personally love to see AI
> opponents and games with more than 2 players (your code doesn't
> entirely assume only two), replays/demos, perhaps spectators, etc. :)

one of the things people suggested on the grid was being able to join
as an spectator, and i think that should be easy to implement reusing
the playerq queue, adding a flag to the players and popping only those
who are there to FIGHT.  that way there's no need to change the reaper
nor the matchmaker procs.  i could also add another queue so the
popping remains O(1) and not potentially O(n), but we'll see.

by the code not being restricted to two players, i guess you are right
on the battle proc, since you could add as many players as you want
with a little adaptation.  still, there's only two sides in a battle,
so we'd have to tag the players, add a turn queue and then perform the
actions based on which side they are in.  we also have to think about
how one would join such a game, there're people who will prefer a 1v1,
and others who will want their own group battle.  this sounds like it
would be fun though.  haha

as for the AI, it didn't even cross my mind, but i'd be open to
suggestions/patches.  :)


cheers!

-rodri

Re: [9front] new game: battleship (aka sink the fleet)

[Amavect]

On Tue, Sep 5, 2023 at 5:43 AM <rgl@antares-labs.eu> wrote:
> there's actually a bug that i want to investigate before i continue
> adding stuff.
It is not a stack overflow.
Hint: add a print("I exit now :)\n") after the yield in threadmain.

I've been burned by libthread before, and I'm not convinced that
cooperative scheduling via threadcreate is very useful.
For example, the draw thread is controlling the board reset.
Instead, that should be sequenced by the game logic.
I would move the input and draw threads into main.
Expect some patches soon :)

Good job so far, and love sigrid's anchor cursor!

Thanks,
Amavect

Re: [9front] new game: battleship (aka sink the fleet)

[Stanley Lieber]

On September 5, 2023 9:45:35 PM EDT, Amavect <amavect@gmail.com> wrote:
>On Tue, Sep 5, 2023 at 5:43 AM <rgl@antares-labs.eu> wrote:
>> there's actually a bug that i want to investigate before i continue
>> adding stuff.
>It is not a stack overflow.
>Hint: add a print("I exit now :)\n") after the yield in threadmain.
>
>I've been burned by libthread before, and I'm not convinced that
>cooperative scheduling via threadcreate is very useful.
>For example, the draw thread is controlling the board reset.
>Instead, that should be sequenced by the game logic.
>I would move the input and draw threads into main.
>Expect some patches soon :)
>
>Good job so far, and love sigrid's anchor cursor!
>
>Thanks,
>Amavect
>

this seems really fun. i idled for a couple hours the other night but nobody ever came online.

sl

Re: [9front] new game: battleship (aka sink the fleet)

[rgl]

hey sl,

that's too bad, but there's nothing i can do about it. :/
i think it's best if you set up a battle with someone
out of band, then join the server.

i'll try to improve the ui to show some information,
regarding how many users are online, who was the last
player, when did they leave. stuff like that.

any other suggestions, i'm all ears. :)


-rodri

Re: [9front] new game: battleship (aka sink the fleet)

[sirjofri]

Hey all,

as a game developer at some point I just have to raise my voice, although I didn't have the time yet to take a look at battleship.

06.09.2023 12:49:00 rgl@antares-labs.eu:
> that's too bad, but there's nothing i can do about it. :/
> i think it's best if you set up a battle with someone
> out of band, then join the server.

For that issue, it's probably worth recording a game session with other players as a video, so everybody can take a look at it no matter if someone is there or not. I'd certainly watch it, and it would attract more players.

Because I haven't played the game yet I can't give more advice yet. Only that I started working on some kinda 3d game engine. (The rest of the mail is about that idea, so feel free to skip if you're not interested.)

To be more precise, I'm playing around with the thought of building a full system, including shaders and filesystem that can be implemented as drivers for actual GPUs (but with the first implementation being purely CPU based). It'll probably be a collection of multiple libraries and tools that can be replaced easily.

I don't know how the idea will develop, I'm currently only thinking about it and developing a simple mesh importer library (next will be the renderer). What I can definitely say is, the whole project will take quite some time and it'll start very slowly because I'm busy with other projects, just in case someone wants to collaborate (I know rodri has a bunch of 3d experiments).

Any details and ideas should be discussed in a separate thread, I think.

sirjofri

Re: [9front] new game: battleship (aka sink the fleet)

[Sigrid Solveig Haflínudóttir]

I am not sure what this is about (made me confused) but if you want to talk about your kinda 3d game engine a separate thread could definitely be more useful, because this looks just like an vaporware advertisement butt-in.

Re: [9front] new game: battleship (aka sink the fleet)

[rgl]

hey amavect! long time no see :)

> It is not a stack overflow.
> Hint: add a print("I exit now :)\n") after the yield in threadmain.

oh man, i keep committing this crime.  for some reason i burnt in my
brain that whenever you yield(), the thread doesn't die, it just idles
doing nothing while the other threads get scheduled, until the entire
proc dies.  i really have to read libthread again, or nemo's 9intro
section on the matter, which was very concise.

> For example, the draw thread is controlling the board reset.
> Instead, that should be sequenced by the game logic.
> I would move the input and draw threads into main.

i agree, but implementing it with the conclusion struct seemed like
the simplest idea atm.  in the end it's the same process, so it will
have to wait (blocking) those five seconds after printing the banner,
no matter the thread.  but it can be done better for sure.

> Expect some patches soon :)

cool, i look forward to that.


thank you very much!

-rodri

Re: [9front] new game: battleship (aka sink the fleet)

[Amavect]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On Wed, Sep 6, 2023 at 6:02 AM <rgl@antares-labs.eu> wrote:
> hey amavect! long time no see :)
I'm alive!
Feel free to send me a message if you miss me.

> i agree, but implementing it with the conclusion struct seemed like
> the simplest idea atm.  in the end it's the same process, so it will
> have to wait (blocking) those five seconds after printing the banner,
> no matter the thread.  but it can be done better for sure.
Totally agree, and it's time to make it better.
It's rare for sleep() to be the best option in userspace.
There's often a way to organize the code to block on read or rendezvous.
I think the best option is to prompt the user to queue again.
Then, the program can immediately respond to the delete key,
and the user doesn't have to wait to requeue.

There's 2 other sleep calls in btsd.c.
Those may be removed by using channels instead of your custom list.

>cool, i look forward to that.
Here it is!

Thanks,
Amavect

[-- Attachment #2.1: Type: text/plain, Size: 395 bytes --]

from postmaster@9front:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: text/x-patch; charset="US-ASCII"; name="battleship-0.patch"
	Content-Disposition: attachment; filename="battleship-0.patch"
	Content-Transfer-Encoding: base64
	Content-ID: <f_lm8k9d7l0>

[-- Attachment #2.2: battleship-0.patch.suspect --]
[-- Type: application/octet-stream, Size: 4867 bytes --]

From: Amavect <amavect@gmail.com>
Date: Thu, 07 Sep 2023 02:38:36 +0000
Subject: [PATCH] inline spawned threads to threadmain.


Pointers to automatic variables become invalid
when threadmain exits.
Solution is to reuse threadmain.
Use nbsend to avoid deadlock to the draw channel.
Input struct is no longer needed, inline it.
---
diff 2723bb6ff3e339f7f56a6276fa1c7c9f28d63871 30c064287cdb9c7006088ea38b4dcb62059a4647
--- a/bts.c
+++ b/bts.c
@@ -344,7 +344,7 @@
 		}
 	}
 
-	send(drawchan, nil);
+	nbsend(drawchan, nil);
 }
 
 void
@@ -500,7 +500,7 @@
 		}
 		break;
 	}
-	send(drawchan, nil);
+	nbsend(drawchan, nil);
 }
 
 void
@@ -536,7 +536,7 @@
 		if(rectXarmada(curship->bbox))
 			curship->bbox = ZR;
 
-		send(drawchan, nil);
+		nbsend(drawchan, nil);
 	}
 }
 
@@ -584,7 +584,7 @@
 		layoutdone++;
 		break;
 	}
-	send(drawchan, nil);
+	nbsend(drawchan, nil);
 }
 
 void
@@ -605,7 +605,7 @@
 		if(rectinrect(newbbox, localboard.bbox) && !rectXarmada(newbbox)){
 			curship->p = toboard(&localboard, mc->xy);
 			curship->bbox = newbbox;
-			send(drawchan, nil);
+			nbsend(drawchan, nil);
 		}
 	}
 
@@ -639,44 +639,6 @@
 }
 
 void
-bobross(void *)
-{
-	while(recv(drawchan, nil) > 0)
-		redraw();
-	sysfatal("painter died");
-}
-
-void
-inputthread(void *arg)
-{
-	Input *in;
-	Rune r;
-	Alt a[4];
-
-	in = arg;
-
-	a[0].c = in->mc->c; a[0].v = &in->mc->Mouse; a[0].op = CHANRCV;
-	a[1].c = in->mc->resizec; a[1].v = nil; a[1].op = CHANRCV;
-	a[2].c = in->kc->c; a[2].v = &r; a[2].op = CHANRCV;
-	a[3].op = CHANEND;
-
-	for(;;)
-		switch(alt(a)){
-		case -1:
-			sysfatal("input thread interrupted");
-		case 0:
-			mouse(in->mc);
-			break;
-		case 1:
-			resize();
-			break;
-		case 2:
-			key(r);
-			break;
-		}
-}
-
-void
 celebrate(void)
 {
 	static Image *c;
@@ -762,7 +724,7 @@
 		}
 		break;
 	}
-	send(drawchan, nil);
+	nbsend(drawchan, nil);
 }
 
 void
@@ -821,15 +783,10 @@
 threadmain(int argc, char *argv[])
 {
 	char *addr;
-	/*
-	 * TODO
-	 * if it's not static it messes with in.mc->xy later, probably
-	 * because of an stack overflow somewhere.  have to investigate
-	 * with wpset("w", &in.mc->xy, sizeof(Point*)); in acid(1)
-	 */
-	static char *user;
+	char *user;
 	int fd;
-	Input in;
+	Mousectl *mc;
+	Keyboardctl *kc;
 
 	GEOMfmtinstall();
 	ARGBEGIN{
@@ -856,15 +813,15 @@
 		sysfatal("newwindow: %r");
 	if(initdraw(nil, deffont, "bts") < 0)
 		sysfatal("initdraw: %r");
-	if((in.mc = initmouse(nil, screen)) == nil)
+	if((mc = initmouse(nil, screen)) == nil)
 		sysfatal("initmouse: %r");
-	if((in.kc = initkeyboard(nil)) == nil)
+	if((kc = initkeyboard(nil)) == nil)
 		sysfatal("initkeyboard: %r");
 
 	display->locking = 1;
 	unlockdisplay(display);
 
-	mctl = in.mc;
+	mctl = mc;
 	if((user = getenv("user")) == nil)
 		user = getuser();
 	snprint(uid, sizeof uid, "%s", user);
@@ -880,13 +837,38 @@
 	game.state = Waiting0;
 	csetcursor(mctl, &patrolcursor);
 
-	drawchan = chancreate(sizeof(void*), 0);
+	drawchan = chancreate(sizeof(void*), 1);
 	ingress = chancreate(sizeof(char*), 1);
 	egress = chancreate(sizeof(char*), 1);
-	threadcreate(bobross, nil, mainstacksize);
-	threadcreate(inputthread, &in, mainstacksize);
 	threadcreate(netrecvthread, &fd, mainstacksize);
 	threadcreate(netsendthread, &fd, mainstacksize);
-	send(drawchan, nil);
-	yield();
+	nbsend(drawchan, nil);
+
+	Rune r;
+	enum {MOUSE, RESIZE, KEYS, DRAW, NONE};
+	Alt a[] = {
+	[MOUSE]  = {mc->c, &mc->Mouse, CHANRCV},
+	[RESIZE] = {mc->resizec, nil, CHANRCV},
+	[KEYS]   = {kc->c, &r, CHANRCV},
+	[DRAW]   = {drawchan, nil, CHANRCV},
+	[NONE]   = {nil, nil, CHANEND}
+	};
+
+	for(;;)
+		switch(alt(a)){
+		default:
+			sysfatal("input thread interrupted");
+		case MOUSE:
+			mouse(mc);
+			break;
+		case RESIZE:
+			resize();
+			break;
+		case KEYS:
+			key(r);
+			break;
+		case DRAW:
+			redraw();
+			break;
+		}
 }
--- a/btsd.c
+++ b/btsd.c
@@ -299,14 +299,12 @@
 }
 
 void
-listenthread(void *arg)
+listenthread(char *addr)
 {
-	char *addr, adir[40], ldir[40], aux[128], *s;
+	char adir[40], ldir[40], aux[128], *s;
 	int acfd, lcfd, dfd, sfd;
 	Player *p;
 
-	addr = arg;
-
 	acfd = announce(addr, adir);
 	if(acfd < 0)
 		sysfatal("announce: %r");
@@ -357,6 +355,7 @@
 	case 'a':
 		addr = EARGF(usage());
 		break;
+	default: usage();
 	}ARGEND
 	if(argc != 0)
 		usage();
@@ -363,6 +362,5 @@
 
 	proccreate(matchmaker, nil, mainstacksize);
 	proccreate(reaper, nil, mainstacksize);
-	threadcreate(listenthread, addr, mainstacksize);
-	yield();
+	listenthread(addr);
 }
--- a/dat.h
+++ b/dat.h
@@ -31,7 +31,6 @@
 	KB = 1024,
 };
 
-typedef struct Input Input;
 typedef struct Ship Ship;
 typedef struct Map Map;
 typedef struct Board Board;
@@ -39,12 +38,6 @@
 typedef struct Playerq Playerq;
 typedef struct Match Match;
 typedef struct Chanpipe Chanpipe;
-
-struct Input
-{
-	Mousectl *mc;
-	Keyboardctl *kc;
-};
 
 struct Ship
 {

Re: [9front] new game: battleship (aka sink the fleet)

[rgl]

looks good. pushed :)

i will work on the other stuff this weekend.


thanks amavect!

-rodri

Re: [9front] new game: battleship (aka sink the fleet)

[rgl]

hi there,

i've fixed some of the issues we talked about, namely:

- mk install failing due to a lack of manpages
- ships rotating when pressing mmb while moving the mouse
- using a custom queue for the players and polling instead of a csp
channel

also, amavect fixed the problem with the use-after-free of stack
variables and my yield(2) abuse.

here's the list of things that i'm going to work on next:

- a better conclusion procedure: this means getting rid of the 5s
	sleep and waiting for the player to press (almost) any key to
	continue.  to do this right, the server shouldn't reschedule the
	player immediately after a battle, but wait for the player to signal
	their interest to keep playing; this will require radical changes in
	the match-making and battle procs, since right now client messages are
	only processed during a battle.
- spectator mode
- one of these three:
	- NvM battles
	- Salvo variation of the game (documented in battleship.pdf)
	- a rudimentary AI

i'm thinking the AI could be offline, so there'd be no need to join a
server, or online, in which case the player should be able to opt-in
through a program flag or runtime menu.  then instead of waiting for
another player to join, the server will automatically schedule an AI
battle.


feel free to share any relevant ideas or code. i'll keep you updated.

have a good weekend!

-rodri

Re: [9front] new game: battleship (aka sink the fleet)

[Amavect]

On Sun, Sep 10, 2023 at 7:00 AM <rgl@antares-labs.eu> wrote:
> - a better conclusion procedure: this means getting rid of the 5s
>         sleep and waiting for the player to press (almost) any key to
>         continue.  to do this right, the server shouldn't reschedule the
>         player immediately after a battle, but wait for the player to signal
>         their interest to keep playing; this will require radical changes in
>         the match-making and battle procs, since right now client messages are
>         only processed during a battle.
> - spectator mode
> - one of these three:
>         - NvM battles
>         - Salvo variation of the game (documented in battleship.pdf)
>         - a rudimentary AI
These might require adding a version negotiation to your net protocol.
Also consider writing a specification of the net protocol,
if only just to organize your thoughts.

Thanks,
Amavect