House of Quality Matrix 9

Phases of Design 9

BMC Model 1 11

BMC Model 2 12

Gantt Chart Part 1 13

Gantt Chart Part 2 14

The goal of this project is to develop a Chess Variant Application that provides a variety of unique gameplay twists on the classic game of chess. This application will give players the ability to play any variants of chess against AI agents or other humans online. There are not many applications that offer a unique spin on the gameplay of chess like variants. There is also not one localized application where players can play with others online and AI agents. This provides our project a good opportunity in the market.

We will be able to utilize many open-source technologies for this application. For example, we can utilize already existing AI agents for chess, and build upon them to work for variants of chess. We can also do this for the main chess game itself. Utilizing an open source technology and editing to fit our specific needs within a variant of chess. There are also many additional features that we can add to enhance the user experience of the application.

In order for us to determine and narrow down what exactly would be the most useful integrations for our device, we will conduct customer interviews with Dr. Christopher Flora, an avid chess enthusiast, and Dominic Matessyk, a chess game and chess AI developer.

A Chess Variant Application will allow many chess game players to experience chess in a way they have never before. It will also allow for players to learn and improve on their skills in chess or a chess variant. Currently, there exist few applications where users are able to play chess variants against another human or an Artificial Intelligent (AI) agent. For example, there is Chess.com, a website where players can play against other humans online, and ChessV, a desktop application that allows the player to oppose an AI agent for a select amount of chess variants. Multiplayer opponents and AI agent opponents exist on different platforms.

For our application, we will mainly be focusing on the amount of variants able to be played, and the AI that the player will be able to oppose. There will also be a strong focus on online multiplayer with the application.

The objective of our Chess Variant Application is to provide chess players with an accessible and safe platform to experience chess variants on. We also want to provide a customizable AI agent to allow players to play against any difficulty of the agent instead of preset values. This will allow for players to learn any level. Potentially there could be a feature that predicts what AI agent level will line up with the current players playstyle.

With this application we also hope to provide a satisfactory and safe online experience with other players from a cybersecurity, and social perspective. For example, we do not want to share any personal information of one player with another player. Or if there is an online chat feature, we would like to have this automatically moderated as a safe chat for all players.

Lastly, we hope to provide a robust and computationally efficient AI agent or Machine Learning model that is comparable, if not better, than other chess game variants on the market.

Background & Literature Survey

Chess is a board game in which two players compete against each other. It is among the most popular games globally, with millions of players. Playing chess results in better brain function, enhanced memory, and improved attention (Zhang, Li, and Xiong, 2019). Various platforms enable people to play chess online; (Nair, Marathe, and Pansambal, 2018.) this includes chess.com, Red hot pawn, Liches, and Chess24.

These platforms have varying features and functionality to enable people, learn, play and contest efficiently and with less complexity in using the site.

Chess.com, the most popular site, enables an individual to sign up and play against the computer or a human competitor. Its standard features include unlimited chess games in different styles and variants, supporting clubs and leagues with an unlockable achievement system.

Red hot pawn is a one-of-a-kind gameplay experience, particularly for those who favor a slower pace. It has a user-friendly platform that enables juggling numerous games a breeze. In addition, there is an educational forum and a unique support structure. While there are no prerequisites for using Lichess, it does provide the ability to learn and play chess. It comes in various flavors, including cloud-based chess courses, and it supports a wide variety of languages.

These sites are significant since they are free to get and can play chess variants against a human or an AI rival (Wilkenfeld, 2019).

Chess has gone a long way since it first appeared on a computer, and each year, a new chess engine emerges that outperforms the preceding one. Each engine has been improved, and new techniques to manipulate the graphical user interface have been devised (LinLin, YuNu, YaJie, and Guoqiang, 2017). A site that provides a changeable Artificial Intelligence agent that has the potential to allow gamers to play against the agent's complexity instead of preset levels are desired. This will allow players to learn at their own pace (Su, Shiau, Guo, and Shiau, 2009). A

