Game AI Simulator
Visual Studio 2017
Employers within the video game industry
Fronczak. (2018). Game AI Simulator [Mobile app]. Winter Park, FL: Fronczak.
Experiment with the distilled concepts of modern game AI.
Game AI Simulator is a simulation application that offers an opportunity for first-hand experimentation with AI in a dynamic real-time environment. It serves to familiarize users with the fundamentals of modern game AI.
Initially, this project was conceived as a means to an end. I knew that I wanted to gain employment within the video game industry on a technically demanding project, such as an RTS or RPG. The areas of required knowledge for development varies considerably between these types of games. However, one thing that is almost always relevant to such games, is the need for AI. If I could demonstrate sufficient skill in this area, I suspected my job opportunities would open up considerably.
As I began my research in preparation for this project, I started to realize the breadth of systems that are intertwined with any robust AI system. I became inspired by the numerous individuals that have devoted their time to teaching game AI concepts. This list of people includes Amit Patel, Steve Rabin, Alex Champandard, Sebastian Lague, Craig Reynolds, Dave Mark, and numerous others. Through this newfound inspiration, I tried to develop my project with the same level of care and detail.
Capstone Project Scope
When first envisioning this project, the scope was considerably unrealistic for the allotted timeframe. This scope is best summarized through the following Gantt chart that was used for the greenlight presentation.
Out of the 28 primary tasks listed in the original Gantt chart, 8 of those tasks were never started. Those non-started tasks included the in-game node editor, encyclopedia, advanced AI architectures, and machine learning. These tasks were postponed until after this capstone development period because a conscious shift was made towards prioritizing a small polished project, rather than an unfinished mess.
I still intend to implement many of the non-started tasks, especially regarding the UI and advanced agent architectures. This would be in support of the ideal version of this project, which is something that can be undeniably described as comprehensive, interactive, and informative. The current version does have varying degrees of each quality, depending on the particular mode, but there is still significant room for improvement.
The Critique: What went right
Design & Aesthetics
The intent of this app’s aesthetic is not to create a cohesive experience or express some inner artistic desire. Rather, it is intended to convey a sense of purposeful design and utility. Therefore, when a UI element serves its purpose and does not detract from the user’s understanding, it is considered as having been successful. There are three major elements of the UI that satisfy these criteria, which are the app icon, main menu screen, and mode select screen.
The humanoid robot was chosen to be the app icon in part because of its use of neutral and cool colors. By saving the use of warm colors for the terrain and agent indicators, the visual attention of the user can be better managed. Additionally, cool colors were favored for the icon because of its calming psychological effect. Considering that the app icon is one of the first things a user will encounter, it is important to reduce any apprehension the user may initially have with an app about AI.
After pressing the app’s robot icon and opening the app, there is an element of continuity because the app’s icon is also displayed in the main menu’s bottom-right corner. Additionally, the color composition of the menu is very similar to the robot, which gives visual consistency.
Finally, in the mode select menu the user's attention is drawn to the vibrant images of the three modes, which stand in contrast the otherwise neutral UI. The player is enticed to press one of the modes because the rounded corners are indicative of an interactive element.
The use of tracking processes was instrumental in managing the complexity of this project. Before any work, I would start a digital timer through an online time tracking application, which allows for labeling of each time segment. At the end of each week, after having logged numerous time segments, the application would collate the data into charts that would allow for reflection on that week’s progress. This helped to provide a sense of accomplishment and identify problematic areas.
In addition to the time tracking, after making any notable change to the project, I would immediately record the change in a temporary document. When submitting changes through version control, that text would then be directly pasted from that document into the change list. If any problems arose in the future, this very accurate changelist always proved invaluable towards identifying the root causes.
One benefit of testing is that it can identify issues that would otherwise go unrecognized. However, I was generally aware of most issues long before they were encountered through user testing. Due to the large number of these issues and the rapid pace of development, I often needed to pick a small set of issues to focus on. Without regular user testing, it can be difficult to know what tasks should be prioritized. I would often find my myself focusing my efforts on issues that were fundamental to the application’s systems. This kind of focus is certainly valuable in order avoid excessive technical debt, but it can lead to milestones that are entirely underwhelming from an outsider’s perspective. This is where user testing proved invaluable, especially usability testing. Through the completion of a usability report, I was able to identify aspects of the project that were eliciting undesirable feedback, analyze the potential causes, and prioritize tasks that would most improve the project’s reception.
It may initially seem strange that I list communication as a strength of this project’s development, especially considering that I am the sole member of the development team. However, to ignore this aspect would be to downplay the role of the project adviser. If communication with my project adviser had failed, the project would have certainly failed as well. This conclusion is drawn from the fact that the development process was riddled with external impediments, to include hospitalization, financial difficulty, and academic burnout.
Regular communication allowed my adviser to stay informed of the current situation, which made it easier to justify resultant changes to the project. Additionally, due to the frequent communication with my adviser, he was able to regularly provide insightful feedback. While I didn’t always incorporate that feedback exactly how he may have intended, I never had an issue finding a compromise that satisfied both his expectations and my vision for the project.
Ultimately, the success of this project is dependent on its ability to demonstrate a fundamental understanding of game AI. While this project is still rough around the edges and lacks a degree of clarity, it does demonstrate important AI concepts such as knowledge representation (grid), pathfinding, steering behaviors, agent perception, influence mapping, and a behavior tree architecture. With this basic toolset, I am more than capable of mimicking the AI that exists in many modern games. Therefore, I am confident that this project can be considered a success. A sentiment that has been echoed by my project adviser and my peers.
The Critique: What went wrong
Design & Aesthetics
It is my belief that the simplistic design of the app is beneficial to focus the user’s attention on the actual concepts that are being explored. However, there are times when simplicity lends itself well to confusion. The best example is the case of the ecosystem mode. Color is used to differentiate the current emotional state of agents, such as red when agitated. The problem with this simple representation is that relying on color alone diminishes the ability for color-blind individuals to utilize the app. Also, the meaning behind a color can differ greatly based upon an individual’s cultural understandings.
There are also certain visual elements designed entirely around my current experience with AI. Without my personal context, some things cues are likely worthless because they have no inherent meaning. For example, when a steering behavior agent is moving, red and blue lines are used to indicate steering and velocity forces. Other individuals likely visualize these same values through different means. Therefore, the current design is in the correct direction, but it lacks the proper context and subtle qualities that make a simple design, easily understandable.
Adhering to a schedule is generally a good practice, but don’t let that be confused with clinging to a failing schedule. During the first couple months of this project’s development, it gradually became clear that the original plan was too ambitious. I was constantly pushing myself to the limit and yet still falling behind with every milestone. Not only did this foster a general sense of failure, but the hurried pace compromised the quality of any work that was completed. Rather than deliberately writing code that was carefully considered and verified through automated testing, I was usually developing at a furious pace and hoping for the best.
If you find yourself falling into the same rut despite your best efforts, I recommend putting your pride aside and acknowledging that a change is required. In my personal experience with the Full Sail instructors and my project advisor, they can be very accommodating. Once you have formulated a reasonable adjustment to your plan, you should explain the situation and present that idea to your advisor, else you risk catastrophic failure.
One way of considering the quality of development is by the quality of the produced code. A standard method to quickly analyze the source code of a project is by calculating its code metrics through your IDE. After looking at the code metrics for only a portion of this project, you can easily see numerous problems. The two worst offenders, CustomTerrain.cs and Edge.cs, have issues with low maintainability, high cyclomatic complexity, and unnecessarily large line counts. The terrain and grid systems were both developed near the start of the project, so their poor quality can be largely attributed to the frantic pace at the start of development.
When considering the overall state of the project’s source code, it can be described as reasonably sustainable and scalable. However, the fact that important underlying systems have serious problems, is concerning. The reason being, changes to those systems would have implications to numerous other systems. With each day that is spent ignoring such problems, the impact that would occur from changing them increases dramatically. If delayed too long, it will become impossible to change such nuisance systems and their problems will become inextricably ingrained into the entire project.
When working with complex systems that cannot be easily verified manually, it is important to have some form of automated testing. During development, there were a few high-profile bugs that were caused by seemingly unrelated systems, that I had assumed were working correctly. This false confidence could have easily been rectified and the subsequent loss of time avoided, if I had written a few simple tests when the relevant systems were first designed.
The most unfortunate past about this whole issue, is that I had originally planned to regularly write unit tests. However, due to the poor initial pacing of the project, I manage to rationalize the exclusion of such tests for the sake of time. I certainly should have known better, but I let excitement get the best on me.
If I could only impart one lesson upon a student preparing to embark on the journey I am now completing, it would be the following: Make sure to take care of your mental and physical well-being.
For many years, I relentlessly charged towards my every goal with total disregard for my health. In the Army, I stopped at nothing until I had achieved the rank of sergeant and saved a considerable amount of money. This had meant never going out, volunteering for extra work, and assuming a considerable amount of professional responsibility. Once that goal was finished I set my focus on going to college. Despite having saved over 60 vacation days, in just over 3 years in the Army, I decided to go straight into the rigorous bachelor’s degree program for game design at Full Sail. After completing that program with a 3.93 GPA, I began to feel very worn out. Please note, I mention the GPA as an indicator of perfectionist effort, rather than for bragging. Unfortunately, instead of listening to my body, I started this master’s degree program the same day I graduated.
With each passing month, my motivation and energy gradually declined. This situation was exacerbated by family and financial burdens, which led to a state of total burnout. It is quite upsetting because I was really engaged when first researching and implementing AI concepts, but the burnout kept me from truly enjoying what I was doing. Even as I write this post, despite being so close to graduation, I struggle to muster the necessary motivation.
If I had taken some time off before starting this master’s program, my situation might have been considerably different. With improved health, my project’s quality would have likely been much higher and I would have enjoyed my education, rather than longed for its completion. I will admit that this issue sounds whiny and belabored, but I still hope that you will take heed.
While the project may have satisfied its primary objective, it is far from complete. There still exists deficiencies regarding source code, concept clarity, visual design, and audio integration. As far as source code, some scripts are too bloated, convoluted, unorganized, and/or inefficient. When it comes to concept clarity, many user interactions require basic familiarity with the underlying concepts being demonstrated, which limits the app’s potential audience. The project’s visual design is satisfactory for the time being, but certainly cannot be considered complete when comparing it against well received apps on the Google Play store. Finally, the audio in the project is nearly non-existent.
Going forward, this project will serve as a continual exploration into increasingly improved and nuanced AI concepts. Once it has undeniably achieved the ideal qualities of being comprehensive, interactive, and informative, the app will be removed from its beta period and officially released through Google Play. Depending on its reception, I will consider building and deploying the app for iOS and PC.
Algorithms with Attitude. (n.d.). Home [YouTube Channel]. Retrieved from https://www.youtube.com/channel/UCUGQA2H6AXFolADHf9mBb4Q
Board To Bits Games. (n.d.). Home [YouTube Channel]. Retrieved from https://www.youtube.com/channel/UCifiUB82IZ6kCkjNXN8dwsQ
Coding Train. (n.d.). Home [YouTube Channel]. Retrieved from
DeLoura, M. (Ed.) (2000). Game programming gems. Boston, MA: Charles River Media.
DeLoura, M. (Ed.) (2001). Game programming gems. Boston, MA: Charles River Media.
Jonathan Burnside. (n.d.). Home [YouTube Channel]. Retrieved from https://www.youtube.com/channel/UCyrVnZ-rM2YH8EB3OyGLZGQ
Rabin, S. (Ed.) (2004). AI game programming wisdom 2. Boston, MA: Charles River Media.
Rabin, S. (Ed.) (2013). Game AI pro: Collected wisdom of game AI professionals. Boca Raton, FL: CRC Press.
Sebastian Lague. (n.d.). Home [YouTube Channel]. Retrieved from https://www.youtube.com/channel/UCmtyQOKKmrMVaKuRXz02jbQ
Treglia, D. (Ed.) (2002). Game programming gems. Boston, MA: Charles River Media.
Unity. (n.d.). Home [YouTube Channel]. Retrieved from https://www.youtube.com/channel/UCG08EqOAXJk_YXPDsAvReSg