Monday, September 29, 2014

For Class: A Brief on XNA Architecture

So, for Graphics Programming I this week we were asked to restructure some of our code and write a blog post about it (the architecture) of our XNA projects. Because I already planned a basic architecture for all of my projects, I didn't actually restructure anything, but instead, I am going to briefly and simply explain my "architecture".

Here is the basic architecture (as it is for now)

  1. GameWorld
    1. Menu
    2. LevelOne
    3. (Any or all self-contained worlds)
  2. GameObject
    1. Sprite
      1. AnimatedSprite
      2. Text
    2. Tile 
      1. ModularTile
  3. NewCamera

Each project is broken into Worlds which can be derived and overridden. Worlds are composed of GameObjects which make the levels actually do things. Every object in the game is derived from a GameObject class, though in most cases, the player will be creating Tiles, Sprites or Text objects. The GameWorld maintains a list of GameObjects that it will consistently draw, update and allow manipulation of, but it does this automatically, so all someone has to do is create an object and add it to the world's objectList and it will be drawn and updated. That means that to create a game or content, I can derive from the major classes and override virtual/abstract functions and define any gameplay that I want. It's very simple, but fairly robust.

There is also a separate NewCamera class which consists of a matrix that defines how the view should be drawn. The camera can be loaded into a GameWorld as each GameWorld has its own main spritebatch that can be overloaded/edited for the needs of the level. The user can create and define a camera object or choose not to and the level will still run. Movement of the camera can be defined in an overridden camera object or be handled directly within the class or even other classes.