As both a bit of coding practice and preparing for future personal coding challenges, I had constructed a few mini-games over the last few months. Mini-games, like Code Breaker, a tic-tac-toe game, and other code-practicing projects. As I work towards making the Pegamoose Games site more useful and entertaining, I have decide to share these mini-games and revive older games in some form. The big question hanging over my head is how should these be handled.

When I go to a brick-and-mortar store to purchase a game, this is not an issue. I bring the game home and store it in the game cabinet until it is ready to be played. Simple, huh?

How is that behavior mimicked for a gaming website? This is not one game from one game cabinet played at one table. This will be a variety of virtual game templates to clone multiple game sessions for multiple players each connected to the sessions through their own browser nodes. So many decisions need to be made on how to program such a feat.

Are all games available to all players? Or, are some free and some are available for purchase? Because it is a virtual environment, can a player have more than one session of these virtual games at a time? How are the games organized on the page to differentiate between an active game session versus a dormant game still in the cabinet? How does the site handle solitaire games and multiplayer games? Can players favor some games over others? Should newer games be highlighted over older games? What happens when players are allowed to modify their games, and have the option to kick off a mod-version or the original game?

It boils down to what needs to be done to allow players to quickly find the games they want to play and jump into a game session with people they want to play with. Because this site will support solitaire games, many of which will be designed to be on-going, with other games designed to play with other players, with the possibility of playing over an indeterminate amount of time. I have been more focused on how pieces are manipulated within a game session, I have set aside what happens outside the game session, both before and after the game session.

This and so much more is what I have been brainstorming over the past several days. I am going to break this down into three different moments: presenting the games in the virtual cabinet, inviting others to play, and managing the game session.

Virtual Game Cabinet

Most likely, games will be listed in alphabetical order, but sorted into three buckets: Active, Invitations, and Dormant. Active games are ones in the middle of a game session. Invitations are ones waiting in the wings for players to express their interest in playing or not. Dormant games are ones still sitting in the cabinet of game templates. Each game needs its own entry, listing its title and a thumbnail image. Other information might indicate the type of game, how many players, and other useful details (especially for an active session).

Instead of a home game cabinet, imagine a scenario where a player enters a game hall with different games at different tables. This player wants to play several games at once, and switch between games when it is not their turn. If this were an actual game night, the other players would probably be annoyed with this dude for picking up his phone between turns to play Wordle. Also, this is me imagining a not-ideal-but-possible scenario for a virtual game night scenario.

Back to the scenario, this player is in the middle of Wordle at one table. At another table, they have a game of Sudoku. At other tables, this player is in the middle of a game of Monopoly and a game of Risk. While other players take their turn, this player, juggling multiple games, can return to his Wordle and Sudoku, and then return to these other tables to take their turn.

As the proprietor of this virtual game hall, should I allow a player to jump between games? For the solitaire games…Sure! Why not? The game might not be a quick game of  Wordle or Sudoku. Imagine it is an RPG or simulation game where they can invest time into building their world or their character in short moments of their spare time. Other players may have more issues with game-jumping in the multiplayer games, but these kinds of scenarios need consideration, too.

For multiplayer games, I may have a turn time limit to keep the game progressing as long as at least one player is actively online. When other players are annoyed by this type of game-jumper, they can decide to block him from playing future games with them. Or, maybe I allow the system to let other players will know when the other players are still in a game or when they have stepped away. These are all things to consider when developing a game engine to facilitate virtual table top gaming.

While on the subject of multiplayer games, let’s change focus to explore the social aspect of virtual gaming.

Want to Play a Game?

For multiplayer games, I want Peggy to be flexible for turn-based games to either progress in a (somewhat) timely manner, or allow games to be played “by mail” (not really, but like the days when pen pals would play a game, like chess, over a long period of time, letting the other know the move and when it is the next player’s turn). I want players to dictate how they want to play. I want players to have the freedom to be able to complete a game session in one sitting, or allow them to play over a long stretch of time. Taking turns and the timespan of a game session is another topic. Let’s focus on inviting others to play a game.

After selecting a game to play, the host (I.e., the player inviting others) determines some of the parameters, like how many other players to invite and what variation of a game to play. They declare, I want to play X and am looking for Y players to join me. If the host has an extensive list of friends, they may want to invite specific players or open it to any of their friends. New players on the site might have an interest in playing, but have not yet built up many friend connections. All three options should be available to the host: specific invites, open to their friend list, or open to anyone.

The host should also let everyone know how long the invitation is open. Hey players! You have until this time to respond. The host can cancel the invite if there are no other players, or can start before the deadline when enough players have shown up, or can allow the game to automatically start when the deadline is met. Again, how the invite is handled should be mostly up to the host player.

What should be done when some invited players decline? Should the invite be extended to other friends? Or, globally to all players? This flexibility should be available to the host, too.

What if the host wants to openly invite any interested players? Ok…Maybe not everyone. In past sessions, the host has played with Jimbo, who is a poor loser. The host blocked Jimbo. This open invite should be available to any unblocked players, and should be hidden from any blocked players. What if the host is okay with Jimbo, but his friend Sarah refuses to play with Jimbo and his temper tantrums. If the host has not blocked Jimbo, but his friend Sarah has, when the host invites Sarah, the invite is hidden from friends’ block lists, too.

The game session has not really kicked off, and yet how to handle who plays with who can be a big hurdle to figure out. Let’s move onto the non-host perspective.

What’s Going on Over There?

Before a player decides to host their own game session, they might want to see if anyone else has already made a call for players. A player might inquire a game and see what other sessions or potential sessions might already be available. Associated with the game, others can see existing invite and session information. Maybe seats are still available for a game starting soon. Maybe a player is curious about a game, and wants to be a spectator for an active game session.

One thing I want to allow is for players to view how other people play a game. I want people to be able to jump into a game session to watch, but not interfere with, an on-going game. If a spectator has arrived late, I want them to be able to jump back to the beginning and step through the progress of the game. I even want spectators to be able to read the in-game conversations shared among the players and the game logs. If players want a more private conversation, they are free to use other means, like Discord.

What if the in-game chat gets too heated? Again, the host should have the controls to help police their game session. Mute any player from using the in-game chat. Or, if the host won’t step in, give the option for players to exit a game, ending their participation in that session.

Since the host is the one starting a game session, they are also the one to end a game session at any point, just like players are allowed to exit a game at any point. The session is mostly controlled by the host. The instance of the game is their responsibility to clean up once the game is over. Now, as an admin of the site, if I see that a player has not cleaned up a very stale game session, I may reach out to the host player to prompt them to clean up their virtual room. And, in the event of a ghosted game, the admin can also clean up anyone’s game session.

One thought, for a post-clean-up scenario, I am considering sending the players (through on-site messaging) a brief survey. I might ask questions like, who do they declare as a winner of the game? What did they think of the other players? Should they friend or block anyone? How would they rate their experience? Would they like to offer any feedback?

Game Over

As you can see, there is a lot of decisions to be made when it comes to designing a fully functional, tabletop game engine and website. As the solitary developer, these types of decisions are what challenges this designer, and slows progress of how to program this entire project.

Until next time!