As mentioned in my first post, I love board and card games. I own a lot of them and play regularly. I even chose a game as my capstone project. As part of this project, users can create their own game decks and test them out against a computer opponent. Building a fun deck is challenging and I thought I would share a few tips.

Although game enjoyment is highly subjective, the top games on https://www.boardgamegeek.com share recognizable traits. The traits are essential in making a game both fun and repayable. I thought I should share examples of games (with all images coming from boardgamegeek.com) that embody these traits and how those rules might apply to a collectible card game.

Balance

Balancing games is arguable the most difficult part of the game creation process and is far more complicated than new designers think. A truly balanced game is not one where every player has an equal chance of winning. Instead, a balanced game is one where the game maintains a sense of tension during the entire session. A poorly designed game may start off fun but then turn into a slog halfway through. For example, Munckin is not a balanced game. In every game of Munckin I’ve played, there is one player who ends up leading the pack. At about the 3/4 mark, everyone knows who will win the game. But you still keep playing. unfortunately, for the losing players, the rest of the game can be quite boring, and many players easily get distracted by other forms of entertainment. The game goes on past its balance.

Power grid is a game with good balance during the game’s entire duration. Each player has similar opportunities at the start of the game. As the game progresses, players in the lead must spend more money on resources than trailing players. As a result, trailing players can often catch up to the leader and have a chance of winning. The game is won through good strategy. You often do not want to be the leader, but you also don’t want to be too far behind. This leads to an interesting game where players jockey for position right up to the last round.

For a collectible card games, balance is achieved by appropriately costing cards so that a single card cannot win every game. Good collectible card games give players counters to powerful combos, preventing a single strategy from winning every time. This translates to keeping card values, like cost, attack, and defense, in harmony with each other.

Randomness

Randomness, by itself, does not equate to a bad game. A lot of games rely on randomness to help with balance and to keep the game fresh. The outcome of a game with too much randomness is essentially determined by a die role. A game with too little randomness is a puzzle. Puzzles are fun but are not generally thought of as a game.

An example of too much randomness is Candy Land. In Candy Land, a random card determines how far you move. You do not control the deck or which card you drew. The game is determined by who can draw the best cards the most times in a row. This result is predetermined when you shuffle the deck. Even my three year old daughter finds Candy Land boring.

Castles of Burgundy is an example of good randomness. In Castles of Burgundy, players roll a lot of dice. Players then spend the die values to take a variety of actions. The die values determine which actions are available. None of the actions are, by default, worse than the other actions. The combination of actions over time determines the winner. The randomness of the dice makes the game replayable without hampering strategy. Players can even take actions to remediate a series of ‘bad’ rolls.

Collectible card games have randomness in which cards are drawn. Therefore, aligning the attributes across cards can help reduce the randomness. If the cards are relatively equal in power, then the initial draw is less important. Similarly, if there are cards built to counter a bad starting hand, like a card letting you search your deck, then a bad opening will not determine the game’s winner. When building a card game, make sure the decks are balanced in card power, and give players enough good cards that a player won’t quit on a bad first hand.

The ‘Fun’ Factor

The final pillar of a good game is that the game is fun! Some games are just a pleasure to play, while others are so mechanical that even good rules and balance don’t save them. Playing boring games feel like you are moving pieces for no reason or that you are playing a solo game with others watching. The worst ones have long turns where the non-active players get bored and wander off.

An example of a game missing the fun factor, for me, is Monopoly. Players take a long time to decide whether to buy a property and haggle over trades. Players also take a long time to take turns as their attention is usually elsewhere during the game. When you aren’t rolling the dice and moving your piece, your presence at the Monopoly table is mostly optional. For me, Monopoly is just not fun. It’s a chore.

On the opposite end of the spectrum, Gloomhaven is the number one rated game on BoardGameGeek and is rated number one for a good reason. Players play simultaneously, and each player’s choices impact the outcome of the game. To win, players must interact with each other and devise strategies that harness their collective abilities. Many classes rely on another players magic generation to cast powerful spells. Turns are fast with each player knowing exactly how to execute the cards they play.

