It is crazy to think Pegamoose Games started almost twenty years ago. James Ernest of Cheapass Games suggested, “If you have an idea for a game, don’t send it to me. Create it yourself!” So, I did. I created Snipe Hunt. This blog is not about the dawn of Pegamoose Games, nor entirely about Snipe Hunt. Today, I blog about how projects evolve throughout the process.

The first prototype of Snipe Hunt used the backs of old business cards. A Monopoly board helped space the cards, and kept track of piece movement. After some feedback, the game evolved into arrows directing piece movement. Next, came the hedge-maze style of what it currently resembles. Eventually, Snipe Hunt will evolve again into a digital, web-based version, instead of a printed version.

The design process directed the creativity process in the direction of a web-based design. To print, provide pawns, and package Snipe Hunt took money. The original, limited-edition version cost over $1000 to create. Over the past couple of decades, I have sold enough copies to make back the amount spent. Because of the cost, I hesitate to create another print version of other game ideas. That’s why I invented Peggy, my browser-based game engine.

Peggy, the Game Engine

I wanted a way to be able to create more games, but did not want to incur more costs and take up more storage space in my home to do so. That was the main drive for seeking a digital solution. I have the webpage, I just needed the means for providing games. One of the first possible solutions I had found was using someone else’s game engine. The problem was, they took a long time to release new games because all the little, nitpick rules had to be encoded. To me, that wouldn’t fly. When I designed an early version of Peggy, I wanted to only program the pieces, and rely on the players to enforce all those nitpick rules. Or, not. Players can cheat if that’s how they want to play.

Peggy was a way for me to define a set of game pieces in a template. Each game piece type has its own set of “physics”, defining how the piece can be presented and manipulated on the page. I would provide a set of rules for how players should play the game, but what they do with the pieces is up to them, only with the limitation of laws of game piece physics.

This was great for a while, but game creation was still a bit tedious. In the original version, I provided an XML file that listed all the pieces of a game. The list would need to be compiled into the system. The system would use a snapshot of the list of pieces to play a game session. What if players wanted to play a game using two or more decks of cards? The XML would need to be updated and recompiled. And so, Peggy evolved.

Round Two

Instead of XML, I migrated the game and pieces to the database. Each individual game piece is defined in a piece warehouse. Game templates reference pieces from the warehouse. Finally, players initiate a game session from the template. Without compilations, players could easily adjust the game by referencing pieces as necessary. Great! Another hurdle solved!

One thing about the first version of Peggy, I did not like the presentation of different collections of pieces. Look at card games (ex. Bridge, Spades, Rummy). Each player has their own hand of cards. These cards are played to the table. In some games, the cards played are collected into tricks. How do you display all these collections of pieces? Some pieces you do not want to reveal to other players. You do not want to show your hand to your opponents. In the original version, each of these sets were displayable in their own views, but players could only see one view at a time. Peggy needed to change.

I redesigned the webpage to have a split view. The table, a community view where most of the game is played, occupies the larger view. The other, smaller view would be for the more personal sets of pieces (hands of cards, collections of tricks, etc.). That sounds good. Well, what if a game does not need that smaller view? Where does the menu go for telling how to manipulate different pieces? How do I update the page with two views and a highly dynamic set of menu options? I liked the split view, but I had some big problems stumping me. So, Peggy went dormant for many years. In that time, I focused more on my writing and day job(s). And then, I enrolled in a developer bootcamp.

The Next Generation

I learned all sorts of new web development concepts. The bootcamp opened up more possibilities. My current hosting package operates both my gaming and writing websites at a much cheaper rate than a hosting package allowing the concepts learned from bootcamp. To use NodeJS or ReactJS will take more planning and considerably more money, one of the original reasons I invented Peggy. However, I had discovered a few cheaper solutions.

For one, I learned of the existence of Bootstrap, a web service assisting with professional-looking UI. In the first version of Peggy, I discovered code to make draggable images. That helped with the physics issues for cards and pawns. In the bootcamp, one instructor used a style sheet trick providing the effect of a card flipping over. Bingo! Another physics element to make the flipping of cards look more appealing. Bootstrap gave me an idea for how to handle a good portion of other UI issues.

When visiting a webpage, it typically uses a navigation bar at the top with all the functionality. Could a universal nav-bar provide actions on the game pieces? Perhaps another style sheet opportunity could make functionality easier. I decided to still provide a general nav-bar. However, since each piece requires its own actions, why not give each game piece its own dropdown menu?

Even though the dropdown menus will have different actions applied to the selected game piece, only a few types of pieces and the actions are needed. These drop menus will also be templatized and associated with the individual piece type. Another problem, potentially, solved.

What Now?

I feel guilty about sitting on Project Peggy for so long, but I shouldn’t. Time and flexibility is all part of the creation process. Sometimes, it takes time to think about how to make something better. When I cannot think of better solutions, that is when the motivation for a project fizzles out. However, when I discover new possibilities, it is like revealing the survival of the fittest solution. It inspires me and rejuvenates me to work on the project all over again!

Unfortunately, as a creative person with too many ideas in his head, the waiting game is also a curse. When I set one project aside, other projects muscle their way in to fill the gap. In my case, game design is in constant competition with fiction writing and using my new web development education to find a new day job career path. I find myself pulled in many directions, or find my projects slowly simmering on the growing range of back burners.

Where to go from here? We’ll see!