SimplePathXna is Getting Simpler
I find that a project should become easier and more refined in focus over time, not more complicated and more difficult to use. SPX was always intended to be a bare bones framework that allowed for absolutely nothing more than helping developers creates game at a great pace and higher quality. Today was a successful growth in project OGUR, knocking out some of the critical sub-systems required to build the game.
During the process of crafting some logic I came upon an error in SimplePathXna. I have already pushed a fix for this problem and have decided that I want to do a small amount of work cleaning up some of SPX’s workflow. This will involve two major (albeit overall they are small) steps.
- Bring over most of the changes made to SPX to fit the needs of OGUR
- Separate the business logic of SPX into a separate library file. This will make both setting up SPX and developing larger projects with it much easier to swallow.
Step two is definitely the larger change coming to SPX, but I feel that it is required. Currently a person is tied to the directory structure of SPX if they want to use it. This doesn’t feel clean and actually gets a bit in the way on a project I’m currently developing. Once the project is separated into the framework itself and the sample demonstrating the framework I will push everything in one swell foop.
Later that day…
Having pushed everything, there are a couple of lessons learned. For one, there is a bit of coupling in the DLL to the end graphics that I want to investigate removing. Specifically the ways in which SpriteTypes are used to drive the animation engine and the constructors for the GameplayObjectFactory require GameObjectTypes to be defined, which aren’t available until defined by the end game.