component that forecasts which Artificial Intelligence agent rank would align with the actual player's playstyle could be included.

We found several requirements customers have for a software application. The first is that the application should be low cost to make it more accessible. The second requirement is that the software should be easy to use. While a slight learning curve is inevitable, if an application is too much of a hassle to use, customers will opt for alternatives. The third requirement is that updates are quick. This is especially important if there are bugs that make the application unenjoyable to use. The fourth requirement is that it has a variety of uses, this attracts a large user base. The fifth requirement is that it is compatible with multiple platforms. In a world where not everybody uses

the same operating system, this is essential to reach as many people as possible. The sixth requirement is that the interface is modern-looking. Unattractive UI can repel users. The seventh requirement is that the application is not resource-intensive. Not all customers will have the same level of power in the systems they are using, so we need to be mindful of that. The eighth requirement is that customer support resources are available, so that they can reach the developers in case of any issues. The ninth requirement is that the app is engaging. As a game application, it is not useful if it isn’t fun to the customers. Lastly, it should run reasonably fast.

There are several engineering requirements for our project. Firstly, that our code is clean. Messy code will inhibit our process of designing (and any future updates). Secondly, we need to compare it to similar applications and make ours a top performer. The third engineering requirement is speed, not only is excessively slow software bad for customers but it also makes it more difficult for us to test. The fourth requirement is innovation. The fifth requirement is good documentation, this is necessary if our software becomes open-source, and it also serves to help

us as developers. The sixth requirement is not a lot of bugs, we need to minimize bugs as much as possible in our process. The seventh requirement is secure, security is very important so that our content and data is not compromised. Additionally, our software should be scalable. Given that there are many possible variants and features for the application, it is important that the app could grow instead of staying stagnant. Lastly, our application needs to be both cost efficient and efficient to maintain.

Our application has a number of constraints and tradeoffs that factor into the design and decisions that must be made. Four main constraints and tradeoffs that must be considered for our application are: which platform it will be released on, whether it will have 2D or 3D graphics, the chess variants that will be implemented in it, and time.

The platform we choose for release will affect the processing power we have available at our disposal and what types of input systems we must design for. We will also have to consider the cost to publish on each of these platforms. Publishing on multiple platforms will expand the reach we have to our audience but also increase the complexity of the project as we will have to design ways for the user to interface through each one. Due to the different processing power available to each platform and user devices, platform selection may also impact graphical decisions if we aim to ship to lower-end devices.

A choice will also have to be made between 2D or 3D graphics. 3D graphics can look more appealing and realistic and set our app apart aesthetically, but it also introduces complexity into the system. The 3D perspective could lead to a more complicated user interface if camera controls are taken into consideration and the less symbolic representation of 3D could obscure gameplay concepts compared to a simpler 2D application. A 2D representation could remove the need for any sort of camera control and provide a clear symbolic representation of gameplay concepts.

The types and number of variants we will implement in our application also comes with a handful of tradeoffs. We can only implement a finite number of chess variations and each one will add to the scope of the project. Some variations may be more complicated than others, calling for different board shapes or more complex piece interactions. It is important to not scope

too big but we must also consider that the variants we present our one of the biggest features that will set our application apart from others. Because it will be necessary to implement a variety of chess variants, the design of our underlying chess system must be very flexible to host a variety of altered rulesets, boards, and pieces. The variants we implement will also play a large role in the complexity of training an AI system to play the different variants we implement.

The last and tightest constraint on this project is time. The project will have a finite time to be completed in the spring semester. It is important to scope the project so that it can be completed within this time frame. Our team will have to define and split up the feature set of our application into a variety of tasks to deliver a quality product in a timely manner.

Our application will have to adhere to the standards of the platforms it is published on. It may be necessary to develop publicly available privacy policy or terms of service documents.

