The types of input that the user will be providing through the webpage interface can be broken down into two categories: preferences and constraints. Preferences match the user’s desired characterics of a game, whereas constraints match rigid conditions of the game.

Preferences include things like:

• Mechanics
• Systems
• Themes
• Turn system
• Skill vs. luck base
• Cooperative vs. competative

Constraints include things like:

• Number of players
• Time to play

In fact, that constraints list may be comprehensive.

Constraints are easy; there’s no such thing as a mostly matched constraint. All they need is a straightforward filter. Simply remove games that don’t match these constraints from consideration. There’s potential for efficiency increase if filtering is done properly before the recommendation engine parses the preferences. Preferences, on the other hand, are accurate to some degree, rather than being a boolean match. We may display a game that matches most of the mechanics, or is close enough to the user’s skill vs. luck base, even though it wasn’t exactly what they were searching for.

The other significant aspect of preferences is that they can (and should) incorporate some weighting system on the inputs. A user may not care what the themes of the game are, and they may only partially care what the turn system is like. A true expert could take such things into consideration, and, therefore, so should our expert system.

Note: This post deals with content discussed in the first interview with Raymond Chandler.

Ray offered insight into the design behind board games with his expertise. This isn’t the same type of expertise we intend to model with the board game recommendation engine (we’re not building an engine that creates board games, just one that recommends them for play), but in some respects, it’s still relevant to our problem domain. (It’s also important to note that Ray is an a zealous board game player, and so he is still a highly useful expert.)

The interview writeup goes into greater detail on his explanations of board game design, but he gave some good possible game attributes and other input that we hadn’t considered, such as the “ramp” and “tempo” of a game, and the average player skill of those in the group. We discussed the possibility of a ”similar games engine” to add variety to search results with Ray. Ray didn’t like the idea of directly linking games, as it was demanding on experts and poorly scalable. He recommended as an alternative that we link attributes across games so that newly added games would be immediately integrated in the system.

While what he recommended made sense, the notion of linking arbitrary attributes is rather complex. An example of his proposal is to link dice-rolling to card-playing systems as similar. When a new card-playing game is added, no new links will need to be established; the engine will know that the games are similar because of this link. If all we’re to do is link gameplay mechanics, then that is a reasonable approach. However, it may be more effective to link arbitrary game attributes in some manner, such as linking dice rolling mechanics to luck-based gameplay (in the luck vs. skill attribute). The problem is that linking attributes is such a manner is rather complex, especially when the only reason we began down this road was to add variety to recommendations; a nice feature, but an unnecessary one.

I think this thought shouldn’t be accepted or rejected so quickly. It will require discussion with the team at the next meeting, and potentially further exploring this option in the next interview with Ray.

Note: This post was heavily inspired from the system design that Ryan, Alex, and I talked about earlier.

Our team has always understood that we would need some contained system that gives game recommendations based on preferences (i.e. the recommendation system core), but this is only half the work. There’s more to do in storing the data, and providing webpage interfaces for sending queries to the core and displaying results. While this bare-bones system should be sufficient to meet our initial requirements, there’s still more to add to the system, as we discovered at our meeting. In particular, there’s a this system doesn’t provide a feature that an expert could provide to a user: variety. Many avid players are interested in trying something new, even if it is further away from their preferences. We want to provide an option to the user to request variety in the search.

Unfortunately, variety is a loosely defined preference in a board game query. The user can select that they want a strategy game or a 4 person game, and we know exactly what they mean. If the user selects that they want variety, then suddenly we have a huge problem. This isn’t some attribute of a game that we just match. It’s the desire to get games that don’t match their selected attributes, but still will be likely fun by their standards.

The simple solution would be to just not provide this feature. But where’s the fun and variety in that?

The other solution we talked through is to allow experts to map similar games. Rather than attempt to model variety ourselves, we can simply return games that are similar to the games the user will like, but that the user didn’t actually search for with his input. This would involve providing a new interface to experts on the website so that they can map games to each other.

I drew up some flowcharts on the proposed system. When the system is finalized, we’ll have some proper flowcharts:

The overall I/O of the system with the two proposed engines.

The flow of a recommendation query from inception to display.

Essentially, instead of returning games matched by attributes immediately, some of these results are then passed into the similar games engine and then the mixture of results are returned to the user. The filtering in the second chart exists to remove attributes that aren’t directly relevent to user preferences for recommendations; that is, they are closer to constraints than preferences (e.g. number of players, time to play).

Surprise! None of us on the team have developed a recommendation engine before! This whole experience is entirely new to us. We’re not following any guidebook or teacher directions on how to throw this system together. What this means for us as developers, is that we have to work hard, early on, to ensure that the design of our engine is sensical and efficient. The system components and their interactions must be airtight, or else we risk wasting energy on code that won’t make the final cut. It’s essential that the engine solves a problem that we can identify, and that the system is built from start to finish to solve this problem.

