Gaming update #27
Open
Gaming update #27
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…Dynamically setting game agent player ids when the game is instantiated (independent of who goes first). Decoupled game agent and game bi-directional dependency. Added templating to reduce object type casting. Added TicTacToeGameAgent abstract class. Updated clients and junit tests with these changes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
"Dynamically setting game agent player ids when the game is instantiated (independent of who goes first). Decoupled game agent and game bi-directional dependency. Added templating to reduce object type casting. Added TicTacToeGameAgent abstract class. Updated clients and junit tests with these changes."
The broader change in this update is templatizing the game object to expect a type of game action and game agent. This largely eliminates the need to constantly check object types. Future expansions to the gaming functionality can then have less hierarchical overlap. To this end, I had to decouple the strong dependencies between the game agent and the game, otherwise the templating would be a huge mess. If in the future it is important for players to know who went first, either appending that type of metainformation to the game board or creating a game metadata object would be the best practice to avoid that circular dependency issue.
One potential issue I realized during this is that game search agents are updated every game update cycle (at least as far as I can tell). The issue is that it would scale poorly with a lot of ships as either: 1) multiple new search agents are instantiated every frame, rather than being instantiated on-demand and 2) a single search agent reference is shared across multiple ships, which might behave abnormally if then multiple ships collide with a gaming asteroid on the same update frame (not very likely, but the probability scales as more ships/asteroids are in the environment).