0h Game Jam

Two weeks ago took place the 0H Game Jam, in which everybody has to write a little game within the daylight saving time transition, an hour-long time frame which does not technically exist. This basically means building whatever one can in one hour or less!

Having taken a liking to small versus games on mobiles (I had a blast playing Bang with friends), I decided to have a crack at making such a game in a small time frame.
Behold, Versus Mini! A two-player, one-button shooting battle game made with Unity in just about an hour !

Here is a quick summary of the rules:

  • Each player controls his character  from one side of the screen.
  • The goal is to have your opponent collide with any wall.
  • Tap your side of the screen to shoot. Shooting makes you change direction, but also knocks you back slightly.
  • Being hit knocks you back a significant amount.
  • The speed of the game increases gradually until it reaches a maximum or one player dies.
  • When a player dies, his opponent earns a point, and the game moves to the next round.
  • There is no score limit (mostly due to time constraint). Feel free to set one as you play!

The .APK can be downloaded at this address. Naturally, since it is not Play Store certified, it will have to be installed manually through a file explorer.
Don’t forget to check out all the cool and sometimes crazy things people made in less than an hour!

Advertisements

Waiting For Players – Survival Horror With Friends

waitingforplayers

Waiting for Players (pending title) is a multiplayer survival horror game developed in 48 hours using the Unity engine. It was submitted as part as 2013’s Global Game Jam Humberside, and earned first prize.

Our team was composed of Louis Deane, Daniel Endersby, Ryan Hollands, Duncan Mulholland, Don Holland, Jack Wood and myself. That’s a lot of Hollands.

Players are thrown into what appears to be a dark mansion. One of them becomes an invisible presence, tasked with eliminating the other players. To do so, the presence must maintain eye contact with the survivors until they faint. The game stops when all survivors are dead, or when the last person alive makes his/her escape.

  • The survivors, on the other hand, posess the ability to sense the presence’s heartbeat. The louder, the closer. The speed of the beats can also indicate the pace of the ghost’s movement. A very slow beat will indicate that the presence is sitting idle, waiting for prey. On the other hand, it will most certainly be running if the heartbeat is fast paced.
  • The survivor’s vision becomes increasingly twisted the more their health diminishes.
  • When the presence is staring at a survivor, a screeching music is played, alarming the survivor of the threat without revealing its position.
  • Several other cues can be used by the survivors to locate the presence, such as decorations falling when the presence brushes past them.
  • A ball of light is located somewhere within the mansion. It sticks to any surface it is being thrown at, and allows the carrier to slow down and reveal the presence.

The last two features, although implemented in a local version of the game, were not implemented for network play due to time constraints.

Also, "Yaaay we won!"
Also, “Yaaay we won!”

Ultimate Garbage Team Space Sheriffs

UGTSS3

Footage of the game can be found here.

This particularly long title stands for a game I developed in my first year for the Imagine Cup.

The game is a side-scrolling shooter featuring a combo mechanic and some mild RPG elements. The player controls a flying recycle bit, exhibiting a proud mustache. Various enemy types will storm from the right, and the player will have to destroy them. When an enemy gets blown into smithereens, it may drop some garbage which the player needs to properly recycle.

The twist is, the player actually controls three separate bins (although just one at once), each with its own unique type of shots. The keys QWE allow to dynamically switch bit and shoot with it.

Collecting garbage with the appropriate type of bin will increase the bin’s experience level, as well as the combo meter. When the experience bar is full, the bin levels up, and its shots become more powerful and varied.

If a bin ever gets hit by enemy fire, it will be incapacitated for a certain period of time, and the combo meter is reset. There is no game over, but this holds an impact on the final score.

At the end of the game, the player gets issued badges for his achievements, based on his score and damage received. One objective of the game is to obtain all badges for all levels.

Main Menu Save Screendamage+ weaponupgrade cheese

Three Thing Game: It’s on. In 12 hours.

And we have virtually nothing running! How awesome is that?

Image

I think we’ve gone pretty ambitious, at least a lot more than the previous times. There will be blood, monogame, networking, kinect and windows phone. I’m kidding, but just about the blood.

To be frank, I really do not know where this is going. We have a very solid idea of what we need to do, how the game should look and play, but now it remains to be seen if it is possible to cram basically everything in a fortnight.

If we do pull it off, it will be awesome.

Three Thing Game: It’s on. Sort of.

Are you sick of Three Thing Game posts? Well, tough! Here’s another one.

