CySoftDev

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

129 Neutral

About CySoftDev

  • Rank
    Newbie
  1. What are the advantages/disadvantages of completely modularizing my game model code into its own DLL, and creating an XNA Game Component to, essentially, function as an adapter between XNA and the game model?  All I want XNA to do is draw stuff and capture user input. One advantage I like is the ability to unit test the game model itself. I also like that it keeps solution files better organized (that's one thing that has driven me MAD with the books I have on XNA game development; there is little to no organization of the solution files...) I like the clean separation of responsibilities, and the portability it affords the actual game logic (it could later be hooked up to Unity, SFML, etc.) I am aware that it takes more effort, having to develop an interface for the game model; am I overly in love with separation of concerns?
  2. Looking for a mentor

    Until you find a mentor, the CodeKata site might be useful.   Best of luck to you!
  3. Might have answered my own question: why create two different systems for the same thing?  If I'm going to build the id-based system for the external interface, might as well use it internally as well. Does this seem reasonable?  Seems reasonable to me...
  4. Your second idea, have a component for each state, sounds similar to the GoF State Pattern, which may be a good sign :)
  5. I'm building a utility/support assembly that maintains data & state for any tile-based board game: it should be able to model everything from checkers and chess to a Civilization-esque game (no visuals, just state & data).  They're just boards with height, width, and stuff that goes on the board.   Consumers of the assembly wont have access to domain object instances, but will have lists of ids for the various entities active in the model.  The public interface is in domain terms only (create a boardpiece, move a boardpiece, set value for an attribute of a boardpiece, etc).   I'm stumbling on the internal implementation: is it sounder for domain objects to have references to each other (easier to code, but could also result in code that invalidates the model; a BoardTile shouldn't mutate the Boardpiece it may contain), or to mirror the public interface, and only reference other objects by "domain entity id" (seems overly restrictive, and a little more work to implement, but may be better for enforcing compliant code)?