The post Writing RPG Adventures appeared first on PegamooseG's Blog.

• Massive projects require several small steps. Stressing over those steps add up to a huge headache.
• Be mindful how minor steps can lead to major progress.
• Progress is not always visible. Not every moment needs to be dedicated to building a thing.
• Remember all things are made of smaller parts, and they all add up to a greater whole.

The post Small Steps, Big Picture appeared first on PegamooseG's Blog.

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!

The post Want to Play a Game? appeared first on PegamooseG's Blog.

Instead of a challenge for random piece behaviors, why not create a simple game? Or, I could recreate one of ye olde Pegamoose Games from many years ago. I constructed a list (in one of my work tickets) of the various solo mini-games. Dress-a-Moose was very similar to elements of the first few challenges, for this one, I intended to present a “naked” pegamoose image and a variety of items to decorate it. I decided to table this challenge for a bit to work on a “Code Breaker” prototype instead.

History

Code Breaker is my variant of another game I have played under a couple different names (Master Mind the tabletop version, and Hits and Blows on Nintendo Switch). These games arrange four colored pegs in a row and the player guesses what the colored pegs are based on feedback after each unsuccessful guess. A different set of pegs indicates which colored pegs are the correct color and in the correct position, a correct color in a wrong position, and which are flat out wrong.

As I outlined the work and brainstormed ideas for Code Breaker, I considered making the “secret codes” of colors increasingly more difficult. I considered allowing players to specify how many code digits to guess and other, possible game options. As much fun as I thought these ideas might be, I reminded myself, “Keep it simple, stupid!” After all, the challenge is meant to be a basic prototype plus a bit of coding practice.

My Variant

The current prototype includes a secret code of six digits, instead of the usual four. Hits and Blows allow the option for no duplicates or colors used twice. In my version, any color may be duplicated up to six times. If my rusty, dusty math is correct, that makes six to the power of six possible different codes (or 46,656 unique codes). Instead of limiting the game to eight guesses, my version provides unlimited guesses.

The four types of hints this variant provides are:

1. An empty square indicating the player did not specify a color for a space.
2. A green check for correct guesses in a correct space.
3. A yellow yield for correct color in a wrong space.
4. A red X per incorrect guess.

Hurdles

The trickiest part of this project involved accurately calculating the hints. Correct guesses? No problem! Guessing a color not in the code? Piece of cake! Empty spaces? A scoop of ice cream with that cake! Everything else…Uh…

In my first attempt, I figured everything else would be the number of spaces minus the correct and incorrect guesses. Something was not quite right with this possible solution and the yield hints did not accurately reflect the comparison of the code versus the guess. I tweaked the code to check for right colors in the wrong space, but a miscalculation resulted in more hints than possibly number of spaces. Try again.

I tried several times to calculate the yellow yields accurately. I encountered difficulty distinguishing the difference between a color in the wrong space and guessing a color too many times (which should result in the red X, instead of yellow yield). This is what resulted in indicating more than six hints, one for each space. For the final solution, I realized I needed to compare the counts of colors for both the guesses and codes.

Design Decisions

One design decision evolving out of this project, I had considered dragging and dropping the colors into the different slots. I may do that for the “live” version (as a Pegamoose Games featured mini-game). I think the point and click (or double-click) works well enough for this prottype.

When I started this project, I had used underscores for the blanks and question marks for the code placeholders. As I wired in the colorful pegamooses (which I had intended to use from the start), I remembered I had also created a mystery token with a question mark and an empty circle.

Restarting a game is as easy as reloading the page. I provide this in a New Game button, too. Plus, I added another button for the rules. Plus, two more buttons for either clearing a selected blank or clearing the entire guess.

Future Considerations

At the moment, because of “unlimited” attempts, I want to issue points for the different types of incorrect guesses. To prevent the game from truly being unlimited, I might cut the game off when a player meets or exceeds a threshold score.

Once the game is wired into Peggy, I may consider those additional options mentioned earlier in the blog for adjusting the constraints of the game for a possible deluxe edition of the game. Players could earn points when the game ends with scores falling within certain ranges. Also, because players would login to their account, the Peggy version would preserve game states so players may continue an in-progress game at a later time. Play at your leisure!