Our words are Goldfish, Plug Hole, Invasion.

Image

We are planning on making the game directly using Windows 8 VMs and Monogame. In such a short time span, ’tis a recipe for disaster if you ask me. But hey, it’s not like we have anything to lose, right? So far, only some art and some networking has been done. My partner will also be missing for part of the competition.

In all honesty, we went for something both idiotic and risky, because hard to make. Let’s hope we at least make the cut to the finals!

Three Thing Game: Ticks & Trips

Another wall of text!

Who does not enjoy winning things? I cannot say I was not satisfied when our team won the last Three Thing Game. But winning a competition which only spans on the duration of student life does leave a bitter taste in the mouth. Since this is the last year for us MEng students, it will also mark their last year taking part in the Three Thing Game. Some other teams who have been taking part since their foundation year were quite unhappy about us winning three times in a row, which is easy to understand.

Here are a few tips from what I gathered throughout the competitions that I hope will prove helpful. Make sure you also check Rob Miles’ blog, for other useful infos. I know he wrote a post with tips and tricks, but I just cannot find it… If anyone finds it, please give the link in the comments, and I will update this section. Speaking of comments, feel free to disagree, this is purely advice, and I’d gladly stand corrected.

Yes, indeed.
“Thou shalt not make a platformer.”

Take time to think.

I often see teams coming up with a concept in less than a day. This is mind-boggling, as everything a team will subsequently do revolves around that core concept. Getting the concept right should be something you spend time on. With a good concept, you will also thouroughly enjoy the competition! Taking time to think goes hand in hand with the next point:

Be evil with your ideas.

Be awful with them, as if you were a member of an elitict jury just waiting to tear them apart, like the Dragons on the BBC. When something comes as ‘The Best Idea Ever’, it might be a good idea to twist it, twirl it, and examine it first. Be a perfectionist. If something does not smell right (and there are many reasons for something not to smell right, as there are many more constraints in the TTG – see below) either drop it, or alter it in a way that remains meaningful to what the game is set to achieve. If you have an idea of a game that works and fits fine on very first hour, you are either a genius, or the idea will need refining. You’d be surprised how different (and potentially better) a game comes out when you had time to think hard. This difference needs to pop out at the design phase, and not at the implementation. The truth is, when you are starting to program, you must feel confident and have a clear picture of the game in your mind.

Do not be over-ambitious.

There is only a week. Think in terms of time, and how long making the game would take. Make sure programming the basics of the gameplay won’t take all of your time. This will give you some breathing space, and you will be glad to have some breathing time, which you can use in polishing the game.

Keep the art simple but coherent!

The game does not have to be pretty. It can, but it does not require very detailed/well drawn graphics to please the eye. However, what can make a game visually irritating is the inconsistency of its graphics. Like having an ugly texture in a very pretty game for instance, or using different graphical styles which don’t fit together. This usually happens when more than one person is working with the graphics, or when temporary art is left in because ‘it doesn’t look that bad’.

Mind the polish (I heard they are dangerous people).

Joke aside, and although it may seem like an afterthought, polish is extremely important. When speaking about the topic of polish, the phrase “You cannot polish a turd!” usually ends up being mentioned. While I agree with the principle, its opposite is, to me slightly different. A game with brilliant mechanics can be considerably less fun when it is rough around the edges. Take some time during development to refine the points that stick out, or the interactions the player execute the most. The key is to find which parts of your game are relevant to polish, and which ones would just be a waste of precious time. 

(Brace yourselves, here’s a pompous bit):

One key aspect of polish is feedback to the player. Feedback, in a way, is the way of the game to tell the player that his/her actions have a meaning. Lack of feedback is often the biggest lack of polish. As Ralph Koster puts it in his Theory of Fun, what makes a game fun is the assimilation of the patterns of its mechanics. It is learning. A very predictable pattern which is easily learned makes for a boring game, while a complex pattern leads to a challenging game. But challenging can still be boring right? The question is how? A hard game becomes boring when it stops giving cues for improvement, or when you just don’t get them. It is when you just cannot be asked to identify its patterns. By adding effects, such as simple particles when an enemy dies instead of just making it dissapear, you will show the player the result of his/her actions, and encouraging the learning of the pattern. Feedback directs the learning process.

Make a small, but complete package.