For a card game, the best advice I can give is to develop interesting cards. Mix up the effects, while keeping balance in mind, so all the cards feel different. Add interesting card interactions to drive additional unique combinations. Using clever card names and well-written descriptions help convey the atmosphere and immerse players in the game.

Conclusion

Good board game design is a lot of work. You need to balance solid gameplay with the entertainment factor. There is a very think line between too random and boring. The best advice I’ve seen is to playtest the game over and over again, making changes based on feedback. I hope you have fun using our project to make a great card game!

I’ve work in product management for a decade now. Over that course of time, I’ve watched the company change software development philosophies several times. Not all of these changes resulted in positive improvements, but the impact of these changes on the software development lifecycle and engineering culture is fascinating. For this blog, I discuss the four different approaches taken during my time with the company and the results of those approaches. Note that not everything in here is typical of these processes. In many cases, we implemented the approach in an ineffective way, which lead to some process failure. These are my experiences, and your mileage may vary.

Stage 1: Kanban

When I first joined the product team, many moons ago, the young company had only a single team of engineers. Back then, software development used Kanban, including a Kanban board that listed the various tasks needed. Under this form of Kanban, sprints do not exist. Instead engineers accept new tasks immediately after finishing a prior task. Product managers were required to constantly groom new tasks to keep up with the engineers.

One of Kanban’s focuses is on constant deployment. This frequent deployment and change in tasks made software evolve at lightning speed. Customer requested features were often implemented within days or weeks of getting the requests. Everyone delighted in the constant smorgasbord of new features. Of course, no one was very happy when a new feature broke something. However, we could repair any outage within hours or rollback with minimal effect. The product was fun to work on, even if keeping up with the constant change was taxing. UX and marketing experienced the most hardships. The fast timelines left UX little room for testing designs and the impact of new features. Marketing also struggled to keep up with engineering and complained that the constant deployment meant they lacked a big press announcement about new features. Note that Kanban can accommodate bigger changes with proper notice to marketing and UX of what projects are coming up. However, in this case, planning that far in advance never happened.

Kanban was super fun and, for me, the upsides of speed and agility outweighed the negative aspects. The teams were forced into a tight-knit group in order to meet the need for speed and constant change. This made going to work very pleasant and rewarding.

Stage 2: Classic Scrum

As the company grew, Kanban became increasingly difficult to manage. With additional engineers and new teams, conflicts arose both in work and in code. In turn, the conflicts increased the number of outages and rollbacks. I believe Kanban can work with large teams and comprehensive unit tests, but the discipline required from engineering proved too much. We switched to classic scrum.

Using classic scrum, the teams switched to two-week sprints, daily standups, and a dedicated scrum master who held the members of the team accountable for their performance. Each product manager was assigned as specific area of the project, allowing the engineers on that team to focus their skills .In addition, we added true cross-functional stakeholder meetings and sprint demos. These meetings were a relief to both UX and marketing as the heads-up gave those teams room to plan.

The primary downside of scrum was the noticeable loss of speed compared to Kanban. With sprint planning and team coordination, fixes that used to take a day could take up to three weeks. One week of planning plus two weeks of waiting for the change to reach the top of the priority list. The other perceived downside was the leadership team felt a lack of control over the planning process. Roadmaps in scrum are ordered lists of priorities. This mean that the executive team was never sure when a project would complete. Combined with the lack of immediate changes, the use of scrum led to frustrated business leaders.

Of the various approaches, I thought classic scrum worked the best. Although we operated slightly slower, the total amount of product produced over all teams was significantly higher. I also liked having slightly more time to plan and the focus of product on future changes rather than the immediate tasks.

Stage 3: Large Scale Scrum (LeSS)

The engineering teams expanded with additional company growth. Eventually, we reached a critical mass where, once again, the engineering teams were stepping on each other. With six teams working on one project, each with their own product manager, conflicts became common. The PM releasing first usually ended up owning that particular part of the product.

To fix the conflicts, the company pivoted to large scale scrum (LeSS). LeSS is similar to traditional scrum but is designed to deal with multiple engineering teams working on the same system. LeSS features a main product manager that coordinates between the product owners, each of which has responsibility for certain areas of the product. The product manager decides which stories are a priority based on the the customer impact and completeness of the specification.