Another possible feature, I may have thought earlier, but am thinking it now as I write this blog, is to allow the player to click on one of their rows of guesses and fill in the guess with the same set of colors. This might be particularly useful the more accurate a player’s guess.

Play on!

Here is the link if you would like to play this Code Breaker prototype:

https://pegamoosegames.com/games/codebreaker/

All in all, I am very proud of myself for making a very playable, working prototype that can be wired into the final product once Peggy is more “live-worthy”. A majority of this project was completed within two to three days. More of these types of mini games help the site get closer to a “live-worthy” status.

If you have any suggestions, please share in the comments section. Or, if you have suggestions for other mini games, I would like your input on that, too!

The post Code Breaker (Prototype) appeared first on PegamooseG's Blog.

Currently, I have three roadmaps for the Pegamoose Games website. I have developed other roadmaps for my more recent books, which I refer to as IPCs (Indie Publishing Checklists). These checklists are for the entire story publishing process, from outlining an idea to providing a post-production marketing checklist, and every step in between. Essentially, outlines and checklists are forms of roadmaps. They are a series of checkpoints helping navigate to a desired goal.

Why does Pegamoose Games need three roadmaps? Because, one is for the epic journey and the other two are major side-quests. The main roadmap states what to do to help build and run my business, and features for the website to support the business. The other two are for two game engines, which will be key products for the business: one for Peggy (tabletop game engine), and one for Reggie (role playing game engine).

Developing a Roadmap

The first thing to designing a well-crafted roadmap is to hire a really good cartographer and a professional origamist to fold your maps. More jokes. No cartography or folding are necessary when designing a roadmap, but it will require work.

Above, I mentioned IPCs and outlines., because developing a roadmap is similar to outlining a story. They are called roadmaps because it can be like planning an epic journey. You know where you are starting from and you know your destination. Break down that journey to figure out the points of interest along the way.

Two Points

Start with the beginning and end points. What do you currently have? What are you trying to achieve? Where do all the other dots come from to connect the beginning and the end? I suggest as much brainstorming as necessary to start filling in the details. Do not dismiss any ideas, and do not stress over any missing details.

Brainstorming

To kick off the brainstorming, consider the difference between what you already have and what you need. For example, I have a website for Pegamoose Games, but the goal is to allow people to play games online. What do I need? Player accounts? Games to play? Maybe a store to facilitate what games players want to play? Maybe a leaderboard? This is great! Four additional points on the map!

Each of those midpoints may require more granular brainstorming to iron out additional details our journey. We start with the site having no player accounts, and work towards establishing the winner of a game. What happens in between those points? Do not stress over organization during the brainstorming phase. Just get all those ideas out and noted. In fact, you might consider brainstorming onto Post-It notes or index cards for when you do begin organization.

Organizing

We now have ideas all over the place. How should we go about organizing these ideas into something more linear? First, group ideas together into piles that make sense. Let’s take player features as an example. Each player needs and account. Their account most likely will need a profile. We might include password recovery in the event a player cannot log in. Players will friend and block other players. Players have a set of games they have purchased. Players will need a way to invite others to play a game. Some players may have active game sessions. These are all important aspects of the site involving the players, but it is a bit of a mishmash of different things players have or can do. It is messy, but a good start. You might even wonder if Player Accounts belongs with the pile of Player-related ideas or the Access Control-related ideas. Either pile is fine at this point.

Ordering

Now we have vague piles of ideas, grouped by concepts that may overlap with other groups. Start ordering those piles into a logical progression. You may start at the beginning. Typically, I organize better starting with the end and working backwards. Eventually, I will bounce around to help smooth the progression. The end goal is to have players playing online games. Games and Players fall before the end goal. Which is first? We need Games to attract Players to the site. Good. Games is now before Players. But, Players are needed before there can be a Game Session. Ah. This is where logic begins to divide those piles. There is now a new pile for Game Sessions which is after another pile for Game Design. And, a Player Account pile is before the Player Sessions pile. Continue this process enough, and there is general outline as the first draft of a Roadmap. Congratulations! We can finally get this show on the road!

Detours

Adjusting

Once the roadmap has a logical progression between the beginning and the end, it is time to kick off the journey. Start at the beginning to work your way towards the ultimate end goal. Uh oh. Things were going fine, but we have hit a snag!