As Rob Miles quite often points out, a game needs a starting point and an ending point. It does not necessarily mean “A main menu with several options and an ending to the story”. What it does mean however is: “When I stop playing, I must feel that I accomplished something”. In other words, I should not feel like I am stagnating. When player control is removed (death, win), things like a win sound or message, or even a change in the character’s behaviour (in Pocket Starlight, when the boy got too close to the darkness, he would start falling down as a game over sign) can express progression feedback and help the game feel more complete. The easiest way to make a game feel complete is to introduce a simple, straightforward goal (which self-provides the progression feedback to the player).

You do not need multiple levels to make a point.

Another important point is that the game should not necessarily have multiple levels. Multiple levels will likely require a level editor, and the time spent building it could very well be spend on making other things. The word game stands for something that can be played and enjoyed, but it does not necessarily require a full suite of levels. If it is immediately shippable and sellable, good for you, but if you can get the point of the game across in one, well realised level, it would be well enough. Even better, find a design that does not necessarily require levels (multiplayer? survival?…).

Integrate the words.

You WILL get silly words. Everyone does. Everyone. The key in getting a game that fits with the theme is… well… to have the theme fit. Many people (including my team) have a more or less precise idea of what game they’d like to make. And when the words are attributed, this idea needs to change. Tacking on the words is not the solution. They must fit not only with the graphics, but with the context and the gameplay. Keeping the same game concept will only get you as far as a game with three things taped on it. Which is why you will absolutely need to go creative with the words. Being litteral isn’t always the best solution. (And I’ve heard that Nicholas Cage will be in the next word selection. Hope no one’s gonna be litteral with that one.)

Sometimes tacking on the words gives a wacky, zany result… And most of the time, to the point of mental indigestion. The game can be crazy or weird, but it still needs to make sense, to have a common ground on which the zaniness can stand on.

To conclude. DO. NOT. MAKE A PLATFORMER.

Choosing to make a platformer summarises most of the issues covered up there. They are harder to make than they look, they feel unoriginal in terms of the words (and making an original platformer gameplay would be even more time consuming), they often require levels, polishing them is a lot harder.

Only try going for a platformer if you are ABSOLUTELY SURE of what you are doing and how much time it will take to build.

And most of all, have fun, eat pizza, and wear a silly hat!

Because pizza comes best with silly hats.

Three Thing Game: And now, the Obligatory Retrospective.

I was thinking of making a Three Thing Game Retrospective post, about the TTG of March 2012. In fact, I have been writing and rewriting it for months (with a whooping 18 revisions), as I was dreading us being hated even more (that is Rob Marshall and me). Since the next TTG is getting close fast, I figured it would be a good time to finally post the draft. Here it is then.

Well, here we are, the Three Thing Game is once again over. And something happened too…

Oh, glee! We won again.

I figured I would do like all the other bloggers out there and tell the tale of how the whole thing went.

THE AUCTION AND THE IDEA

A few thoughs about the original game idea.

Since the words were going to be in a bid, my initial thoughts were that we could come up with a vague game concept before receiving the words themselves. That is, just a game concept. If we had some really mismatched words, we’d have to find something else. One thing NOT to do is building the words around the game. Since the PSVita had analog sticks on both sides, the idea was to take it sideways, and use it as a cooperative game. For once, I wanted to make something different, that would appeal to more than the shootey-stuffey satisfaction. If there was a word I desired most, it would have been ‘love’ or ‘union’, as I really wanted to capitalize on the relation between the two characters on screen, and having their interactions being meaningful. This is mostly when the ideas for a ‘life-regenerating hug’, and the ‘the closer, the stronger’ came into play. Though these mechanics were being thought as part of a cooperative game, they are still part of the final product.

Rob and I also came up with an interesting concept of betrayal. Players would originally share a heart-shaped life bar, which would split into two separate life bars at the moment of betrayal. The player killing the other would gain some bonus mutiplier for his final score, but it would make things harder, of course, since he/she is now alone.

…And then came the word auction. We failed at most of our bids, which resulted in the words being

… BOY, CONTRAPTION, HIGH JUMP

 Which, in all honesty, was not that bad, although it clashed with all of the ideas we had for the project. So we decided to alter what we had in mind to base the game on the words. The coop game became a twin-stick solo game, where a ‘link’ between two characters would help destroy enemies. We focused our attention on the backstory and making the game feel organic, mostly by establishing links between the words and the game that were more than dimensional. For instance, we brought forward the concept of the contraption, by imagining a stick which essentially absorbs starlight and creates the link between the two characters. A boy finds this contraption, which sends him flying into the sky with his teddy bear to rid the sky of a swollen darkness that ate the stars.