This application will also have to disclose any sensitive permissions it may need on some platforms such as mobile storage. It will also be important to adhere to any family or content rating policies a platform may have (such as Android's Designed for Families policy) when deciding on target audiences, the nature of advertisements, monetization, and online interactions we may put within the application.

We are currently in the “Concept Generation” phase of design. We have identified the

problem (the scarcity of cross-platform applications featuring chess variants). We have also researched existing chess AI frameworks and applications. We developed both engineering and marketing requirements (discussed more in depth in the Requirements section).

As with any software application, we must be diligent to respect customers’ preferences as to how their data would be used. We would obtain explicit consent to use data, and not sell it to any company. In addition, if there is the option for users to contact each other, we would need safeguards against online harassment and bullying. We would need to practice good security, so user information is not leaked to third parties.

Initial

Hypothesis: Customers will buy our product because there is a large demand for innovative multiplayer games that utilize artificial intelligence.

After 1st Interview

Hypothesis: Customers will buy our product because we will offer popular chess variants to players on multiple accessible platforms.

After 2nd Interview

Hypothesis: Customers will want to buy our product because there is a demand for innovative chess software, specifically ones with twists on gameplay and features to help users hone their skills.

BMC Model:

Our goals for Senior Design one were to form a team, select a topic, and find an advisor. We achieved all three of these things, although we are still formulating all of the details for our project. In the future, we will design and implement our software.

Appendix A (References)

Need at least 5 references, in IEEE/ACM format

LinLin, W., YuNu, W., YaJie, W., and Guoqiang, C. 2017. Research on the Surakarta chess game program based on unity 3D, 2017 29th Chinese Control and Decision Conference (CCDC),7671-7674, Doi: 10.1109/CCDC.2017.7978580.

Nair, A., Marathe, K., & Pansambal, S. 2018. Literature Survey of Chess Engines. International journal of engineering research and technology, 5.

Su, K., Shiau, S., Guo, J., and Shiau, C., 2009. Mobile Robot Based Online Chinese Chess Game, 2009 Fourth International Conference on Innovative Computing, Information and Control (ICICIC), 528-531, Doi: 10.1109/ICICIC.2009.261.

The purpose of the project is to create a continuous wave (CW) analog signal generator for Advanced Radar Techniques Equipment Microwave Integrated Systems (ARTEMIS) Inc. It will be used to simulate a direct digital synthesizer (DDS) used in Synthetic Aperture Radar’s (SAR). This device will replace the expensive, long lead time and custom designed DDS’s.

The analog signal generator will synthesize a sinusoidal wave. Its frequency will be adjustable and be provided to the user via SubMiniature version A (SMA) connection.

( 10 )

Advanced Radar Techniques Equipment Microwave Integrated Systems (ARTEMIS) Inc. needs a low cost, low frequency analog signal generator. This device will help solve their signal generator shortage and save the company money. Generators on the market today are very expensive with many features that are not needed. ARTEMIS would like a simple signal generator that will meet their needs. This generator will be used in their upconverter test setup. This test setup requires a 0 MHz to 300 MHz analog input signal used in the upconverter’s translation and generation of transmit (TX) and local oscillator (LO) signals. The test setup consists of a few high frequency, one low frequency generators and a spectrum analyzer.

Our objective is to design a portable low cost analog signal generator using the Direct Digital Synthesis technique specified by the company. This device will have a user interface that will allow the user to interactively set the output frequency. The generator’s output must be available via SMA female connectors for easy access by the user. The device will also have multiple profiles. Each profile will allow the user to set and recall a particular frequency.

Most signal generators on the market today (in the range of 0-300MHz) cost anywhere from

$800 to $2,000 dollars and above. [1] These generators are designed to meet the needs of many different customers and therefore support a wide range of functions and special features. Many of these extra features are not needed and will not be implemented in our design. Due to limited resources, the signal generators at ARTEMIS are shared among multiple test setups. This is an inconvenience and can cause delays in system testing. The company cannot justify buying separate generators for each test setup when only some of the features will be utilized. Our task is to design a low cost signal generator for ARTEMIS that doesn’t include unnecessary (and costly) features. The signal generator will be designed to output a variable sinusoidal frequency. This signal will be used as a reference for the (Direct Digital Synthesis) DDS signal. The upconverter is one of ARTEMIS’s products used for translation and generation of TX and LO signals. The TX and LO signals are generated by up converting its input signals to a high frequency radio signals.

Figure 1 shows a basic radar system block diagram. The overall function of the DDS is to generate a chirp. A chirp is a quick frequency sweep. The chirp is sent through the upconverter where it is up converted to a microwave frequency. The microwave frequencies are then amplified by the SSPA (Solid State Power Amplifier) and transmitted out of the antenna. The system is then switched to receive mode where the reflected signals are captured by the antenna and sent into the receiver. The receiver then down converts the signals and sends it to a digitizer. The digitizer uses an ADC (analog to digital converter) to convert the signal into a digital representation of the reflected signal. The data is then sent to the digital signal processor to extrapolate the image.

Our waveform generator will be replacing the DDS subsystem during ARTEMIS’s testing phase. It will be used to supply an analog signal to the upconverter. Each fundament frequency of the upconverter is tested and tuned to the desired level.

Figure 1: Basic Radar System Block Diagram

Figure 2: A basic DDS system

The basic function of a Direct Digital Synthesizer is straightforward. A lookup table holds a digital representation of the desired waveform over one period, with each row of the table containing a sample of the waveform’s amplitude. A system controller steps through this lookup table at a specific rate, feeding its value of the current row to the input of a DA (digital to analog) converter. When the controller reaches the end of the lookup table it cycles back to the first row and repeats the process. This process results in the desired analog signal appearing on the output of the DAC. Since no time consuming calculations are needed during signal generation this is a notably fast technique. The output frequency can be changed by altering the values in the lookup table or reading from a separate lookup table

There are multiple ways to implement a DDS system. One possibility is to directly build the DDS shown above using standard logic components. Alternately, a DDS system could be developed using a FPGA (Field Programmable Gate Array). Finally, a dedicated DDS SOC (system on a chip) could be used. Each of these implementations has advantages and disadvantages as discussed below.

Designing the system using standard logic components such as RAM memory, a micro- controller, DA converter, counter, etc would allow for a great deal of design flexibility. We would be able to choose precisely what features would be included in the design and not have to pay for other features that wouldn’t be necessary. For this reason, this implementation is likely to be the cheapest of the three. One disadvantage to this solution, however, is that the design would be very complex. Extensive consideration would be required to ensure that the device could achieve the frequency range and frequency resolution specified by ARTEMIS. Also, we

could easily be “reinventing the wheel” by using this method since there are dedicated DDS chips on the market that might have the same functionality.

Using a FPGA to realize a DDS system would provide a moderate amount of design flexibility, although not as much as a basic component-based system. This implementation would reduce design complexity, since FPGAs can easily be reprogrammed and thus different design solutions could easily be tested and compared to one another. Some components may be required in addition to the FPGA, but this solution will still be much simpler than the previous one. As with the basic component-based system, this design work would be unnecessary if there is a pre-built DDS chip on the market that exhibits the functionality desired.

A dedicated DDS chip can have all of the system components integrated onto a single chip. Although designing a dedicated chip ourselves is beyond the scope of this course there are many DDS chips currently on the market that might be appropriate for this project. This method provides minimum design flexibility since we would be limited to the features already designed into the chip. However, if we find a chip that satisfies our project requirements, this will be a very viable option.

Another possible choice is to use an FPGA with a soft core. With this method, the FPGA is configured to operate as a reduced instruction set (RISC) processor. Software can then be written for this processor in assembly or even the C programming language. We would then write a program to implement a DDS system and load it onto the FPGA/RISC processor.