Need help with pom.xml to divide Forge into modules
Post MTG Forge Related Programming Questions Here
Moderators: timmermac, Agetian, friarsol, Blacksmith, KrazyTheFox, CCGHQ Admins
16 posts
• Page 2 of 2 • 1, 2
Re: Need help with pom.xml to divide Forge into modules
by ptx » 08 Nov 2013, 11:46
Yeah, this point is mainly academic, for now it's much better just to focus on core vs gui vs ai, that'll keep us busy for a whilesilly freak wrote:As for game vs rest, I can't see a clear distinction, as things like turn order, priority, winning and losing are also defined in the comprehensive rules. I don't really see the place where a game module would mediate to the player, as the rules are so specific on when and what players can do. setting up a game alone doesn't warrant its own module IMO. Maybe forge's architecture lends itself to such a separation, but I doubt it's worth the effort.
But just to expand on my reasoning here a little bit (in case we ever get to the point where it might get interesting to make this distinction after all)... It is indeed the rules that say what happens when, but from a certain point of view it would be useful to have a separate game module that makes sure that those things actually happens.
The rules module could then be a stateless system, you essentially just ask it questions about a certain game state (what happens next, what actions can player A take at this point, ...). Identical input would always get you identical output.
The game module would be responsible for managing the game state, and communicating it to players.
Consider for example this (very hypothetical) example : we have 3 human players and an AI-server running 3 AIs, all connected to a Forge game server. In this case, the Forge game server would run the game module, it's responsible for handling all communication with players (though it doesn't care about network vs local vs AI, that's just an implementation detail of the player code itself). The players themselves might also run their own versions of the rule engine to make their interface more responsive, but they would not run their own version of the game engine.
But as said, let's just aim for a 3-module architecture
16 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 16 guests