Finally done, here it is!

Do not be afraid to shake it up, shake it up, sha..

The entry can be downloaded from here:

Download

Watch capture (stream)
Watch capture (xvid)

Requirements:

.NET 3/3.5
XNA 2.0

up2date DirectX dll’s

Here’s some of the latest models:

In other news, I suck at composing music so I have made sure that people can turn it off in my game.

But here’s my main-menu:

The colored text at the top is bouncing up and down, and the model below is rotating to give a preview of the level.

<3

ArcBall rotation still isn’t working, and i’ve basically given up on trying to fix it. Below you can see what i’ve spent my morning doing.

• Gradient background
• Fonts
• Better shading for the main model
• Better shading for dirt
• Improved model for dirt specks

Had some troubles with math earlier, but that should be fixed now. Here’s a shot of a more complex model in action, where some blobs have been shaken off to the left.

There’s still one major issue with the ArcBall implementation (to rotate the model intuitively) which really needs to work before it’s playable.

Not much to show, but I guess that fits the theme perfectly. The reason is that I have spent all my time on coming up with an idea that
I didn’t hate.

What you’re seeing here is a 3d model infested with nasty stuff. It’s your job to shake these things off.

To abide by the rules I hereby deliver a link to my work-in-progress library; all it really does is provide a way of binding game behaviors to “entities”, and getting a hold of them again. Oh, and it’s written for .NET3.

Download

This theme was horrible to think up ideas for, I mean, games usually rely on the player expecting what happens. However, I did write a small platformer with just one level which tries to incorporate this idea of having something unexpected happen, so that the player then has to think up a way around.

I’m not sure i’ll continue working on it, as i’m not terribly excited about the game idea. Meh.

It requires .NET2.0, XNA 2.0, shader 1.1 and updated DirectX dll’s ( )

Try it here

Ever since playing the Commandos series i've been fascinated with the way they displayed the view of the enemies. They had this triangular shape which would get cut off when geometry was blocking the view. I thought this was a great way of showing how much, and where, an enemy can actually see. You can see what im talking about in the below picture (the red shape). 

I still don't know exactly how they created the effect back then. Well, obviously I have a few ideas, but i'll never know exactly how. Anyway, I wanted this effect for a game I was writing, and so I had to figure out a way to create it. Incidentally it turns out this effect could work great for shadows/light as well.

First Steps

So, getting down to business. First off it is necessary to create a rendertarget which will be used to draw the visibility triangle and every mask onto. This allows us to resolve the texture from the rendertarget and thereby having separated this part from the actual scene.

In order to achieve the wanted effect we will have to draw the visibility triangle prior to drawing the masks, as they will, quite literally, be used to cut off pieces of the visibility triangle.

Looking at the above image, you can see how every pixel that is white is considered to be part of the "masked area". So, we can now draw the mask geometry (shadows if you will) for every wall in the scene. By drawing the mask geometry in the defined mask-color, we can achieve the effect we're going for. See the following diagram.

The above image shows how a mask is created, and drawn, for every wall in the scene (colored black only for illustrational purposes).

Constructing The Mask

All the information we need to know is the Start and End points (P0 and P1 respectively) of the line segment (wall) and the position of the dude that the visibility triangle is attached to.

With these pieces of information we already know the positions for 2 vertices of the mask, and can calculate the remaining 2 by finding the direction towards P0 and P1 from our dude's position. With these directions handy, we simply move along them and stop at a fitting time. Doing this, we should now know all 4 vertices of our mask, and are now able to draw it ontop of the visibility triangle.

Then, once we have the texture containing the visibility triangle and the full mask, we can draw a fullscreen quad and apply the texture to it using the following simple pixelshader (note that this is not a complete .fx shader. It is only showing the important parts):

float4 MaskColor = {1, 1, 1, 1}; // white

Texture VisibilityMask;

sampler maskSampler = sampler_state
{
    Texture = <VisibilityMask>;

        ...
};

float4 PixelShaderFunction(VertexShaderOutput input) : COLOR0
{
    float4 color = tex2D(maskSampler, input.TexCoords);
 
    float4 finalColor = color;
   
    if (color == MaskColor) {
        // make this pixel completely transparent
        finalColor.a = 0;
    }
   
    return finalColor;   
} 

Finally

The pixelshader function makes sure that every masked pixel gets drawn completely transparent, thus giving the "cut-off" effect.

On the above image you can see how a scene would look with masks drawn (left), and how it should look after cutting out the full mask (right).

So, to sum up; every Draw call the following should happen - in this order:

1. Clear designated rendertarget to the mask color
2. Draw visibility triangle
3. Draw masks (in same color as the specified mask color)
4. Get texture from rendertarget and save it
5. ---
   
6. Clear standard rendertarget as usual
7. Draw scene
8. Draw fullscreen quad and apply the saved texture (using a pixelshader that sets every masked pixel's alpha value to 0 - making it completely transparent)

This postmortem covers my experience with the 10th Ludum Dare 48hour game competition, in which I won a Silver Pelly in the Technical category.

Summary

The theme for the competition ended up being 'Chain Reaction'. This wasn't really one of my favourites, in fact, it was amongst the themes that I wanted the least. I think my dislike towards the theme is pretty apparent in the final result, as it doesn't feature traditional "chain reactions" as seen in most of the entries. Taking that aside, the "game" (quotes because it's more of a toy) turned out pretty good I think.

As soon as I discovered the chosen theme I began the hunt for ideas, and just like most of the other entrants I tried hard to think in different directions than what had already been done (match3, boomshine). From the get-go I knew I wanted to do something in 3D, simply because I figured most entries (if not all) would be 2D. This was a silly decision, considering the gameplay I ended up with would have translated very well to a 2D setting, and would have saved me a bunch of time which could have been spent on polishing. But anyway, having it 3D allowed for a couple nifty little features.

It didn't take long for me to decide that I was going to use spring physics in some way or another. But knowing what a pain it is to implement and use springs, I knew the usage had to be something really simple. I honestly don't remember the idea I initially went for, but somewhere along the road, while implementing the physics, I discovered how fun it was to swing this snake-like structure around using the tail as a wrecking ball of sorts. With this discovery I figured I might as well do something with that.

There were lots of possibilities bundled with this discovery, like for example I could make it a fighting action game where you use your tail to bash down enemies, with possible chain customization included. Or, you could use your tail to collect stuff scattered around on the playing field. As said, lots of possibilities based around it simply being fun to control the motion of the tail.

I guess it's true that games are emergent.

Ultimately I ended up with a game about "snake-like creatures using their tails to bash a ball around a soccer field in hope of hitting the opponents goal" that had close to nothing to do with the initial idea. (Which I don't even recall what was by now - I guess it wasn't very good!)

What Went Right

I'm really happy about these, and they were really simple to implement!

I still find myself enjoying swinging them around, so these were a definite success.

The mouse control scheme is probably the one feeling most "right", and is quite easy to control, in my opinion. Same goes for the gamepad scheme.

What Went Wrong

This competition is generally not very friendly towards microsoftian technologies, thereby making distribution a living hell for anyone using them. I knew this beforehand, having participated before. I chose to use them regardless as I feel much more confident in the use of them which makes me able to produce stuff faster.

This was a bad decision, but I did not feel I had the time to figure out a decent AI solution for the enemy opponent. Even now there's no obvious solution that pops into my mind when thinking about it, so even though it was a crippling decision it was probably the right one.

Waste of time and effort. The springy goals are often not even noticed, and has zero impact on the game-play.

They suck. Nuff' said. Unfortunately, as far as I know, there's not really any way of having keyboard controls that feels right for this game.

Conclusion

It was a very good competition this time, and it went very well for me. I produced a whole lot of stuff during the competition, and ended up with a nice little multiplayer toy that I had some fun playing.

However, the game did not really make great use of the theme, and in a similar fashion did not present any new and awesome innovative game mechanics. Another downside is that I tend to end up with half-games; that is, games which lack polish (menus, game states, help screens/information) and are therefore basically just toys.

"Use the Tail, Luke!"

The outcome of these 48 hours is a reasonably decent game, that just barely stays within the theme. Taking that aside, I do think it’s good fun to play and that’s all that matters.

Hopefully at least a few people will be able to try it out, but since there is no single-player component it gets a little bit dull playing by yourself

The entry can downloaded from here:

Download Final! (src included)

Watch capture (stream)
Watch capture (xvid)

Added support for various control schemes, and prettied up the display:

A couple sounds are in also! Thanks DrPetter! (sfxr)

A few things have been implemented since last entry; most notably the springy goals. Well, only the back of the goals actually. They add nothing gameplay-wise, but they’re kinda fun to watch when a ball is hammered into them. Barrier advertisement textures have also been made, i’m not crazy about them but they’ll do for now.

What I really need to get started on are the controls. The gamepad controls are perfect, but the majority of people here does not have such a peripheral so keyboard/mouse support is essential. Keyboard is currently supported, but man, it feels quite crappy. I think pure mouse control would be better.

Since I woke up i’ve mostly been making graphical improvements, e.g. colored players, textured field barriers.. But I also implemented a better camera, so every moving thing should now be visible at all (most) times.

Later I will try to model a better looking goal, and possibly add a menu.

A bit progress here; it’s now possible to actually score! I took a really lousy approach to getting score displayed on the ground.. It’s a quad with texture coordinates, and then I have a texture for each number (i.e. 1, 2 and 3). Not very awesome performance wise, but meh.

So I kinda went back and forth between some ideas I had sketched out. They all involved the same mechanic though, so I was basically just figuring out which was more fun.

I came to realize that there’s simply too many possibilities with this setup. There could be major amounts of violence, I mean, just look at the spikes on those tails! But, I think i’ll simply make it into some kind of sports game, i.e. get the ball into your opponents goal, at least just for the compo entry. I will, however, be keeping the spiky tails.

Dinner will be had in approximately 30 seconds.

I woke up this morning discovering the horrific theme of Chain Reaction, I was pretty bummed that something like Evolution didn’t win and to be honest, I was doubting if I could come up with anything that wasn’t just another Boomshine clone. Well, I sketched around a bit and came up with some ideas that involved chains reacting to input

Originally I was gonna do some kind of “throw your rope and catch something” kind of game, but by tweaking spring properties I stumbled upon something that feels much better to play. You’ll play as some snake-like creature, and have to either kill enemies, or collect stuff by bashing your tail into them/it.

So this is a debug view of the current condition of the game. I prefer writing the gameplay mechanics before delving into doing the artsy fartsy stuff.

A class being dependant on another class is not uncommon. The dependency can be solved in a multitude of ways, but most common is passing references through the constructor.

However, when passing references through the constructor you are forcing yourself to consider the order of creating the objects – i.e. A has to be new’ed before B, if B is dependent on A. This was something I’d like to not have to worry about. Basically I wanted to be allowed being lazy.

First let me provide you with a little insight into the design of this application that is essentially an implementation of a component based system. (See: Mick West - “evolve your hierarchy”)

Everything revolves around Behaviors. These are exactly that by exposing very specific functionality. Next there’s the BehaviorGroups; behaviors are associated with groups, and thus groups make up a combination of different functionalities.

Often a behavior is dependent on another behavior, and this is exactly the problem I’m presenting a solution to in this post.

To mark a behavior type as a dependency for another behavior, you simply place the BehaviorDependency tag on a reference holder and it will be handled automatically. It reads like this:

  [BehaviorDependency]
  AnotherBehavior anotherBehavior; 

Likewise, you can specify dependencies across the system – i.e. behaviors that are associated with other groups.

  [BehaviorDependency(Group = “Another Group”)]
  AnotherBehavior anotherBehavior;

Essentially both of these blocks represent the same action:

• Search group for association with behavior type
  • Found
    • Inject reference to the object
  • Not Found
    • Instantiate behavior, associate it with the group and inject reference to the object

The behavior itself is responsible for searching and finding fields marked with the dependency attribute. This is handled in the base-class, though, so code-wise there is little involvement required.

A more contextual example:

  public class SomeBehavior : Behavior
  {
      [BehaviorDependency]
      AnotherBehavior anotherBehavior;

      public override void Initialize()
      {
          base.Initialize();

          // AnotherBehavior has now been associated with this behavior’s group, and
          // anotherBehavior has been injected with the reference to the newly created
          // object
      }
  }

A few problems do arise, however. The most prominent one being that when a behavior is marked as a dependency it is assumed that this particular behavior implements an empty constructor. This is due to the instantiation of the behavior under the circumstance that the behavior has not yet been associated with the group. A minor annoyance if kept in mind and you simply code around it. The problem could possibly be solved using some further attribute magic, though.

Secondly, the references will not be injected until Initialize(). This effectively rules out using the constructor for anything that involves the dependencies. Again, not a huge problem when kept in mind.

All in all, I much prefer having an automatic way of doing this – and come on, you can’t say it isn’t just a tiny bit pretty to read.

In lack of other things to write about, I present a progress report on the game I’m currently writing.

This is going to be a “stealth puzzle”, i.e. a stealth game with various puzzle elements. The idea is that you start in this building, and you have to plan/time your way through to reach the exit/goal without being spotted by the patrolling guards.

Currently the project has reached the point where a prototype of the primary mechanics is up and running. Next on the list is to create actual levels, and some proper models + textures.

I wouldn’t usually publish content as “rough” as this, but I figured it might provide enough incentive for me to keep working on it.

Here you can see a short play-through. I chose to shoot a video instead of handing out the executable, since it is generally unimpressive, and is nothing more than a show of the mechanics (this is not to be mistaken with actual game-play in this case).

A very user-unfriendly editor also exists; you can see a level being edited in the following screenshots:

Just for the hell of it..

This post will be the first of, hopefully, many postmortems on the games I prototype. I will focus on things that went wrong, and things that went right.

This game takes places entirely on a planet, and you, the player, have to either save or destroy the people roaming the surface from the evil asteroids that are on a direct crash course with the planet.

Inception

The idea for this game was kind of a forced result of my obsession spherical game worlds – i.e. games taking place entirely on/in a sphere. Since I had been messing with spheres for some time, I had a bunch of ideas in mind that I wanted to implement, quickly.

For actual game-play I thought it might be fun if the only interaction the player had with the game was controlling the rotation of the sphere. This way the player would be able to basically choose where the asteroids would land, at least until the amount of asteroids became larger at which point some prioritizing would have to happen.

What went right

I really think I nailed the theme with the small hills on the planet, the expanding shadows on the surface and the comical look that the building has to it. Imagine this with a classical tune looping in the background, and some horrifying screams from the people on the surface whenever they get crushed – I think it would be a perfect a fit.

Besides the visuals, I have learned a bunch about using a sphere as the game world. I seriously think there’s a ton of potential in such a world, at least, I have a bunch of ideas I want to try out sometime in the not-so distant future.

What went wrong

Starting out, I figured that the toy (the main game-play mechanic) would be simple to implement, and since it looked great on paper I did not give it any further thought that it might not be any fun in reality. Turned out it really wasn’t any fun.

The time I should have spent on re-thinking the toy was “wasted” on writing code that mapped a height-mapped terrain onto the planet surface, and some AI for the roaming dudes. These things were obviously both lovely things to have implemented; however, their loveliness was hidden due to the frustration of the actual game-play. It is hard to appreciate such things as a player, when the game is working against you.

Another game-play issue became apparent quite quickly during development; how to keep an overview of the situation as a player. This issue had actually been dealt with on paper by placing shadows on the surface of the planet as reference points for where the asteroids would hit.

This solution was great both visually and game-play wise. But, now imagine that asteroids keep spawning on the opposite side of the planet. You will never see these unless you navigate around using the camera. How could this issue be handled? Well, the carebear solution would be to simply not let anything spawn in places the player cannot see. This however, opens another set of issues – couldn’t the player just keep buildings/people somewhere out of sight? The whole game might become way too easy this way.

Conclusion

Ultimately, this process has been a good experience. I have gained a bunch of knowledge, and, most notably, learned the importance of developing on the core mechanics prior to, literally, ANYTHING else.

As a closing note, I’ll say that I remain confident that this idea could be successful given more creativity and time. For now, however, it’s time to do something else.

I have always been fascinated by contests such as Ludum Dare, it’s inspiring to be a part of something that is driven by fun, and the enjoyment of being productive. Really, contestants have nothing more to gain than fame and recognition - there are no fancy prizes.

I try to participate in events like this as often as possible, and I encourage anyone with an interest in game development to try and participate at least once. Simply because it’s a lot of fun, hard work and because I feel that you gain a big personal achievement every time. Also, you get to make programmer art without being frowned upon!

The rule set of the Ludum Dare contest is in essence very simple: Given 48 hours, write a game about, or involving, [insert theme]. This might not seem like much of a start, but it’s always amazing to see how much creativity is generated from something as simple as a one-worded theme description.

When being faced with such a short amount of time until the deadline there are a couple of golden rules that are good to keep in mind, but like all rules, they aren’t always easy to obey. They are:

• Get an idea and stick to it
• Spend your time wisely

Hopefully the chosen theme is enough to inspire you and help you establish an idea. However, while your inspiration is less likely to shift, your motivation is bound to face some large obstacles throughout the process.

You might find that your idea, which was fun on paper, is not so much fun in reality. Or, you might find that your lack of knowledge/lack of experience is keeping you from progressing, as you may have been too ambitious with your goal. When encountering a motivational obstacle, you have to make a choice, you might:

1. End the project
2. End the project by starting over with a fresh idea
3. Keep going by trying another path to the goal

Either choice you make will affect motivation negatively, but most notable is the 2nd which is a potentially dangerous choice to make. Depending on the time left until the deadline, you are making your goal much, much harder to reach and simultaneously lowering motivation. On the other hand, you might actually make it just because of this decision. Life is hard.

Successful or not, by participating you are sure to make yourself some good experiences and possibly discovering something worth building on in the future.

  Join the fun on December 14-16th 2007!