What is the purpose of a board game recommendation engine? It’s easy to think, to recommend board games, and skip over this train of thought. For any board game enthusiast with a sizeable collection, choosing a game to play is a challenge. Even with a type of game in mind, with known time constraints and number of players, the person will still often be unsure of what his set of options are. Add into this mix the preferences of several other potential players, and suddenly the group’s eagerness to jump into a game is pacified by the difficulty of the decision of what to play. It is this very scenario to which we hope to provide a solution. So what is the purpose of a board game recommendation engine? In our case, it is to take whatever factors a board game enthusiast considers when selecting a game to play, quantify them, and allow the user to send them as input into our recommendation engine. The output will be a list of board games that match the preferences and constraints that the user provided as input, in order of expected relevance to the query.

That begets the question of what preferences and constraints the user may input into the system in order to receive recommendations. That question alone is hugely significant and difficult, so it will be discussed in a future post.

Our group gave a presentation today on Chapter 4: Reasoning Under Uncertainty from the textbook, Expert Systems: Principles and Programming, 4th Edition. The presentation slides are available here.

An additional problem that had the potential to provide an interesting challenge was that of evaluating the relative reading level of a sample of text.

1. The Problem

While many databases exist that rate the reading level on various scales, whether it is by grade level or on some other numeric scale, there is a lack of tools to dynamically evaluate the complexity of an arbitary piece of text that could be sourced from an article, website, book, or many others. An application could be developed that would allow a user to paste a sample of a text into an input field, and then return a numeric rating or educational level corresponding to that text. This way, educators would have a reliable method for determining whether a piece of writing was appropriate in terms of difficulty for that age level.

The system would need to take in several criteria as input, such as the level of difficulty of the vocabulary used and the complexity of the sentence structures found in the text. These values could then be input into a rule-based system to determine the final level of that text.

To expand the project, additional machine learning and AI concepts could be used. Natural Language Processing would be necessary to acurately handle and evaluate the sentence structure of the text among other issues. Categorization methods such as clustering could used to compare texts to others with known, established values, or a machine learning system such as a neural network could be trained against a large database of texts with known values.

2. Expert Sources

As a team we discussed, and even briefly described this project to a few of our family and friends who are experts in this area, including elementary and high school teachers, as well as those with degrees in English. Additional experts who would be necessary to the completion of the project would likely come from an Ohio State department such as Education or Linguistics.

3. Our Motivation

As a group, this project was initially appealing because it provided a flexible and daunting challenge. The problem has a somewhat subjectively defined solution, and yet, if it were to work successfully it could provide a very useful tool for educators. Additionally, it allows a very convenient segue into other AI areas of interest such as Natural Language Processing and text categorization.

4. Details

Upon researching the project further, it became apparent that a large portion of what would make this project challenging was finding accurate and reliable knowledge bases, beyond our experts, to help define the behavior of the system. It would be necessary to have access to large amounts of texts, possibly by scraping sites like Google Books in conjunction with an existing database such as that found at AR BookFinder. Additional challenges arise from the subjectivity of rating a concept like reading level; our experts would need to provide tangible feedback on the “correctness” of a nebulous concept.

During our meetings one of our favorite topics has been a board game recommendation system. The goal would be to have board game experts use their vast knowledge of which games are worth playing to point new and old players to games that fit their immediate requirements.

1. The Problem

The Columbus Area Boarding Society (CABS) has over 1000 board games. We aim to save them from the paralysis of choice such a large collection brings. At any given hour of a meeting, dozens of players will mill around in front of the library’s game cabinets and waste time not playing games.

Each group of people has various restrictions on what they will eventually pick. Major requirements are often the Number of Players and the Length of Gameplay. A group of 3 people is not interested in playing a game for 12. Likewise, a group with only an hour available is not interested in anything taking 4 hours.

Other requirements are more varied. Genre, categorization, game mechanics, publishing date, suggested age, or community awards. Veteran board gamers will take all these things into consideration in varying amounts when choosing a new game. This analysis is very much an art, not a science. We aim to automate their expertise build a system to take any or all of these factors into consideration for everyone, not just experienced players.

2. Expert Sources

Unfortunately, even experts can make mistakes. A single expert might not have all the knowledge necessary to make a good recommendation. We will use our local experts at CABS to test and refine the system. With their experience at our disposal, we can find the correct calibration settings for how much weight we should give to qualities described above. Pooling their collective expertise we will be able to cover a wide range of games and their appropriate pairings.

We also have BoardGameGeek.com (BGG), the single largest website covering the board gaming community. BGG has a free API we can access to download the extensive board game data. Using this, we can import thousands of games worth of data into our database, allowing us to focus our time on tweaking our recommendation system as tightly as possible.

3. Our Motivation

We are going to integrate with the CABS library system so that we can allow members to use our system on a day to day basis. This will provide real value to a local community organization and its members. We hope to be able to use the data collected from actual usage to further tweak the system into a mind-reading, board game recommending machine.

4. Details

Interfaces

These are two separate interfaces for the two ideas. The Expert Weighted Query System is of more immediate value to the users of the system. The system would be much useful very quickly and very extendable. The User Profile approach would be very similar to a Netflix style recommendation engine. The amount of work required for this is much greater with no guarantee of it providing valuable output. Team members have expressed interest in this approach and we will attempt it given time.

