XNA 4.0
Intro
Just as a quick introduction for anyone who isn't familiar with XNA, it is a set of managed libraries designed for game development for Xbox, Windows Phones, and Windows-based computers. It's not so much of a game engine as an abstraction of a few important pieces normally found in game engines. Whereas using a full game engine may be overkill for developing simple games, XNA provides at least a nice starting point and simplifying rendering and certain tasks.
I have a friend who is in the process of developing an iPhone game titled, Jungle Spin.
I've tried to dip my hands before in some indie development, but I was always stuck at the artwork portion of the game. This time around, my friend allowed me to play around with his artwork for his game and with that as a great starting point and a clearly defined game (I decided to attempt to recreate the game in XNA), I set off!
Mostly Overkill
Having just about finished writing my simple 2D entity-component based game engine, I was pretty much looking to implement a similar methodology to the game. Upon first reading of the some of the books I had purchased for XNA Game development, it seemed as it would be an easy fit. XNA at first glance has this idea of "GameComponents" and "DrawableGameComponents" where each one must instantiate an interface including a respective Update() and Draw() method. However it seemed a bit overkill to make everything inherit from GameComponent and register it, since any GameComponent must be given the Game object and I didn't feel that every entity needed that.
I opted to just re-implement the similar Manager system in my earlier engine. I simply defined a base type "Entity" and an "EntityManager" (which is a singleton) and anytime anyone would like to create or kill an Entity/Sprite/Object they would do so through the manager. The manager would then simply iterate through the list and call update and draw on each Entity.
Status
What I had learned while making the game is that art & assets run the show. Things were going very somewhat smoothly until I started to add all the animations for my Monkey. I ran into the following problems; they are ordered from annoying to blocking.
- The sprites were packed into a spritesheet/atlas that had a matching XML file. XNA doesn't come natively with a way to load Spritesheets. Although I could write a custom content loader, I was just mucking around and just hard coded the values (positions within the spritesheets manually).
- Figuring out the speed of the animation for repetitive animations! I'm not really sure how it's done in most games and whether the artist has a particular animation speed in mind, but I pretty much toyed around with the animation speeds until I got something that was aesthetically pleasing.
- Figuring out the speed of animations that involve displacement. Once of the actions the monkey can take is to swing from vine-to-vine with an accompanying animation. I'm curious as to what other artists do. Do you explain to them the distance they'd like to travel in the animation so that they can create enough frames or is the animation speed changed to always match the distance to be traveled?
- Figuring out the anchor of the texture. Every texture can specify an 'origin' during the spriteBatch's draw call. This origin is normally set to the top left corner of the image. This had caused me a lot of headache because all the textures of the monkey had his feet at different locations within the texture. This meant that transitioning from one animation to another caused a minor displacement. I tried to overcompensate for this by playing around with the origin until someone pointed out that normally artists always have the sprite centered in the texture for this very reason! I'm currently blocked on this issue as I need to modify all the textures
Checkout the question on gamedev.stackexchange on this very question.
Here is an early working video of the game (1-2 hours worth of work). Since then I had included the 3 additional vines (including dynamic random vine generation) and the extra animations (i.e. jumping from vine to vine).
Design: Simplicity over Awesomeness
Although the big buzz about games is to have them abstract and the best way to do that is to normally make it so that your engine is Component base driven. Although that architecture lends itself to amazing data driven design, I wanted to just try and bang something out quickly and most importantly simply. You can see from the UML design above that a lot of the Entity types could be re-factored to simply be a base entity holding different collections of Components instead.
I had made a pretty decent post on gamedev.stackexchange.com regarding the question on using GameServices and GameComponent architecture that is contained within XNA and recieved some great feedback as well.