Like any road trip, keep in mind you may need to deviate from your route. Recalculating and adjusting the roadmap along the way is essential. This is why map systems don’t continue to follow the same route when the driver deviates. It may nag you to get back to where it thinks you should be, but unforeseen things happen and there may be setbacks.

The roadmap is not set in stone and should be referenced and modified as often as necessary. As the project evolves and has setbacks, the roadmap should be edited to accommodate for the evolving landscape. Like the long car trips we had as a kid, we sometimes took detours to visit a corn maze or see the world’s biggest horse shoe. Then, we checked the map and returned to our plotted route. Going off on tangents happens all the time, and is nothing to stress about. Recalculate your route and keep going as best you can.

Documenting

One other thing I recommend is documenting the journey. For development projects, this may be in the form of detailed design docs and work tickets. For writing, this may be keeping a bible of events and characters. Any time you associate adequate documentation while following the roadmap, these details act like the map’s legend, providing key information to reference to help better understand where you are going and why.

There have been times when I do not provide enough details, and I begin to question my design decisions. I may go off on unnecessary tangents or second guess a design, develop a different way, and realize why I settled on the original design.

Other times, I may have provided enough details, but some new factor is introduced which may impact various points on the roadmap. I can refer to all my notes to better decide what is best approach for getting things back on track. Things happen. Refer to the roadmap, make changes where necessary, and keep moving forward.

Driving Blind

This seems like an awful lot of work. Are roadmaps really necessary? For bigger projects, yes, some form of roadmap is necessary. If the project is small enough, you may not need an elaborate roadmap. You may not think you need a roadmap, but even when you microwave a meal, how often do you double check how much time it should be heated? Those microwave instructions are a roadmap in a basic form.

When you progress through the same steps over and over, you may realize you no longer need a roadmap. Just like going to the store each week, you most likely do not need your GPS system, unless there is traffic or construction diverting your memorized route.

I do not need a recipe to make a breakfast scramble. I generally know what to add and when and how long to cook it. But, designing games and self publishing a book is not the same as whipping together a few ingredients into a meal. When necessary, I recommend providing some form of roadmap.

In the writing world, we refer to those who follow roadmaps versus those who do not as Plotters and Pantsers. The Plotters make plans. They take time to create an outline for the story and a checklist to get it published. They adjust their plans based on feedback. The Pantsers, on the other hand, “fly by the seat of their pants”. They make it up as they go. They start a story, throw in some characters, and see what those characters get up to and where the story goes. I do not know how Pantsers do it. Some are good at making it all up as they go along. Not me. I am a definite Plotters. Even this blog started with an idea, evolved into an outline, and became this blog. I even adjusted and edited out bits as I wrote it.

What type of worker are you? Are you a Plotters or a Pantser?

What kind of roadmaps help you with your projects?

The post Roadmapping appeared first on PegamooseG's Blog.

• A growing set of proof-of-concepts demonstrates a monumental project is achievable.
• Each code sample is a reference point when coding the main project.
• Smaller chunks narrows the view of how to construct the larger features.
• Be diligent when commenting the code. Also, journal thought processes and design decisions.
• Consider all sides of simplifying. Is there a better way? Is it simpler than a current implementation? Is anything neglected by simplifying?

The post A Little Chunky appeared first on PegamooseG's Blog.

I know. It sounds crazy to claim the different pieces are cards. In the confines of Peggy, it makes perfect, crazy sense. Plus, it simplifies a lot of the design.

Let’s back up a moment. First, picture in your mind a typical playing card. Think about the characteristics of that card. Consider its physical aspects and how it functions.

An average playing card essentially has two sides. Yes, I know it also has a very thin depth, but game-wise, players are mostly concerned with its two sides. One side is the back, which most often shares the same image as the other cards in the deck. This is to help obscure its position in the order of the deck. The other side is the face. Unless decks are combined or there are duplicates, most often, the face is a unique image between the other cards in deck. It has various symbols to help identify the face (suit and rank). That is what a playing card looks like. How does it behave?

Think of the various ways you can manipulate a playing card. The card exists in three-dimensional space. It can move in various directions, like tossed into a hat or slid across a table. You can flip the card over to show the back or the face. It can be rotated.