The main issue with LeSS is political. With one person deciding priorities, the different product owners felt more like advocates for particular agendas than dedicated to a single team. The lack of embedment with engineering corroded the relationship between product and engineering, leading to less trust in the product plans. On top of that, the UX team could never be sure which product owner had the most important task. Sometimes UX would end up working on a part of the product that never received prioritization. With LeSS, if the product manager is constantly diligent, the whole process breaks down. LeSS also didn’t solve the management oversight problem.

I liked LeSS slightly less than Kanban. LeSS ended up feeling too political. The product manager simply didn’t have the time to review all of the proposals and sort out the presentations effectively. I think LeSS would have been more successful if the engineering teams aligned more closely with the product owners rather than the product manager at the top.

Stage 4: Waterfall

The final, and current, evolution of software development approaches was a retreat to waterfall. Despite the CTO trying to pivot towards a more agile framework, the CEO and current SVP of product really like the theoretical oversight waterfall provides. The waterfall approach features a beautiful project plan. Managers and sales can share this project plan, pointing to what the future holds. When the project plan came out, everyone was excited about the end-state product. Customers especially appreciated the long notice of what we planned to release and the end-state specifications.

Unfortunately, we ended up experiencing every classic waterfall pitfall. The project has significantly deviated rom the project plan. All parts of the project are late. That big fancy document that the SVP touts around? No one reads it. Everyone still likes the end-state, but the actual plan is more of a marketing and sales tool rather than a product specification.  This causes friction between the business and engineering.

Although the waterfall process appears super organized on paper, the reality is chaos. Despite being happy about the documentation, the management team is more frustrated than ever because of the missed timelines. I personally have found the decline to waterfall fascinating. It’s a textbook case about the pitfalls listed in every article on agile.

Summary

My recommendation, based on experience, is to stick with agile. There are lots of agile methods available, and every single one worked better than waterfall. I loved Kanban, but I definitely experienced issues in scaling Kanban to large organizations. If I could change one thing, I’d go back to classic scrum.

Card Creation

One of the most interesting parts of this capstone project is allowing users to create cards that are then saved to a database and used to build custom playing decks. Naturally, I volunteered for this assignment. Most of the card creation system implementation is straight forward. I set up text information for card statistics and flavor text information. I added images that change based on a card’s characteristics. This information is saved via an HTTP request to the server (which part is still under construction).

However, there was one very difficult requirement to get working. The project specification allowed a user to upload an image and then use that image in the card design. Initially, I thought this would be something readily built into Unity. I was wrong. Very wrong.

There is a lot of complexity surrounding this one little command:

Uploading Images

Uploading local images in Unity during a game’s run time is surprisingly complex considering this is a common Window’s task. The complexity must be why so many games allow users to pick skins from a predefined list. Accessing predefined information in Unity is pretty straight forward. Simply access the “Resources” folder and load the asset into the project, assigning the loaded asset to the desired UI element. You cannot use the “Resources” folder approach if the information needed is not known before compiling the program.

