Oh, it’s been a while since I have written anything about Little Longhorn! Actually I just discovered that my last post is from 1. February 2010, so that is pretty crazy how fast times goes by. :)
Even though I haven’t written anything about the game a lot have actually happened. In this post I will take you through some of the things we have done these months.
What you see in the middle is our new RadialWheel menu component.
[more]
Code clean up and a lot of rewrite/refactor
In the last post I wrote about how we showed a alpha version of the game at a party and how it went. The two weeks up to this party we coded intense on the game to make it playable. We had the focus on getting things done fast, not making any big thoughts on the code design. This resulted, and we knew that from the start, in some “Spaghetti code” just to make it work.
After the party we started to clean up all of this code and at the same time we discovered that we had a major bug in the core (coordinate system) of our engine. Without getting into too much details about this, we spend a good deal of time on figuring out how we actually wanted it to work and how we could implement it.
[Insert a lot of trial and error here :) ]
When we figured out how we would like it to work and how we would implement it, the entire game almost broke down, as these changes where so fundamental that almost all code needed to be fixed or entirely rewritten. This gave us a lot of work, without actually doing any progress on the game it self.
Now we are almost back to the point where the game is playable again, but we now have a much better and cleaner codebase to work with. Which makes changes a lot easier.
Everything is XML – almost
One of the really big things we have done, which is making our developer lives SO much easier now, is the ability to define things in XML and load it in from code at runtime. We have this concept of Screens and Components, which makes up the entire game. Both of these can be defined in XML and used in code , actually a little like how XAML and code-behind file works in WPF and Silverlight. It really makes it easy to put new things in and move around, and keep the focus on the actual logic, not how you the texture on the SpriteBatch etc.
We are not ready to really show any of this code yet, but I still thought I would tell you about it, as it’s a major thing for the engine we are building, to build Little Longhorn on.
SilverSprite changes
As we write the game for both Xbox360 (XNA) and Silverlight we use a library called SilverSprite. This makes our XNA code run in Silverlight. Up until recently, SilverSprite have had it’s own namespaces, which meant that we needed to do a lot of #if SILVERLIGHT in code, to make it work. Now Bill Reiss have changed this, so SilverSprite now uses the same namespaces as XNA, which makes everything a lot better and easier on the eye to look at.
Windows Phone 7 Series
This isn’t related directly to Little Longhorn, but it might be in the future: )
At MIX10 Microsoft announced XNA 4.0 and Windows Phone 7 Series. XNA 4.0 will run on this new phone, which means that we can have Little Longhorn run on this pretty easy. It’s not in the scope for us to start targeting the new Windows Phone yet, but when we have a final running game on Silverlight and Xbox I’m pretty sure we will look into this device too.
Even though it’s not in the scope right now, I couldn’t help it and try to make Little Longhorn run on the WP7 emulator. I mean, when Microsoft is to kind to throw an CTP of the framework and tools at you, why not?
All in all, I think I spend around 30 min to 1 hour to make the game run on the device. Of course it didn’t work fully and didn’t fit to the screen etc. but still it was a nice feeling to be able to have the game up and running on the Windows Phone 7 Series (emulator) in XNA 4.0 within an hour.
And besides that, I’m just very excited about the Windows Phone 7 Series in general!
It’s Silverlight and XNA, can it get any better?
14 days iterations
As this is a hobby project and its something we do in our spare time, it can be hard to control and manage the project. What you want is to have control of the project and what everybody is doing, without having it to take up all your time. The typically problem for hobby projects like this is that people have many, if not all, roles in the project and therefore can’t spend a lot of time on “silly” things ;)
Up till now we have had this iteration concept we use to group issues in time. The problem have been that these iterations haven’t had a defined duration from the beginning, which makes it too easy for us just to kind of “push the deadline”. Again this is a hobby project, so we don’t want to push our self too hard, on the other hand, we have realized that we needed to do something if we wanted this game to be done before we lost the interest and excitement of the game.
What we try out now is to have iterations with a fixed duration of 14 days each. Today (4. April 2010) we are ending the second of these iterations and starting the third.
These last two, “14 days iterations”, have been highly productive and we have come a long way. I will try to publish a blog post on every iteration end/start from now on. I know I have to be careful with making promises like this, but I actually want to push my self to HAVE to do this, both for the readers of this blog and for myself.
Hope to see you again in 14 days for a new Little Longhorn blog post :)
– Enjoy!