When using cards as a deck, there are even more ways to manipulate the cards. They can be dealt or drawn from the deck. They can be stacked as the deck or discard pile. They are separated and assigned to the players. Sometimes they are played individually or as a set. They can be collected into tricks. The deck can be ordered or shuffled. When it comes to their physical location, they can be positioned together to build a card house.

Now, applying rules of a game to the deck of cards, things get even more complex. Cards are provided greater meaning, like Chance cards in Monopoly, or the Suits and Ranks as in Bridge. The Monopoly cards declare an action which assists or hinders the player(s). At casinos, there are even rules when players are allowed to interact with the cards.

Got all those concepts in your head? Yeah. It is a lot. And, that is why there are so many different games people can play with something as simple as a deck of cards.

For Peggy, I focus on roughly two-thirds of the above characteristics and manipulations of the game pieces. That is why I want to leave the enforcement of the game rules and protocols to the players. There are already enough other aspects of cards for the game engine to consider and maintain.

All that is complicated enough, and we have not even discussed pawns or dice. Oh, man. I have to worry about those pieces, too? (Sigh)

Yes and no. This is where treating them like cards helps. Dice and pawns share many of the same characteristics. When you think about dice and pawns as a variant of a card, there really is not much more to think about apart from what has already been established for cards.

How is a pawn a card? Think of a pawn as a one-sided card which may be moved two-dimensionally around the game board. That game board is also a one-side card, but it does not move. It is positioned on the table and left alone. For Peggy, it is one piece that is established at set up and does not need to be tracked. Even game currency is essentially pawn-cards in various denominations.

Ok. What about dice? How are dice cards? Think of a single die as a deck with a certain number of cards and each card is one of the die’s faces. Put enough of these decks together, you have a set of dice. Rolling the dice is equivalent to drawing a card from each deck. The decks are ordered if the value ever needs to be incremented of decremented.

For Peggy, when I consider all game pieces (or most pieces) as cards and program the card behaviors, the other game pieces fall into place. Tracking pieces becomes tracking subsets of various decks of card types. If all pieces are treated as cards, I can even make game pieces difficult to replicate in real life, like a seven-sided die or a card with three sides.

Plus, there are some elements I can ignore. I am not building an engine to stack cards into a card house. Nor, am I allowing cards to be tossed into a hat. Other pieces, like a score board, would be considered an additional feature which will be tracked differently and independently to the other pieces.

As I said…It is all in the cards.

The post It Is All in the Cards appeared first on PegamooseG's Blog.

Games that Unfavorably Increase the Odds

Before I talk about Rummy, I want to say I am not completely opposed to games favoring one player over the others. Mainly, because some games are designed to be that way. As the game progresses, the stakes are raised, making it much more challenging to win. Chess is a game in which the odds typically favor the player with the most remaining pieces, but the opposing player hinders themselves by losing pieces and not the rules of the game altering to favor the lead player. Although games like chess are head-to-head, usually, the kinds of games where the odds increase are more collaborative, instead of everyone for themselves.

I had played Space Hulk in college. If you are unfamiliar with this game, it is essentially like the tabletop version of the Alien movie franchise. Players work as a team to achieve a specified objective, but they run out of ammo, or their guns jam, and eventually, they are way outnumbered by deadly, hard-to-kill aliens. That game is tipped a little too much towards the aliens.

In recent years, I have discovered a couple games which are similar, but feel more achievable. Forgotten Island is a game in which players try to acquire four artifacts before the island sinks. As the game progresses, the island sinks faster. Forbidden Desert is the sequel, where the treasures sink under increasingly difficult to remove mounds of sand. Betrayal at House on the Hill is another collaborative game in which, at a specified point in the game, one player becomes the traitor. There are multiple scenarios in which the traitor betrays the others, and usually the end game favors the traitor over the remaining team. This game has incredible replay value based on how the different scenarios play out and the map is constructed.

Those kinds of games, I appreciate the unbalanced favoriting of one side over the other. Rummy, on the other hand…

Rummy

