Little Longhorn – Part 2 – The hunt for an solid architecture

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:

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.


public class EnemyModel : BaseMob
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)

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.


public partial class EnemyView : UserControl
private EnemyModel model;
public EnemyView(EnemyModel model)
//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!