Presentation 20110918 split
•Download as PPT, PDF•
0 likes•233 views
First release of the master defense presentation file, this edition is designed to be play off Flash interface, all transition effects are removed.
![The Need for Better AI ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Viewers also liked (19)
Similar to Presentation 20110918 split
Similar to Presentation 20110918 split (20)
Recently uploaded
Recently uploaded (20)
Presentation 20110918 split
- 1. Dynamic State Based AI Decision Framework Presenter: Kuanhung Chen, MS in Software Engineering Committee Members: Dr. Junhua Ding, Dr. Masao Kishore, Dr. Ronnie Smith East Carolina University Fall 2011 Master’s Presentation
- 3. The Need for Better AI
- 8. Data Layer – Class Diagram
- 9. Presentation Layer – Simplified Class Diagram (Semi-Manual Engine)
- 10. Presentation Layer – Character State
- 11. AI Layer – Action Engine
- 12. Data Link – Character Association
- 13. Data Link – Character Association
- 14. Data Link – Character Association
- 15. Data Link – Character Association
- 16. Graphical Layer - Stock Character
- 18. Project Site – Log-In
- 19. Project Site – Stub Upload
- 20. Project Site – Stub Download
- 21. Project Site – Project Management
- 24. Rounds Selection
- 25. Battle
- 26. Result Display
- 27. Question and Answer Presenter: Kuanhung Chen, MS in Software Engineering Committee Members: Dr. Junhua Ding, Dr. Masao Kishore, Dr. Ronnie Smith East Carolina University Fall 2011 Master’s Presentation
- 29. Simplified User Project Interface
- 30. Test Plan
- 31. Simplified Class Diagram (Manual Engine)
- 32. Class Diagram – Elaborated
- 33. Action Diagram
- 34. Animation Engine
- 35. Animation Engine – Elaboration
- 36. Simplified Character State Diagram
- 37. Interface Design
- 38. Camera Control – Design
- 39. Camera Control – Camera Movement
- 40. Camera Control – User Interface
- 46. AI Stub Injection Interface
- 49. Data Link – Action Driver
- 50. Data Link – Action Driver
- 51. Data Link – Action Driver
- 52. Data Link – Action Driver
- 53. Data Link – Action Driver
- 54. AI Stub Implementation – Template
- 55. Dynamic State Based AI Decision Framework The End
Editor's Notes
- Intro page
- The need for better AI: FPS enemy AI fail, enemies may not always choose best possible choice, a lot of time they choose worst possible outcome.
- The need for better AI: MMORPG AI fail, escort mission, people you are protecting runs straight toward danger.
- Using problem statement instead of abstract to make things short and simple.
- System overall functionalities, separated into three user layers: Player, developer, and Admin Player: Download and runs application using AI stubs Developer: Download and use game engine to develop AI stubs to be uploaded Admin: Oversee AI stub submission to ensure safety
- Algorithm 1: Dynamic source file Pro: Efficiency, dynamic name change Con: Recompile time, user requires compiler Algorithm 2: Dynamic DLL inclusion Pro: Speed and efficiency Con: No dynamic naming
- Algorithm 3: IPC Pro: Dedicated process, location freedom Con: Dump and reconstruct time Algorithm 4: Dynamic DLL Reference Pro: Dynamic inclusion, customizable Con: Efficiency and performance
- .NET layer, data holder, stores game state data. Stores who is where and what the character is about.
- Unity layer, uses the data layer to manipulate game objects and update game state. Could use physics based action or simple action.
- Game is character driven. Character choose what to do and its action affects the game state.
- AI prompt cycle. How character object interact with global game state and uses AI adaptor as well as the action manager. AI adaptor sends a copy of game state and caller character to AI stub is the key of this project. Note, each of the three layers can expand without effecting the other.
- Character implementation by layers. First, an enumerator can be used to reference to a new character so that data layer and presentation layer can use the same flag. Then a generic singleton character fetching method can be created in game state to fetch a new instance of the character. The abstract singleton character factor look into character implementation to fetch necessary data to describe each character, where new characters can be added. Character reference can then be associated in graphical presentation layer by reference.
- Character implementation by layers. First, an enumerator can be used to reference to a new character so that data layer and presentation layer can use the same flag. Then a generic singleton character fetching method can be created in game state to fetch a new instance of the character. The abstract singleton character factor look into character implementation to fetch necessary data to describe each character, where new characters can be added. Character reference can then be associated in graphical presentation layer by reference.
- Character implementation by layers. First, an enumerator can be used to reference to a new character so that data layer and presentation layer can use the same flag. Then a generic singleton character fetching method can be created in game state to fetch a new instance of the character. The abstract singleton character factor look into character implementation to fetch necessary data to describe each character, where new characters can be added. Character reference can then be associated in graphical presentation layer by reference.
- Character implementation by layers. First, an enumerator can be used to reference to a new character so that data layer and presentation layer can use the same flag. Then a generic singleton character fetching method can be created in game state to fetch a new instance of the character. The abstract singleton character factor look into character implementation to fetch necessary data to describe each character, where new characters can be added. Character reference can then be associated in graphical presentation layer by reference.
- Usage of a stock character to dynamically effect how the character looks to reuse available resource. Then the character’s look can be dynamically altered by script to match the needed character’s specification.
- Due to layered architecture dependencies, layers cannot be tested until they are all present. Thus scaffolding system testing is needed to test each component. Before the tests can be done, the depended layer has to be assumed to be correct.
- Log-in by creating account using existing account or ECU intra account
- Upload new stubs
- Search/download existing stubs
- Update project download packages
- Select the characters for both sides. Some algorithm work best with a specific set of characters where as generic algorithm can work with random characters.
- Select which AI stub to use from the “/AI Stubs” folder, where all the download needs to go.
- Select how many rounds by click on the number bar then press [Up] or [Down] to go up or down, hold [Up] or [Down] to incrementally increase selection range. Same can be done by using mouse scroll. Or [Left] or [Right] key to skip by 10.
- Battle until at least one side loses. Repeat if necessary.
- Dynamic pie chart display.
- The end, time for Q&A.
- If necessary, here is a list of indexes to be used to answer things in Q&A section.
- Three categories of users using two components, a simplified version of the Project Functionality diagram.
- Test for expected output and expected failure.
- Simplified class diagram from presentation layer point of view.
- The more elaborated character class diagram from design point of view.
- Simple example on how the action is carried out.
- AnimationEngine flow diagram. How to fetch and get the animation by using an AnimationManager object associated with each character.
- An example on how to use AnimationState flag that’s associated with ActionDriver to trigger which animation to play for the character when performing the said action.
- Simplified character state diagram, much more simplified than before.
- Design the interface in PhotoShop then place the GUI contents. Using guide lines to locate (x, y) location as well as (width, height) dimension of the GUI elements.
- Aim the game camera constantly at where the target is.
- Since the camera is looking at the target, then as long as the target moves or camera moves the view can be controlled easily.
- Mouse control, using click and drag to move the target, scroll up and down to zoom in and out, and right click drag to move the camera up/down rotate left/right.
- Audio manager that plays either background music or sound effect clip.
- This is how the AI stub file is being recognized. By using this scheme I don’t need a secondary database to associate file with its content.
- How to dynamically reference to a class, instantiate an object from the class, and how to reference to the class’ member.
- The difference between Visual Studio .NET’s Reflection class library and MonoDevelop’s C# definition. While similar but syntax is different.
- Since each component acts independently, there is no reason why a secondary form (manual control) can’t pretend to be an AI stub and inject action selection to an AI adaptor. Scaffolding testing.
- Action driver testing, creating a fake game scene with dummy as targets. Display all available actions to visually test the effect of the action drivers before integrating them into the actual scene.
- Built-in methods to help algorithm design.
- Generic methods on how to design AI stubs using this framework.
- Like character reference, there is an action enumerator. Each action has a cost and delay lookup. Action is separated into three types Attack, Projectile, and Defense. Which can be fetch via singleton action factory. Then action object can be associated with action drivers on graphical presentation side.
- Like character reference, there is an action enumerator. Each action has a cost and delay lookup. Action is separated into three types Attack, Projectile, and Defense. Which can be fetch via singleton action factory. Then action object can be associated with action drivers on graphical presentation side.
- Like character reference, there is an action enumerator. Each action has a cost and delay lookup. Action is separated into three types Attack, Projectile, and Defense. Which can be fetch via singleton action factory. Then action object can be associated with action drivers on graphical presentation side.
- Like character reference, there is an action enumerator. Each action has a cost and delay lookup. Action is separated into three types Attack, Projectile, and Defense. Which can be fetch via singleton action factory. Then action object can be associated with action drivers on graphical presentation side.
- Like character reference, there is an action enumerator. Each action has a cost and delay lookup. Action is separated into three types Attack, Projectile, and Defense. Which can be fetch via singleton action factory. Then action object can be associated with action drivers on graphical presentation side.