Typically, I dislike most Rummy games. Our friends have a variant of the game I particularly dislike. The reason I do not like Rummy is because it relies heavily on luck of the deal and luck of the draw. There is little, controllable strategy to the game. Based on the initial deal, you can guesstimate which cards to try for, but once you realize others playing are after the same card, your “strategy” is in jeopardy with little room for course correction.

The reason I really dislike our friends’ variant of the rules is because the game heavily favors the leading player(s). While players covertly collect cards they need to start laying cards down in sets and runs, the game is fairly matched, but, like I said, at this point relies mostly on luck of the deal and the draw. There are a couple of minor strategies players can use, but if it does not help enough, it can backfire at the end of the round. This strategy is called “buying”. One form of buying is a player attempting to call dibs on a discarded card. If allowed, the player buys the discard and with the price of drawing an additional random card from the deck.

Buying can be squashed by the player who is taking their turn and they claim the card for themselves. When a buy is squashed, it exposes what card a player seeks to the rest of the table. Whether they need it for a set or run may not be known, but it weakens the player in need who is now denied what they seek.

The other form of buying is during a player’s turn, in which they can “blind buy”, which is drawing the top two cards from the deck. Both of these strategies could help the player get cards they need, but if the cards are not helpful enough, all cards will count against them at the end of the round. Again, a good portion of this strategy is based on luck of the draw.

Once a player has what cards they need to lay down their sets and runs, the game drastically shifts to favor players with cards on the table. If they can lay down all their cards, all other players accumulate points for the cards still in their hands.

Most often, players cannot put all their cards down on the table, but on their next turn, they may add any remaining cards to other player’s cards on the table. The more variety of cards on the table, the more beneficial it is for players trying to get rid of their last few cards. Players who have not played any sets or runs will find it increasingly difficult to even discard a card at the end of their turn.

On each turn, players draw a card (or more with a blind buy) and end their turn by discarding a card. This is yet another way to favor the lead(s) and restrain the lag(s). When a player discards a card playable on another player’s sets or runs on the table, any player with cards on the table may claim that discard to place in the appropriate collection of cards, plus discard an additional card from their hand. Once again, as more and more people are able to lay cards on the table, this makes it much easier for the lead players to continue getting rid of cards, while it makes it much harder for the lagging player to discard something that does not benefit any of the leading players.

If you are a lagging player who sees someone else lay down similar cards to what you are collecting, your strategy is out the window and too late to do anything about it other than dump as many points from your hand as you can while trying not to help a lead player go out sooner.

This is why I find this variant of Rummy incredibly frustrating.

How I would balance out Rummy?

Five Crowns is one rummy game I enjoy playing very much. The game has a couple mechanics to help reduce the unbalanced frustrations. Both games use a double deck of cards, with the exception Five Crowns drops the aces and twos and adds a fifth suit (stars).

First, there are the number of wild cards. Both decks include jokers, which act as wild cards. Rummy includes four jokers in the entire 108 card deck. Five Crowns includes six jokers in the entire deck of 116 cards. However, each round of Five Crowns, one of the ranks is also considered wild, which means each round includes sixteen wild cards, which greatly benefits all players.

Second, when one player “goes out”, meaning they lay down their entire hand of cards on the table in sets and runs, all other players have one more turn with the opportunity to lay down as much as they can by playing any valid runs or sets. This can greatly reduce the number of cards counting against them.

To improve our friends’ rummy variant, I would borrow elements from Five Crowns to improve the balance. Since it uses standard decks, maybe declare aces and twos as always wild, which would bring the wild card ratio to twelve out of 108 cards. Allow players to set down portions of their hand instead of making them wait until all requirements are fulfilled. Maybe a lagging player has a set, but not a run, or vice versa. They could lay down what they have, reducing the number of cards in their hand. However, because the requirements are incomplete, maybe the player cannot player on other player’s cards until both are satisfied, but other players with both can play on theirs. Plus, they are not able to go out, bringing an end to the round, until both are satisfied.

To me, games are meant to be fun. Challenging at times, but enjoyable to play, especially with a group of friends. Why gather together only to be frustrated?

What games do you dislike? Do you dislike them because they are unbalanced? Or, is it for other reasons?

The post Unbalanced Games – Part Two – Rummy appeared first on PegamooseG's Blog.

What makes a game unbalanced?

