Assignment Three: AI and NPCs
Project Description
In this assignment, you will add AI to your previous game's single-player mode. This AI will include simple decision-making and navigation. You will need at least two types of agents (e.g. a single enemy type and a friendly NPC, or two enemy types), and each AI type will support at least 3 behaviors (e.g. attack, retreat, dodge). By the end of this project, you will have multiple agents of each type within your single-player game mode.The underlying functionality should be build in GDExtension, and you should be thinking about your AI system from a tools/plugin perspective. That is to say, ask yourselves "how can I make this AI system modular enough such that someone else could use my GDExtension base to build out their own AI features in GDScript/C#?" While you can certainly build out your own game's "high level" functionality in C# to create a compelling game experience, remember that this class is about the underlying system functionality, and one of this project's central goals is to create a useful tool for facilitating the game creation process.
Basic Requirements
- AI System
You will implement the underlying AI functionality using one of the systems we discussed in class. This can be a finite state machine, fuzzy logic, a decision or behavior tree, a rules engine, etc. That said, it should be something that makes sense for your game, and you should consider how you will program behaviors using this system. That is -- how would a designer create behaviors for individual agents using your system? Are you programming the functions directly or giving them access to a scripting system? For now, programming the functions directly is fine, but use this process to help you consider what additional features you think designers ultimately need.
- AI Behaviors
Each AI type will need to support at least 3 behaviors (not including death/respawn). In the case of an FSM, this might mean having 3 states agents can transition betweeen, but a rules engine will likely need more than three rules to create an equivalent behavior. Therefore, this idea of "behavior" can be considered broadly, so long as the AI behaviors are distinct enough that we can discern the difference during play, and are interesting enough that novel interactions occur when playing. You may decide how behaviors interact with each other, so they can be distinct (like states) or have overlap (like fuzzy logic).
- Multiple Agents
You will need multiple agents that are based on at least two distinct types of AI. Both types of AI should use the AI system you create, but they should be implemented differently enough that a player can distinguist their behaviors. You can choose where to position these agents in your world (both to highlight their intelligence and avoid buggy behavior), but we will need to be able to experiment and interact with the AI for grading purposes.
- Navigation
Your AI agents will need to perform some sort of world navigation in addition to having multiple behavior types. Typically this is done using A* pathfinding, but you can also use waypoints or flocking behavior etc. Again, consider the needs of your game when choosing how to implement agent movement. Note that Godot has a built-in implementation of A*, so you can either build something interesting on top of this, or create your own form of navigation in your custom GDExtension node. You will be evaluated based on the the complexity relative to the difficulty, so we'll expect more interesting behaviors if you build on top of the existing A* nodes, whereas simpler behaviors are fine if you're building navigation from the ground up.
Extra Credit
- AI Animations (2 points)
Give your AI agents animations!
- Robust AI (2 points)
AI is very difficult, so if you are able to make particularly robust and interesting AI, we will give you additional points for your trouble. Be sure to make a note in your report stating why you think you deserve this extra credit just to make sure we pay close attention when looking for it.
- Even More Particle Effects (1 point)
Yeah!! Why not?!!
Milestone 1
- Documentation: You will turn in a document with the following information:
- Overall design of your AI system. What system are you implementing? How will you program specific agent behaviors within this system? How will you debug unexpected AI behaviors?
- Software architecture and plan. What data structures will you use to represent behaviors and transitions? How will your AI update itself? Polling or event-driven? What classes will you need to create to handle the AI behaviors, and how will it associate with the individual agents? Estimate how much work it'll take to incorporate each of the required capabilities. If it looks like you won't be able to meet your deadline, how can you scale back during the second week?
- Division of labor. In terms of the delivered capabilities, who is responsible for which parts of the code, and what is your plan for meeting up? My experience is that teams, who meet up and code together on a regular basis create a more cohesive, functional project than teams where everyone works autonomously and tries to come together at the end. Keep this in mind during your planning stage.
- Project Demo: You will also submit a link in the milestone report containing any initial demo code of your proposed game for Milestone 1.
This demo can be simple, but we need to see rudimentary versions of the expected AI capabilities, so we can gauge whether or not you're on track.
This demo should compile and run, and you will provide instructions on controls and how the pieces of the demo in some way address your proposed creation (see final game deliverables). These pieces do not need to be at 100%, but they do need to exist.
Final Submission
You should turn in link to your GitLab like you did in the previous assignment. Make sure you have your file structure and SCons files set up correctly, along with your .gitignore and .gitattributes, to minimize build pains. Please also make sure you included all relevant files, including those related to the Godot project, and your own source/library files. Also include:
- A README giving full build instructions and version info
- A User Manual explaining how to play your game, game objectives, and any extra-credit worthy features
- A Project Report that tells us what functionality you've implemented, any other interesting features of the program (e.g. it's really fast because I did this clever thing), what software it relies on that you didn't write, issues you encountered if there are unresolved problems, and how to use the program once it's built (trivial for the base version of this assignment, but critical for later assignments and any extra credit work). You should also document your code layout and describing the basic implementation of your classes. You can include either code snippets or screenshots of the more interesting features in your code. This will help the TA spot check your implementation in case rebuilding the game is too time-consuming.
- A link to video footage (ideally via Youtube or some other easily accessible platform) of your game in action, demonstrating all basic features plus any extra credit features you implemented.
- Individual Evaluations which each member of your team will turn in separately (not as part of the team's game package) an evaluation of the performance of your team on this project, your strengths, weaknesses, what you'd do differently if you were starting again, the main things you've learned. The evaluation must include a specific evaluation of your own performance and that of each of your team members (again both strengths and weaknesses). This will be kept confidential and will be taken into consideration in grading.
Getting Started
This is the most open-ended project yet in this class, which is why it is essential for you and your teammates to start coordinating early! You have a lot freedom in terms of deciding the behaviors you want and how you will implement it, so you will need to do your own research into AI implemenation details that will be relevant to your project. Gamasutra and Game Programming Gems are good places to start.
In terms of building out these systems, remember to start very small and implement very simple behaviors initially. AI generally requires a lot of testing and tuning, so take that time into consideration when designing and implementing behaviors. Think about how fun the Pacman AI is despite being quite simple, and how frustrating more complex, but broken, AI can be. Taking this into consideration when starting this project as well.
You may be tempted to make general upgrades to your game in addition to the AI requirements outlined above. Perhaps you didn't finish some things last time. Perhaps you finally figured out what you want to do, or how to do it. Such upgrades are cautiously encouraged, provided you make your first priority getting the basic requirements done. Any additional upgrades will be considered for extra credit to mitigate points lost on Assignment 2.
Turning it in
We'll use Canvas as with previous assignments. Only one teammate needs to turn in the assignment as a link to your Gitlab. Make sure you have the project you'd like us to consider on a branch called code-freeze and that you add both me and the TA.
Grading
Grading will be handled the same as Assignment 2: C quality work is implementing the features in a way that is mostly working, but may be buggy or not scalable. B quality work is implementing the features in a way that works but may have scaling issues, or lacks consideration for tuning and iterating. A quality work is implementing the features in robust, polished way that demonstrates consideration for tuning and scaling.
Make sure you meet the requirements before doing additional enhancements. And when considering enhancements, realize that improving the UI/gameplay/etc is generally a better place to spend your time than adding bells and whistles. If you end up showing this off to people later, you'd much rather they get involved in playing it than for you to have to hang over their shoulder showing off your special effects and apologizing that you never actually got it to a playable state.
Last modified: 10/06/23 by Sarah Abraham theshark@cs.utexas.edu