Little Longhorn – Part 4 – A fresh start

It’s been awhile since I have posted anything about Little Longhorn, but this doesn’t mean that it’s put on hold. Actually the game is doing really well and we make a lot of progress. Let me give you the high lights.

Extra developer
We are now two developers on the game, which is really great as you can discuss things with another person who it 100% inside the code, just like my self. This is really great and makes the game come along even faster.

New code-base
As the new developer joined, we decided that we would start all over on the code, both so the new developer could be more into the new code, but also because I learned a lot doing the first version of the code. So it were time to start over and have a clean start, of cause with the knowledge of the first version in the back of my head.

Skipping the “Learning in public” 
As I said when I started this, “it might fail”, and it did :). Well, I can see now that the code very fast becomes too complex to describe to people en blog posts or in video’s, especially, when I don’t want to game to be all open-source. So as a result of this, I just skipped the “learning in public”-thing completely. The good thing about this, is that I can now use more time on actually coding on the game.
Instead I will give you smaller updates on the game, like this blog post.

Just wanted to let the people following this game have a little update on how it’s doing, and to sum it up, it’s doing fine – very fine!

– Enjoy!

Little Longhorn – Part 3 – Collision, Detection and Selection (Help needed)

As you might already know, I’m currently trying to get some of the basic stuff implemented for an “Tower defense”-genre (TD) game into Little Longhorn. I’m making progress, but have now run into a little problem. In this blog post I will try to explain which features that are coursing the trouble and hopefully, after I got some input/help from some of you guys out there, I can also post the solution for others to learn from and use.
Let me also make it clear that I’m not asking for complete code samples provided by one of you guys, I’m asking for a good dialog about this problem and different possible solutions for it. I will figure out the code myself, it’s the “thoughts behind” or what you want to call it I’m after here, some inspiration you could say. Hoping for some good input :)

WARNING: This post includes my own hand-made drawings! :)

Course of the problem(s)
Well, the main reason to this/these problems are that Little Longhorn is a little different than a normal TD. In normal TD games I see a lot of use of the mouse to interact with the game, Little Longhorn doesn’t use a mouse for anything. You are now thinking, “But how are you going to place towers, upgrade them etc?”. Instead of a mouse, you have an character you play in the game. This little guy is controlled by the arrow keys at the moment. This little player character will walk around, avoiding being hit by enemies, while he collect gold and build new towers, controlled by you of course. So you actually have to “walk” to where you want your tower and then build it there. It might sound weird to you, if you are use to play the standard online TD games, but believe me, this works and adds a hole different aspect to the game.
The above is what course the troubles I’m having here, but let me explain what I’m trying to archive and then you might see the problem.

The actual problem(s)
The following is what I need to have implemented in the game.

“Normal” collision
I need basic collision in the game. This is actually almost in place in the code and is actually working ok. My implementation is pretty similar to what Joel Neubeck describes in this article, I just have it all divided up in classes etc, but the basics are the same. This collision mechanism should be used to detect is the player is colliding with an enemy.

(Yes, I made this drawing myself :) Keep in mind that all graphics you see on screenshots, drawings etc, are all just “temp” graphics, so don’t get confused if an enemy looks like an alien in one image and a beetle in another one)


This is the most common collision (and maybe the mechanism that all the rest of the features can use? I’ll get back to that later). GameObject A intersect with GameObject B, and a “Collide()” method is called on both GameObject’s which they can act upon.

“Block” collision
At some point in the game, I need to be able to place objects that that player can’t go through, ex. a rock. This is essential the same collision as the “normal” one, I just can’t figure out how to implement it? All my “GameObjects” moves around using the normal “Vector/Velocity” approach (if you don’t know this approach Joel Neubeck describes this too in this article series). I have tried setting the Velocity equals to an “Zero” when the player hits a “rock” (actually i tried it on an enemy just for testing purpose), but it didn’t have the right effect :)


“Detection” of enemies
One of the basic features in a TD game, is the towers ability to detect enemies in a range and shoot at them. I have this implemented in the game right now actually, but it’s done by using the “normal” collision detection described above. This works “ok”, but is it the “right” way to do it? What I have done now is that I have given the towers a big “CollisionSphere”, which is actually a collision object, but act as a “range of sight” for the tower. Is this the right way to do it? I mean, at the moment, when the enemy is inside the towers “range” a collision is happening in every tick of the game. Is that wise or could this be done in another and better way?


“Selection” of elements
As stated earlier you don’t have a mouse in this game, all interaction is done through your player character. In the game you can only build towers on special elements that I (the level editor) put in there. This mean that when you want to build a tower to need to move your player character close to one of these “building” spots, hit “space” and a build-menu will show up. You choose the type of tower you want to build, and hit “space” again and your tower is build on that spot(this isn’t actually implemented in the game yet). The same approach is used when you want to delete or upgrade a tower. Move close to it and hit “space” and the options for this tower will appear.
The problem for me, at this point in time, is this “selection” mechanism. Basically, in my head that is, this is also a kind of “collision”, but at the same time it’s conceptually not, because nothing is actually colliding logically. 



Let’s sum it up
All the above can somehow to boiled down to being “collision” related. I just can’t figure out how I should implement these features. I have tried out different things but nothing seems to be “good”. In my mind all of the above should be able to be archived by using the same “intersection” algorithms that I use already and then adjust the behavior of the colliding objects properly, it’s just not that simple. I’m pretty empty on good idea for how to implement this, so all input are welcome. Please let me know if you need more information about something and I will gladly give it to you.

You can get the current source code of the game here. The game is not intended to be an open source game, but I have decided to share the code in this early stage, to give you guys the best possibility to help me out here. And then you can also see how I have build the game so far. Keep in mind that the source is very work-in-progress, which is why there are a lot stuff in there that isn’t used for anything.

Hope for great dialog and some good feedback/ideas.

Thanks in advance :)

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!