4. April 2010 by
Mads
Little Longhorn Part 7 code clean up and a lot of rewrite and refactor. Everything is XML - almost. SilverSprite changes. Windows Phone 7 Series.
[More]
1. December 2009 by
Mads
I will be doing a talk about the basis of game development in Silverlight 3 on the 16th of December 2009. Please note that the talk will be in danish! After my talk there will be an open discussion about the subject “Game development in Silverlight” . For more information and registration see : http://cnug-dec2009.eventbrite.com/ Hope to see you there. - Enjoy!
2. August 2009 by
Mads
I read this post by Bill Reiss the other day and found out about this marketplace thing that Xbox have. (I don't have an Xbox myself so didn't knew anything about the community actually. I have a PS3). After reading this, I got a little interested in XNA and thereby SilverSprite, as I can see potential in this new “Xbox Live Independent Games” thing. I haven't done any XNA or SilverSprite before, only knew very little about both. So, I decided to take a look at it as it might be interesting to do my current game in XNA and Silverlight. So I started to do a little research.
First I started by follow be beginning of this guide and eventually got Xna game studio 3.1 installed. Then I downloaded the latest changeset for SilverSprite (which supported silverlight 3), so I had the source for that on my pc. I created an default xna windows project 3.1, so I had something to try things on. The code that comes with this default project were pretty easy to understand and I quickly made a small "game" where a sprite were sliding around the screen and pressing the space button changed the background color. Pretty simple and easy. I got that working in Silverlight using SilverSprite pretty fast, so I thought I needed something a little more complex.
I saw that Xna Game Studio 3.1 comes with a starter kit “Platformer”, so I decided to give that a try. After about 4 hours I had a playable version of “Platformer” running in Silverlight and Windows with the exact same code base – wow! At first 4 hours might sound like much to you, but I needed to change stuff in the Platformer game code and in the SilverSprite core to make this work and if you keep in mind that I haven’t worked with either Xna or SilverSprite before, I think it pretty fast :)
Play You can try out the game here (Warning: It’s the same assets as in the XNA version, so the game is about 9 MB) : http://silverlight.laumania.net/platformer/
Source You can get the entire source from here: http://silverlight.laumania.net/platformer/platformer1.zip
Keep in mind that to be able to build the source, you need Xna Game Studio 3.1 and Silverlight 3 Tools installed.
To see all the things I have changed/implemented search for “laumania” in the entire solution. I have made minor comments. The SilverSprite version in this source, is a modified one as stated. I have submitted the changes as patches to the SilverSprite, so they will be in the original source too soon I guess.
My experience of using Xna and SilverSprite were actually really good and I decided to give my current project a try in Xna and SilverSprite :)
- Enjoy!
21. July 2009 by
Mads
The samples have been upgraded to Silverlight 3.0, which means that the source code is now targeted at the Silverlight 3.0 Tools for VS2008. Besides that the Farseer Physics Engine code have been upgraded to version 2.1.1.
Go and get the new release from Codeplex.com
- Enjoy!
16. July 2009 by
Mads
It's been a while I know, but there is a good explanation. After I posted the first post about Little Longhorn (Part 1) I discovered that I couldn't do both Balloon Mayhem and Little Longhorn at the same time. I knew I would end up with none of them getting finished. Therefore I desided to go all-in on Balloon Mayhem: http://laumania.net/post/Balloon-Mayhem-released-at-Silverarcadecom.aspx
With that game out of the way, at least it's marked as "done", so shouldn't take much of my time anymore, I can start working on Little Longhorn again, yiihaa :)
Changes to the "Learning in public" My original idea were to have a video screencast at each blogpost about the progress of this game. Sadly I can see now, that it takes to much time to plan, record, edit, render, encode and upload a video screencast for each blog entry about the game. Instead, I will try to do more smaller blogposts, without video screencasts. I'm not saying that there wouldn't be any more screencasts, I'm just saying that the amount will be smaller than first planned. So basically video screencasts will appear when they make good sense.
Architecture - To go MVC, or not to go MVC? As stated in my first post I have looked a lot on the WeAreBugs and Developing a Casual Game with Siverlight 2 - by Joel Neubeck to get inspired for how to build this game. They both heavy make use of the MVC pattern. I tryed making of prototype implementation and it seemed to work pretty good. For some reason I got some kind of an obsession to have ALL in my game to fit into the MVC pattern, which isn't a good idea of course. I just couldn't see it at the time. I got somehow obsessed with this pattern and had to have all my code to live by the MVC rules. I talked with colleagues, other devs over forums and MSN to figure wierd things out, untill I suddently talked to Cameron Albert. Basically he said to me that I should let the pattern be the solution to my problems, not a barrier. Actually I knew that, sometimes you can just be "blinded" while trying to resolve a problem, that you forget why you need to solve it. So, I started to think what I could and couldn't use from MVC.
I couldn't see the use of an "Controller" as the MVC pattern stated, so that were removed. What I could use were the relation between the "View" and the "Model". The View being a Silverlight UserControl (.xaml file), with out any "game logic" and the Model being a pure class with no visuals. The View knows about the Model, but the Model doesn't know anything about the View. Let me show some code as an example.
Please note that this code is altered from how it actually look sin the game, to make it easier to understand the View/Model relation.
EnemyModel.cs
public class EnemyModel : BaseMob
{
//Events
public event UpdatedHandler Updated;
private Route route;
public EnemyModel(Route routeToFollow)
{
route = routeToFollow;
}
public override void Update(int elapsedTime, Rectangle bounderies)
{
//Some code to actually follow the route
if (Updated != null)
Updated(this);
}
}
As you can see, the EnemyModel takes and "RouteToFollow" as an contructor parameter, guess what that's used for ;) - your right, thats the route (collection of points) that the enemy will follow. The important part is that there is no relation to a View of any kind. The way to Model tells the View to do something is by using events. As you can see, the Model fires the "Updated" event. In the View below you can see how the View respond to this.
EnemyView.xaml.cs
public partial class EnemyView : UserControl
{
private EnemyModel model;
public EnemyView(EnemyModel model)
{
InitializeComponent();
//Setup model
this.model = model;
//Hook up model events
this.model.Updated += new UpdatedHandler(model_Updated);
}
protected void model_Updated(object sender)
{
Canvas.SetLeft(this, model.Position.X);
Canvas.SetTop(this, model.Position.Y);
Canvas.SetZIndex(this, (int)model.Position.Y);
}
}
The View takes an EnemyModel as an contructor parameter and then hook up to the "Updated" event. When the event is fired, the View updates it's position based on the Position of the current Model.
This relationship I like, I can't say that it wouldn't change, but I like it for now, it solves my problems :)
What's next? I'm still trying to figure out the best way to build this game, but I have already learned that I can't do this by sitting and thinking, I need to code. You can think a lot of stuff through, but at some point you need to start coding, as you will then realize things you would never have thought about. So, my goal now is to get all the "basic" mechanisms for this game to work, in a as-good-as-possible-way, at this point in time. This is what I mean by, "solid architecture", I can build the rest of the game on.
The mechanisms I'm going to look into are as follows:
A good way to manage transition and swithing between different screens ingame (Splash, Menu, GamePlay, GameOver, Map etc)
Basic "Tower-Defense" elements. (Enemies, Towers, a Player, Projectiles)
I already have looked into them, but the implementations isn't good enough yet, here how the game looks at the moment:
If you have feedback, ideas or anything else, please post a comment - it's free :)
- Enjoy!