Unity has logical reasons for making loading local assets a difficult task. First, Unity is designed to support multiple platforms. The different platforms do not share a uniform System.IO object, meaning that the windows-type file I/O is not a universal solution (c# – Attempting to upload .png file to web directory – Stack Overflow). Second, there are concerns about copyright and needing to monitor what images are uploaded. I can see why this a concern for commercial developers. The concern is almost zero for a class project.

Non-Solutions

I was surprised that the Unity community forums contained only a few good ideas on how to solve this issue. Most of the answers I found are examples of how to work with files when you already know the file location. If you know the location, you can use the UnityWebRequest object to load the file and use it in the project. Despite the name, the UnityWebRequest object can read local files across platforms.

Other suggestions used the deprecated www object in combination with the Unity EditorUtility. For example: Unity – Manual: Uploading raw data to an HTTP server (PUT) (unity3d.com). These solutions used Unity’s EditorUtility to open a file and read the information using www tools. This works great…in theory. Unfortunately, EditorUtility only works in editing mode and will not work with deployed code, making the solution impractical for the final product. The real answer is: “There is no built in file browser for the player, so you would need to roll your own using the .NET frameworks classes for file system access” How do I let the user select a local file for my application to use? – Unity Answers

The Real Answer

Frustrating, right? At this point, I became very worried about the project’s scope. Writing a new .NET application seemed like a capstone project by itself. I didn’t think the team could create both a new application and develop a game. Frustrated, I was about to move on to a different part of the project. Luckily, I remembered the unity asset store. Eureka!

Searching the store finds a few different option. The free one I used is:

https://assetstore.unity.com/packages/tools/gui/runtime-file-browser-113006

This plugin allows you to load multiple files, save files, and specify search criteria. Likely overkill for what I need, but the price sold me.

Getting It Working

When I first imported the plugin, I could not get the tool to work. This was my mistake, and I failed to import the C# script into the project library after importing the package from the asset store. This failure caused Unity to replicate a similar script in the resources location and crash when run, stating that two assets were detected with the same name. To get the plugin working correctly, I needed to import the plugin into my C# code before testing. I also had to delete the created file. After fixing my installation issues, the plugin worked great and included very comprehensive user documentation. You can see it working below.

Yay! The code to make this work is a small modification on the example implementation.

	private void GetPath()
	{
		FileBrowser.SetFilters(false, new FileBrowser.Filter("Images", ".jpg", ".png"));
		FileBrowser.SetDefaultFilter(".jpg");
		FileBrowser.SetExcludedExtensions(".lnk", ".tmp", ".zip", ".rar", ".exe");
		FileBrowser.AddQuickLink("Users", "C:\\Users", null);


		FileBrowser.ShowLoadDialog( ( paths ) => { path = paths[0]; },
								   () => { Debug.Log( "Canceled" ); },
								   FileBrowser.PickMode.Folders, false, null, null, "Select Folder", "Select" );

		// Coroutine example
		StartCoroutine(ShowLoadDialogCoroutine());
	}

Conclusion

In retrospect, the first place I should have looked for an answer to my problem is the asset store. Being new to unity, the idea didn’t occur to me. I thought of the asset store as a place to buy sprites and images, not useful tools. Turns out the asset store is a real boon to the community and filled with useful items. The biggest takeaway from this headache is that when you get stuck, look at the asset store. There’s a good chance someone already solved your problem.

In this blog, I wanted to share one of my favorite pieces of software, LucidCharts. I use LucidCarts quite a bit for work, and I find that it’s one of the best ways to coordinate across large teams. LucidCharts helps me organize my projects and trains of thought.

Apologies to Elizabeth Barrett Browning on this parody of her sonnet. To break up the poem, I included images of a few projects I’ve done in LucidCarts over the course of my tenure at OSU.  

The Poem

LucidCharts, how do I love thee? Let me count the ways.

I love thee because of thy ERDs and UML diagrams, which are so easy to create.

My soul can reach (to LucidCharts), when feeling like I need to start mapping out a project.

For the end of hand-drawn images and the ideal packages that contain all the icons I need.

Most quiet need, whether I’m working on OSU homework by sun or candle-light (mostly candle-light).

I love thee freely, as I strive to get my project plan just right.

I love thee purely, as you turn diagrams into creative layouts.

I love thee with the passion because it’s so easy to use,

Compared to my old griefs with my childhood’s faith in spreadsheets.

I love thee with a love I seemed to lose using Microsoft Visio.

Especially with my lost files because of failures to save, I love thee with your cloud-based saving,

And the lack of tears when doing all my homework; and if my instructor choose,

I shall but love thee better after this class ends.

The End

I really like LucidCarts.

You can find the real poem by Elizabeth Barrett Browning here: How Do I Love Thee, Let Me Count The Ways: Sonnet Analysis (nosweatshakespeare.com)

For me, the hardest part of any project is getting started. New projects always feel like you’re lost in a big world with every direction leading to new options. The best way to get somewhere interesting is just start moving.

One of the most interesting elements of this class is the lack of a set directions on how our team accomplishes our goal. Previous classes set forth the required language, the desired outcome, and the specifics on how you implemented that outcome. With CS492, everything changes. Suddenly, you have a wide selection of tools and a project where “complete” is left to the imagination. This is both exciting and terrifying!

Just Start Already!

The best way I have found to overcome the anxiety that always seems to accompany new experiences is to just start moving. Type out notes. Sketch a framework. Do something or anything to just start moving! Starting early often means moving in the wrong direction. However, the act of starting starts the gears in motion, allowing me break through the nervousness and focus on the problem.

For my capstone project, I applied this practice by writing out what I wanted to accomplish, consolidating the project outline provided online with what I thought sounded interesting. started by writing out what I hoped to accomplish. I also watched several videos on how to code in unity and set up the repository in Github. These small acts made me feel more confident in the undertaking, got things organized, and was fun to do.

The Second Step

Despite my initial nerves calmed by the act of starting, I still found the project very overwhelming. The project just seems so big! To further “just get started”, I diagrammed a possible flow/architecture for the project. This is the diagram I came up with:

Sketching out diagrams like this help give you direction and help solidify what you want to accomplish.

Rough diagrams like this help me visualize the various steps along the way, breaking the project into more manageable chunks. They also give me direction. Even though the team hasn’t scoped the size or efforts of these chunks, diagrams can help split up an huge undertaking into smaller, and doable, steps.

Added Benefits

One added benefit of starting on a project is the process of starting might find holes in your thought planning process. For example, putting together the flow diagram made me realize that the team never discussed a very important part of the project in planning – how do you actually play the game! The project’s main goal is to allow users to create customizable card games, but we need a simple set of modifiable rules that a computer can follow when becoming an opponent. We are working on creating these now, but thank goodness for staring into the project! 

Conclusion

For me, jumping straight into the work is the best way to start a project , feet first. Even if the project initially feels overwhelming, the act of starting helps calm my nerves, organizes the process, and allows me to better see the project’s bigger picture. Just doing something towards the end-goal makes big tasks seem smaller.

Welcome to the Capstone Gaming blog! I’m glad you stopped by! In this first post, I’m excited to introduce my new blog and what I’m hoping to accomplish during CS467. Although this blog will usually focus on my team’s capstone project, for the first post I wanted to share why I am passionate about this project and document a few thoughts on what I hope the project end-state looks like.  

My Obsession

When perusing the list of available projects, one particular request immediately caught my eye as a unique opportunity. To ensure I captured the projected, I needed two like-minded individuals. Luckily, using the class discussion list, I found two individuals who shared my immediate enthusiasm for this project. We quickly formed a team and signed up for the trading card project, a project where we will create a tool to generate trading cards. Sharing two pictures should fully explain why I am excited about this project:

I own a lot of games. A LOT of games. What’s not shown is that this collection extends onto another shelf. I love games. 

Existing Tools

I love games so much that I spent my summer designing and creating a new game. My game is a card-centric endeavor that I’m hoping hits kickstart next year. Because I needed an extensive set of cards, I spent a significant amount of time looking at the current market for card-generation software. Turns out, the market is really small, consisting of only a single dedicated solution called nanDeck (nanDECK | Code your graphics). Other card designers recommended using Illustrator or Adobe. However, I believe nanDeck is the only software designed solely for making playing cards.

Nandeck is a pretty good open-source tool with a comprehensive. You can add images, replace strings with icons, set the number of cards generated, and import CSV data. Best of all, Nandeck is free to use.

Although the generally robust, the software’s bugs can result in critical failures when trying to print cards. The worst bug, a pointer error, renders the software unusable when encountered. The software also looks dated and needs a serious UX upgrade.

Defining Success

I’m looking forward to seeing the client requirements, but I hope that a successful project will include connecting to a datasource, allowing customization of layouts and display of text and images. The program will need an option to print the cards and save them to a file for future editing. Hopefully, the feature set will be rich enough that I can test the software using my own game. 

If you can’t tell, I’m excited to get started and work on this project with a great team. The team will have a lot of fun working together and creating software that will have a big impact on this niche market. We will at least have fun discovering how to actually build this software. I can’t wait to share with you what I learn and the progress our team makes.  

See you next blog post!