While looking up games other people consider unbalanced, some people define an unbalanced game by how often a player wins. When a player wins too often or not often enough, they consider the game unbalanced. I don’t entirely agree with that. One person might win a game often, because they are very skilled at the game, while another player who doesn’t win much may still be a novice. This does not necessarily mean the game itself is unbalanced, only the players.

For me, unbalanced games either lack skill, or have rules that favor a player. To help explain these two unbalanced game mechanics, I will explain why I really dislike two particular games, and ways I suggest the game might be improved. Discussing both games, the blog got a little long, so I have divided the blog into two parts.

Games, like Chess, eventually reach a stage in the game where one player can have a greater advantage over the other. Even when one player has fewer pieces, players can still rely on skill over luck allowing a fighting chance.

Clue

I appreciate the concept of Clue, where players use logic to solve the mystery. It’s clever. It is why I enjoy games like Hits and Blows or Worlde.

Much of my dislike of Clue can be traced back to a design fraught with human error. The game has three types of cards: suspects, weapons, and rooms. Pick one of each and place them in the envelope. Sounds simple enough. Except, when the game set is missing cards. Or, the wrong kinds of cards are placed in the envelope. One game I played had two weapons, a room, and no suspects! Sometimes, it is a lack of understanding the rules of who sees what cards when. Let’s say the set up is accurate and they understand the rules, but a player doesn’t take very good notes, and incorrectly guesses. There is no room for bad guesses in the game. As I said…Human errors. That’s not the game being unbalanced. Again, that’s the players.

I find this game unbalanced because of the dice roll and how far apart the rooms are. Some players roll well, and begin collecting clues quicker than others all based on high or low dice rolls. There’s no skill in limping or sprinting to the rooms to look for clues. The dice roll should not be s limiting factor in a game of deduction. Once a player enters certain rooms, they can use a shortcut to jump to another room. The game is unbalanced in that it now favors the player who was lucky enough to roll high enough numbers. Luck is not a skill.

On a side note, one of my gripes is the game comes with little murder weapon figurines in which players have no idea what to do with. That’s not necessarily an unbalancing, but it is confusing.

How would I balance out Clue?

First, I would solve the movement issue by redesigning the layout of the murder mansion. The new layout would consist of a main hall surrounded by the rooms in a U-shape. Pairs of neighboring rooms connect both to the main hall and adjacent rooms. As for movement, each turn a player may either move twice (into different rooms) or move once and look for clues (more on this in a moment). Players start in the main hall.

The clues are the next thing I would fix. Give each type of card a different color and pattern of backing so they are easily identifiable (even for color blind players). For  the set up, with each type of card, deal one to each room, starting with the main hall. Then, if the game must have figurines, use a figurine of the victim. Maybe a chalk outline? This is placed ontop of the cards in the main hall, eliminating the need for the envelope. The cards are still clues players collect to try to deduce what happened. With the different colors, it is easier to see if an error has been made (Two weapons and a room? Really?).

Players look for clues by moving into the other rooms and picking one of the three cards, playing it face down in front of them. A player may only keep one face down card of each type. Whenever two or more players share a room, they may “look for clues” by asking to see one of other player’s cards. When players meet up in the main hall, the player looking for clues exposes another player’s card to the entire table by turning it face up. This adds a bit of strategy of trying to avoid other players, especially in the main hall, but can help others (even players who are behind) with learning the clues.

One final fix…The guess! First, no one may make a guess until all the clues are found, which means all cards are taken out of the surrounding rooms. With fewer players, this may mean there are more cards exposed to the entire group. Once all the cards are claimed from the rooms, the game boils down to catching up with the other players withholding evidence. To make a guess, the player enters the main hall and pronounces their guess to the group. For any wrong elements of the guess, these wrong elements are placed face up for all to see. The player who guessed poorly loses their next turn and must stay in the main hall. This makes them vulnerable to having their concealed clues exposed. Any other player moving into the main hall may force them to expose one of the clues. Maybe the poor guess forces another player to expose a clue, but with a penalty. More strategy! In the unlikely event the guesser is wrong but not proven wrong by another player, the game ends in a forfeit.

That is how I would recalibrate Clue to be better balanced. Next time, I will discuss the unbalanced game of Rummy.