And there we had the Pocket Starlight. (In retrospect, it looks awfully like that mirror from Ocarina of Time)

Most of the work during the week was spent porting our game libraries to the Playstation Suite. Since basic classes such as Rectangle were not included, and drawing had to be done with vertex buffers, there was much  that had to be made (and remade). When we came in to the final push, we had the two characters moving on screen.

THE FINAL PUSH

As everyone knows, the week-end is mostly spend on working overnight make the game. And the whole thing just feels like a blur to me now. A blur full of C#, shortcake, pizza and foam darts.

All I can say, from what I remember, is that it went flawlessly. No SVN problems (thanks a bunch Rob -Miles- and Rob -Marshall- for both setting it up in your own rights), and no bloody computer failure at 1 in the morning! For those who did not know, I had to cope with having no working Visual Studio last time, as it decided to BSOD my laptop when updating to SP1. Fun times.

Fenner labs was actually a whole lot more enjoyable than I expected. See, before the event, I was dreading how being in Fenner would feel “like I’m still doing that Neural Nets coursework”. Thankfully, the overall cheerfulness of people really made up for it. Fenner also allows to express the full potential of the long-ranged motorized Nerf gun. I apologize to the people 40 feet further. I made it rain. Lindsay, I do not apologize. You shot me in the privates.

Then, there was the point where I got tired. There are two stages to me being tired. Stage #1 is me running around like a madman and being generally overly energetic and happy. Stage #2 is the absolute opposite. I am stressed and angry, and I start shouting at things. I am sorry I shouted at you Rob Marshall!

THE REVEAL

Personally, our victory was a surprise for me, as I found the whole reveal to be quite funny. First, the finalists were selected and got the occasion to showcase their game in front of a large audience, comprised of the other teams and a jury (including a guest from Sony Liverpool!).  Being part of the finalists, I knew we somehow stood a chance. But in my mind, there wasn’t a possibility of them letting us win for a third time. I tried to take on the audience during the demonstration, and ended screwing up on several occasions due to the deadly combination of stress, tiredness and energy drinkness. Then, it became increasingly clear in the countdown. When at each spot we heard the name of the team that was not ours, we had that doubt increasing in our heads. Is this possible? Did they make us win again? Well, turns out they did. And it is under a sea of (friendly?) boos that we went on stage and collect our prize, a dedicated poster of Wipeout 2048.

I am preparing another post where I will get together a couple of pieces of advice acquired through personal experience. I hope it will prove useful to some first timers!

It Slices! It Dices!

I am a fruit ninja addict. Any time I am given the opportunity to play the game, I will spend more than an hour hogging whoever’s phone or tablet. Yes, I do not even own my own copy.

Yesterday, in a somehow miraculous surge of productivity, I decided I would try to replicate the slicing mechanics in one of my existing 2D games. And, well, it’s time to share the results with the internet, of course!

Whatcha know about texture slicin’, hater?

First of all, I need to clarify. This is 2D, texture based cutting, done using the existing 2D architecture from XNA (Spritebatch, Texture2D, and whatnot). This means no vertex buffers, no shaders and thus no vertex displacement. Cutting by adding vertices and splitting models based on these points is a lot more efficient than the method I am about to show, as it gives all the hard work to the graphics card. However, if you are limited to the 2D XNA framework, you might want to consider the following approach.

Now that this is out the way, let’s do this *crow noise*!

What do we want to do?

Let’s get the problem down first. We would like to be able to slice an object in two. This means that we should feed in a single texture into our method, and obtain two at the end.

public static void SliceTextureLine(Texture2D input,
            out Texture2D output1, out Texture2D output2)
        {
            //Save orphans and puppies from burning buildings.
            //Also, slice a texture in two.
        }

What about the line?

As we are talking about slicing, we should assume that what we want is a straight line going through a texture. The question is, how should we represent line coordinates? What is the lowest level of representing a straight line? We could use two points, but why not use its basic mathematical equation?

Line equation: f(x) : y = ax + b, where a is the gradient and b the intercept.

This means we will need a gradient and an intercept to represent the line. Using two points would eventually boil down to finding the coefficient, which means it’s not lower level enough to be in the scope of the method!

public static void SliceTextureLine(Texture2D input,
            float gradient, float intercept,
            out Texture2D output1, out Texture2D output2)
        {
            //Save orphans and puppies from burning buildings.
            //Also, slice a texture in two.
        }

A note about method scope:

We need to keep in mind that staying within the method scope is essential. Therefore, we should input the line coordinates according to texture space, and not according to world space, as converting from world space to texture space should not be the method’s business.

We need to consider two types of coordinates:

  • Use standard texture coordinates (ie (10, 20) in a 100×100 texture).
  • Use relative texture coordinates (ie (0.1, 0.2) in a 100×100 -or any- texture).

It all depends on how you would like to implement it within the program. Relative texture coordinates are better for encapsulation, but require more calculations on your part. I will use standard coordinates for this example.

Texture data as one-dimensional Color arrays

To slice the input texture into two output textures, we need to fiddle with what’s inside it, which is an array of colours.

We need to obtain colour data from the texture in the form of a one-dimensional Color array, and create two one-dimensional Color arrays to store the texture data for the outputs. Let’s first store the data for the input texture:

Color[] incolors = new Color[input.Width * input.Height];
input.GetData<Color>(incolors);

The principle is to cycle through the input texture data, and set each pixel to its respective slice. For this, we will need a nice nested for loop.

for (int x = 0; x < input.Width; ++x)
                for (int y = 0; y < input.Height; ++y)
                {
                    //Declare world peace.
                    //Also, store incolor into either outcolor1 or outcolor2.
                }

Now, let’s declare the output textures and arrays.

output1 = new Texture2D(device, input.Width, input.Height, false, SurfaceFormat.Color);
            output2 = new Texture2D(device, input.Width, input.Height, false, SurfaceFormat.Color);
            Color[] outcolors1 = new Color[input.Width * input.Height];
            Color[] outcolors2 = new Color[input.Width * input.Height];

Why are we using the same texture size?

In the code above, you might notice that both the output textures have the same size.

Why is this? Isn’t there a better way of doing this? Well, yes there is. The reason why we set the size of the output textures to the size of the input is simply because we do not know the size of the outputs before they are themselves determined.

The most efficient method would be to calculate the two intersection points between the line and the texture rectangle, and using them to determine the size of each output array. However,  this requires quite a huge chunk of code, and a separate method for segment intersections. For the sake of simplicity, the output textures will be kept the same size as the input texture.

Replacing colours

As both output textures are the same size, each pixel will need to be added to both of them, one being transparent, and the other being the original. The original pixel will figure in the correct part of the cut, while the transparent one will replace the original in the other part of the cut. It is pretty simple if put in an image!

This means we will need to set up an empty Color:

Color empty = new Color(0, 0, 0, 0);

Finally, the slicing

How do we separate each side? Thanks to the equation of our line, we can use it to compare if a pixel is higher or lower than the slice.
y > Gradient * x + Intercept would then mean that the pixel [x,y] is above the slice line!

We just need to add this to our for loop:

index = x + y * input.Width;
                    if (y > x * gradient + intercept)
                    {
                        outcolors1[index] = incolors[index];
                        outcolors2[index] = empty;
                    }
                    else
                    {
                        outcolors1[index] = empty;
                        outcolors2[index] = incolors[index];
                    }

And there we go!

The final code should look something like this:

public static bool SliceTexture(GraphicsDevice device, Texture2D input,
            float gradient, float intercept,
            out Texture2D output1, out Texture2D output2)
        {
            Color[] incolors = new Color[input.Width * input.Height];
            input.GetData<Color>(incolors);

            output1 = new Texture2D(device, input.Width, input.Height, false, SurfaceFormat.Color);
            output2 = new Texture2D(device, input.Width, input.Height, false, SurfaceFormat.Color);
            Color[] outcolors1 = new Color[input.Width * input.Height];
            Color[] outcolors2 = new Color[input.Width * input.Height];

            int index = 0;
            Color empty = new Color(0, 0, 0, 0);

            for (int x = 0; x < input.Width; ++x)
                for (int y = 0; y < input.Height; ++y)
                {
                    index = x + y * input.Width;
                    if (y > x * gradient + intercept)
                    {
                        outcolors1[index] = incolors[index];
                        outcolors2[index] = empty;
                    }
                    else
                    {
                        outcolors1[index] = empty;
                        outcolors2[index] = incolors[index];
                    }
                }

            output1.SetData<Color>(outcolors1);
            output2.SetData<Color>(outcolors2);
            return true;
        }

What is there left to do?

Remember that the input to this method is relative to the texture itself, so you will need to take into account all the transformations of your sprite. Here is a small example program I made to test the algorithm, where you get to slice famous internet brawler Kimbo Slice. You can download it here.

It works!