Expert Weighted Query System:

The users will primarily access the system through a web interface built by the team. This will prompt them to enter the primary information necessary for the recommendation engine to make a decision. To begin, these will be Number of Players and Game Length. We will add the ability to enter other information such as categories or game mechanics as the engine begins to handle them.

There will be a select box with an appropriate set of time ranges (<20m, 30m, 45m, 1h, 1.5h, 2h, 3h, 4+h). There will be a multi-select box for number of players (1,2,3,4,5,6, 7+). When we add features such as Game Mechanics, we will allow a multiple tag selection. This will likely be auto-completed through a query interface, but this has not been finalized. After submitting the form, the recommendation list is shown in a ranked order. Relevant information, pictures, and links to BGG are shown.

User Profile Driven Recommendations:

An stretch goal for the project will be to use user profiles to track and learn which games each user likes. The CABS system has the capability to track each user’s checkouts and BGG has user profiles with tracked plays and collections. The interface for this page would allow the user to enter the players involved in the proposed group and recommend games the players are all known to like.

Players will be able to type in the names of a player into a text field, with known players being auto-completed. Optionally, we can integrate with the bar code scanner device already employed by CABS, capable of scanning the membership badges. After a player is added, another text field will appear, ready to add another player. After submitting the form, the recommendation list for this particular group of players is shown.

New players will be able to be added to the system and linked with their BBG user account.

Data

The BoardGameGeek API will provide us with much of the initial data we will need. We will automate the process of gathering data and keeping it updated in our own database through regular resynchronization. We require a local copy of the data as the CABS meeting location does not have regular internet access. We will run a copy of the server locally on the machine setup to handle checkouts.

This is a sample API response from the BGG API. The basic game information (Name, BGG ID, Publisher, Designer, Date Published) and categorization data (Number of Players, Game Length, BGG Rank, Game Mechanics, Age Limits, etc) are included. In addition to detailed game information, we can gather data about User Collections, and Recorded User Plays. Such information may prove useful if we are able to attempt the User Profile system.

This this information available, we will be able to focus on leveraging our experts’ judgement for the recommendation engine instead of inputing data.

Recommendation Engine

The meat of the project will be to accurately recommend games based on the user desires. Unfortunately this is still the most undecided aspect of the project. We are not entirely sure of the best approach and these are primary ideas.

We will begin this in phases.

1. System Integration: Recommend Anything

The first step is to hook up a system that accesses the data retrieved from BGG and return a set of recommended games to the user regardless of accuracy. The games recommended is not important, but making the entire system work together as a coheisive whole is important. Parallel work on downloading BGG data and setting up an initial interface will be done during this step.

2. Number of Players and Game Length

Now that we have some amount of data from BGG, we can begin to restrict our recommendations to games which match the user’s restrictions of Players and Time. Any games matching the appropriate number of players will be considered. Next, we look for overlapping time ranges in the board game data and the user’s selection. This step is essential in providing a quality recommendation to the user. Games not fitting these parameters will not be a useful recommendation in the near term. At this step however, the actual quality of the game is not being considered.

3. Weight by BGG Rank

BGG provides a highly trusted ranking system. The overall rankings and the general consensus of quality (ie. fun) seem to be well correlated. As an initial quality filter, we will weight the recommendations based upon these rankings. We now have games the users have time and people to play presented with some emphasis on high quality.

4. Associate Related Games by Expert Review

This piece is going to be essential to the performance of the system. Our interviews with our experts will provide us with essential guidance to identify which qualities in games are related.

Exactly how we integrate our expert advice into the system is still up in the air. We have talked about using a simple rule based system. Once the experts provide some rules, we could use them to add weights to certain types of games in certain situations.

5. Neural Network Linking

We have discussed having our experts train a neural network which learns which games are similar. When it knows which games are similar, it could use the rules developed in Step 4 to also recommend similar games to their specific recommendations.

6. Weight by BGG Categorization & Mechanics

Lastly, we would like to identify a useful way to recommend games based on certain Mechanics or by a whole Category. If the user selects “Economic Game” as a Category, we should appropriately weight the recommendations based on this Category. However, we may not want to simply eliminate other games from the recommendations list, as similar games may still be relevant but lacking the exact categorization. We are considering running some clustering algorithms on the database of games, scored by how the experts rank them as similar. If a pair of games is scored extremely similar by the experts, but has a slightly different set of tags, we still may want to recommend both when the user enters one of the set of tags.

7. User Profiles

Beyond this, we have discussed mining the BGG Board Game Collections data and the Board Game Plays data to draw conclusions about which games a given set of players will like.

Hello there, and welcome to the DRSNJM blog, where the team will be posting updates about our work on our knowledge-based systems capstone project at the Ohio State University. We will be posting notes from our meetings so you can track our progress, as well as interesting challenges we encounter and our solutions to them. If you have interest in expert systems or AI in general, this site should provide some interesting content for you!