search

drwhut / tabletop-club

An open-source platform for playing tabletop games in a physics-based 3D environment for Windows, macOS, and Linux! Made with the Godot Engine.
https://tabletopclub.net
MIT License
1.3k stars 57 forks source link

User Stories Super Issue #71

Open leogott opened 2 years ago

leogott commented 2 years ago

This is a super issue to collect my (real and imagined) user stories, which can then be spun-off into discrete issues with concrete change-requests -- if necessary. I'll add more user stories below when I come up with them.

User Story 1 I am a newbie game dev potentially interested in developing for/with tabletop simulator. I want to open the game with the godot editor, and be able to start a game, move a few pieces and cards around and click through some menus, before commiting to spend more than 15 minutes, to recompile godotengine or whatever. I do not care about importing assets, or full functionality, I expect some kind of popup, or a grayed-out "import assets" button with a tooltip informing me that (and why) the functionality is missing though.

User Story 2 I am a player frustrated with TTSim (for whatever reason) and trying to port my favorite games to Tabletop Club. I am willing to commit a lot of time, but I want to see some of my files in-game before commiting to read more than a hundred words of online documentation/instructions. I expect to see some in-game menu aiding me in the process of creating custom assets.

User Story 3 We are two players on one computer and want to both join a game online, in which we aren't allowed to see each others cards. We need a way to switch between two hands of cards and have a state in-between, where the screen doesn't show either. We'd like to both be displayed as seated with our respective names.

drwhut commented 2 years ago

User Story 1: #72 User Story 2: #73

User Story 3: This one would require an overhaul of the multiplayer system to implement as you've described, but I think there is a workaround: by having two game instances open at the same time, both fullscreen, then both of them connecting to the same lobby, you can have two players play on one computer, and as long as the player that isn't playing isn't looking, and the players switch windows with Alt-Tab when switching positions, then it should be OK. Granted, I have not tested this, this is just how I would go about solving that problem.

cosmojg commented 2 years ago

User Story 4 I'm a curious passerby looking to test the online multiplayer and learn more about the software. I'm used to open-source games with built-in multiplayer, like TripleA for example, providing a public lobby where I can chat with other players and set up games with them. I click "multiplayer" with this expectation and try to set up a game.

(Sorry if this is too indirect. I couldn't think of a better way to suggest this feature without creating an issue for it.)

drwhut commented 2 years ago

For that, the only thing that can't really be accomplished is setting up a public lobby. The game uses a room-code system, so when you host a game, you're given a code that you can give to your friends to join. I guess you could share the code with a large group and that would constitute being public, but there's no server browser or anything like that - and that's by design. Since there's no "online accounts" for the game, there's no way to prevent "trolls" from repeatedly joining a public game.

cosmojg commented 1 year ago

For that, the only thing that can't really be accomplished is setting up a public lobby. The game uses a room-code system, so when you host a game, you're given a code that you can give to your friends to join. I guess you could share the code with a large group and that would constitute being public, but there's no server browser or anything like that - and that's by design. Since there's no "online accounts" for the game, there's no way to prevent "trolls" from repeatedly joining a public game.

A server browser would be nice! I think you could easily avoid the trolling issue without any sort of "online accounts" by allowing users to set passwords on game servers and/or allowing users already in a given game server to approve/deny requests to join from users using the server browser. You could also allow for "unlisted" games which maintain the current functionality.

As for creating and running a public chat lobby available prior to joining a server through the server browser, I agree that's quite a bit more complicated. I'm sure people would eventually step up to moderate, and IP bans might be sufficient in the short term. However, I can't think of a good way to keep things spam-free in the long term. Maybe a system where everyone is muted by default, but alongside the chat window, there exists a list of users whose chosen and/or randomly generated per-session usernames light up every time they send a message? Curious new users can selectively unmute active names to listen in on conversations, ping said users as a request to unmute them if they're interested, and join the conversation to set up a game.

Anyway, I'm just throwing ideas at the wall hoping to see if any stick with you. While these features admittedly do come with some risk, I think they'd be great for growing the community.

Are you firmly against anything in this direction? Or would you be willing to consider pull requests implementing some of the features I described?

drwhut commented 1 year ago

I'm not against having public lobbies and a server browser per say, it's just that as of right now, there's little to no mitigation against trolls, so systems would have to be in place to be able to kick/ban trolls before allowing publc lobbies. As you mentioned, things like IP address bans can help in this regard.

If I understood your post correctly, I'm not so sure about having a public chat before joining lobbies at this stage. There's just too much that people would be able to do (even with e.g. IP bans), I would feel a lot more comfortable having a dedicated moderator first before making that feature live.

I appreciate the offer to make PRs! Although, this change would need a complete re-writing of the master server and the way the master server and the client communicate, I think it's safer if this was implemented in a future update (v0.2.0, v0.3.0, etc.)