The post Unbalanced Games – Part One – Clue appeared first on PegamooseG's Blog.

With most stories, I start with a basic idea. Sometimes, the idea is taken from a dream. Other times, it is a vague thought about a concept. I start thinking all sorts of what-ifs. Eventually, this thought process turns into a scenario centered around the idea. The concept stretches both backwards and forwards, to a time before the characters encounter the scenario, and to a time of the aftermath of that scenario.

When it comes to feature design, in this case designing a game engine, for me there is more stumbling around. For Peggy, the concept for this game engine started by envisioning how various game pieces should function. How should the pieces “behave”? How do I track the state of the pieces being manipulated? Where do the pieces start, and how do I clean up the pieces when the game concludes? All these concepts have been thoroughly explored and documented. Unfortunately, like with stories, I have not always stretched out this idea to both the before initiating a game session, nor much thought on what happens after. This is where I have stumbled and procrastinated on Peggy the most.

Once I stepped away from the concept of the game engine and focused more on the characters of this “story” (the players), I started better visualizing what else needed to be done for those before and after bookends. I know this will be incorporated into a webpage. This is like establishing the setting for the main character. Provide a basic layout for the site. The players appear on stage. Now what do they do? They need to create an account in order to access the games. Good. Then what? Assuming they want to play a multiplayer game, and not a game of solitaire, they need to invite other players to play. Okay. Are these supporting players their friends? Strangers? Do these other players have an account? Do they need one? These are all considerations needing to be fleshed out well before the first game session starts.

At this point, let’s assume the game construction and engine is all ready and in place. Players are able to start a game with other players, whether friends or strangers, whether they have accounts or not. Assume all the before is settled. The players are able to play games using the game engine. What happens when players encounter issues with Peggy? What happens after they conclude the game? Can they publicly proclaim a winner? Is that necessary? What do I want to happen next?

I have given the after a bit of thought, too. If players invite others to play who do not have accounts, I hope their friends are enticed to create their own accounts to kick off their own game sessions after their first game invite. Also, I want players to be able to use a similar set of tools I use to tinker with the available pieces to create their own games. And then, I want players to invite their friends to play the new or modified games, too. Maybe players can invent and share their own games, ones not based on my own creations. How should this be handled?

This is where I stumble the most. When it comes to the practicality of this kind of system, am I am I breaking down the design to granular enough levels? Am I envisioning the entire player experience including the before, during, and after moments? This level of design requires something more like world building. When I design my own tools for creating my own games, are they designed at a “good enough for me” level, and not considering what happens when I invite strangers to use some form of these tools. My designs needs to keep in mind what is restricted and what is sharable. How can these tools be shared while maintaining the stability and security of the system? Also, with the overlap of how different pieces have shared behaviors, what functionality can be reused or shared within the system’s own features?

Without enough granularity, there can be unexpected backtracking to pause the creative process, revert to an earlier stage, and incorporate additional details overlooked the first time. Sometimes, these additional details can be tacked on later. Other times, it is better to fix it from the beginning before needing to be shoehorned in later. Then, all these little details need to be captured into design documents and defined in work tickets, so the concepts and the decisions behind these plans are all captured so that they will be understandable when reaching that part of the construction. This is all part of the design process many people do not realize until they find themselves in the think of it. Most people will only see the end product. Few will get a glimpse of the dawn of the idea, and then maybe see the result much later on.

For me, the creative design process is both the most exciting and most frustrating thing, especially when I realize all the additional work needing to be done before getting to the fun stuff. It’s like picturing yourself paragliding near a tropical island, then realizing everything else that needs to be done to reach that part. You need to book a flight or cruise, and get your passport updated, and figure out where you are going to stay, and how you may need to get over your fear of heights, and all the other things. The realization of all the little extra bits is enough to burst that bubble around that initial, wonderful thought. Once you go through all the steps and break it down into more manageable pieces, once you actualize that idea, it can be the most wonderful feeling. Looking back, there is a sense of pride in all that was accomplished to get there. Then, the next time you get another fantastic idea, you have all that experience to help you reach that goal more efficiently. You become better equipped to provide a better design in the future.

How do you approach bringing life to an idea?

The post Approaching Design appeared first on PegamooseG's Blog.