SPX has been built by taking code from OGUR and refactoring portions of it to be more useful for general game development with the XNA framework. One week ago I loaded OGUR onto my XBox 360 to see how it performed compared to the PC version. That test was intended as a way for me to see if the first of two graphical overhauls looked as good blown up on a big screen as it does on my laptop.

Boy oh boy did I underestimate how important that test turned out to be.

Starting out, I couldn’t even get the console specific project copy to build. Thanks to multiple blog postings I was able to find out that the Xbox runs a different version of the .NET runtime than what runs on the PC. This meant that I first would need to implement some features from .NET 4.0 in .NET 3.5 which OGUR needed to run. Only after I completed this task did I realize that the target runtime could be changed in the Xbox project without adverse effect. DOH!

As soon as the game launched on the console, I knew something was horribly wrong. OGUR had run on the Xbox in its early stages, but I hadn’t taken any time over the past two months or so to test on the console. I didn’t think there would be any major differences between the two platforms, especially since OGUR (and subsequently SPX) are built to dynamically handle both PC and the Xbox.

By leaps and bounds the most dramatic problem was lag. A button on the controller needed to be held down for literally seconds before any movement would occur. Don’t even get me started on the lack of response shown by the HUD for each player. This was a crippling blow to my momentum on the project.

Sitting on my couch, I knew there was no chance of me backing away from OGUR. With the engine nearing completion I couldn’t cut my losses and either build from scratch on another platform or simply pursue a different game altogether. There was certainly a temptation to quit in the back of my mind, but in hindsight my obsessive nature over this project wouldn’t have possibly let me stop.

What could have been a trainwreck for OGUR turned into an amazing bound forward for both the game and SPX. Over the past seven days, I’ve run countless memory and processing performance tests for OGUR both on PC and the console. I’m happy to say that after many hours and an entire weekend spent, OGUR is once again playable in the Xbox. In the process, I’ve added a number of useful helper utilities to SPX which I plan on pushing to the repo once I can grab another spare handful of hours.

 

 

SimplePathXNA (SPX) was refactored out of my capstone project last semester. At that time, it was a very messy Visual Studio project that one could start with as a base for creating their own game. In that stage, SPX was used as the foundation for OGUR. Over the past three months extensive work has been done while expanding OGUR to enhance the usefulness of the SPX framework.

My fiancee and I are interested in working on a simple game during our spare time. In an effort to speed up the development of our prototype for that game, I have pulled a huge amount of updates to SPX from OGUR over the couse of the past twenty four hours. All of these updates are now pushed on the master repository stored at Github (link available on the Projects page). Additionally, a 32 bit DLL of the library is now available for download.

On top of all of that, the SPXDemo has been re-written to use the new DLL instead of being coupled to the SPX project. A new tutorial will be coming once I have a few extra moments later this week.

 

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.

  1. Bring over most of the changes made to SPX to fit the needs of OGUR
  2. 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.

======

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.

 

The basic functionality of Bombard360 is finished to the point of what is due for my coursework. Now that I basically need to freeze the repo until classes are over (for grading purposes) I used the free time available to abstract out a lot of the code from Bombard360 into an easy to use framework for other 2D games.

This new framework can be found at this GitHub repo.

To get a feel for how the framework is used, try the following to add a new element to the game.

  1. Draw a new sprite in the next open open row of “SimplePathXna\SimplePathXnaContent\GameplaySheet.png”
  2. In the VS2010 solution, add a new element to the SpriteType (\Sprites\SpriteType.cs) enum that described the object you want to add to the game
  3. Add a new dictionary entry defining the contents of the sprite to SpriteSheetManager (\Sprites\SpriteSheetManager.cs)
  4. Create a new class that inherits GameplayObject (\GameObjects\GameplayObject.cs). In the constructor, pass the location and SpriteType into the protected Initialize method. This will handle most of the graphical setup for the class.
  5. Create a method within your new class with the following signature: public override void Update();, and define the object’s game logic here.
  6. In GameplayObjectFactory (\Factory\GameplayObjectFactory.cs), add a new case to the switch statement that defines the way your new object shall be created
  7. In GameplayState (\States\GameplayState.cs), call the function Add(GameplayObjectFactory.Create(400,400,SpriteType.YOUR_NEW_SPRITE_TYPE)); in the constructor
  8. Run the application, and an instance of your new object should show up on screen at 400,400. If not, then there’s a good chance that a null exception will be thrown before the game can launch, showing you what step you missed in setting the object up.

The benefits I’m finding from using this growing framework is the topic of a future post, but feel free to shoot me an e-mail if there are any problems encountered in getting setup with the project.

© 2012 Simple Path Studios Suffusion theme by Sayontan Sinha