PAGES

Archives

Author: Renaud Bédard

Updated 15/06/2012!
See bottom of the post for updated download links.

Diluvium is a game I made with Aliceffekt, Henk Boom and Dom2D as Les Collégiennes over the course of TOJam The Sevening, a 48h game jam (though we had a ~8h headstart on that) which took place between May 11th and 13th 2012.

Gameplay

Diluvium is a versus typing tactics game.
There are two summoners on the battlefield, and you are one of them. Type animal names to summon them, and they will attack the enemy’s spawns and ultimately the enemy summoner himself. The first to kill the other one wins, as these things usually are.

You can type up to three animal names in a row, which spawns a totem of these three animals. Each animal has its own stats : speed, attack power, health and intelligence. The totem is as intelligent as its most intelligent member, and health is summed up, but movement speed is averaged.

If someone spawns a dog on the playfield, nobody can spawn another dog until it dies. No duplicate animal! Thankfully you have 284 animal names to choose from, 100 of which are illustrated differently.

The game has a half-assed single-player mode that you can access by typing “LOCAL” in the connection screen. Otherwise, the game should work fine in LAN and over the Internet, as long as you open up the server’s port 10000 (I’m not sure whether Unity networking uses TCP or UDP, so go for both). The connection screen lets you know your LAN and WAN IPs as you host the game.

Things you can also enter at the connection prompt : “MUTE” to kill the music, “IDDQD” for degreelessness mode, and one other secret code which will be revealed elsewhere on the interwebs!

This was the second network multiplayer game I’ve worked on that uses actual Unity networking instead of a hacked up UDP sender/receiver pair. It’s SO MUCH EASIER TO SET UP! And it works consistently, no threading bugs and random Unity crashes. Knowing this makes me much more comfortable in attempting more network-multiplayer games in jams. The Cloud Is A Lie was a nightmare to keep synchronized, it would’ve been so much easier with the built-in stuff.

We had sort of an Montréal Indie Superstar version of Les Collégiennes this time at TOJam, with FRACT‘s Henk with me on code and Dom2D as an animal portraits factory for the whole weekend. Aliceffekt and Dom’s visual styles merged really well, and having all this extra super talented manpower allowed us to create a much more ambitious game. Henk happened to have working pathfinding classes just lying around, and his deeper knowledge of Unity intricacies meant less time spent fighting bugs and oddities. It was such a great jam! ^_^

Updates

Version 1.1 – 15/06/2012

Server Naming : You can now name your games and tell your friend to connect to it by name instead of IP! (IP still works, though)

Anonymatching : Create a server and wait for a user, or join an anonymous server randomly!

NAT Punchthrough : Server no longer needs to forward port 10000

Adaptative AI : In local mode, AI opponent spawns more/less units per second depending on wins/losses

I re-did my slides and my talk at the Independent Games Summit of the GDC 2012. It grew from a measly 42 slides to a healthy 62, so there is more content, many more videos, and incorporates some of the feedback I had about the MIGS version.
Update : it’s on the GDC Vault, (no membership required!) if you want to see me give the presentation.

Coroutines are a great idea and super useful, but they’re kind of unwieldy to use in C# and sometimes they just don’t plain work. Or I don’t know how to use them properly. All I know is that they’re more complicated than they need to be, and I remember having problems using them from an Update method.

So I made my own version of Coroutines inspired by the XNA WaitUntil stuff I posted about a long time ago. Here it is!

You call Wait.Until as a static method and pass it one or two methods (be it lambdas or method references) : The first one is the Condition which gets evaluated every Update until it returns true, and the second gets evaluated when the condition is true (it’s a shorthand, basically)

The Wait static class instantiates a “Waiter” game object and hooks a custom script component to it that does the updating and checking stuff

The condition gets passed the number of seconds elapsed since the component was created, so you don’t have to keep track of it separately.

I use it for waiting for amounts of time (Wait.Until(elapsed => elapsed > 2, () => { /* Something */ })), interpolate values and do smooth transitions (like the code example above, I animate the player’s arm with it), etc.

I’ll probably keep updating my component as I need more things out of it, but up to now it’s served me well. Hope it helps you too!

Volkenessen is a game I made with Aliceffekt as Les Collégiennes on January 27-29 2012 as part of the 48h Global Game Jam. We actually slept and took the time to eat away from our computer, so based on my estimate we spent at most 30 hours making it!

It’s a two-player, physics-based 2D fighting game. Each player starts with 9 random attached items on his back, and the goal is to strip the other player of his items by beating the crap out of him. When items are removed, they clutter up the playing area, making it even more cahotic and hilarious. The washing machine and sink in the background can also fall and bounce around!

Controls

You need two gamepads (so far the Xbox wired, wireless and a Logitech generic gamepad have been tested and work [you can use the Tattiebogle driver to hook up an Xbox controller to a mac]) to play, there are no keyboard control fallback (yet). The controls are pretty exotic. To move around you can press either the D-Pad (or left analog stick) or the face buttons (A/B/X/Y), and the direction of the button does the same input as if you pressed that D-Pad direction. As you move, your player will throw a punch, kick or flail his ears to make you move as a result.

To hit the other player, you need to get close to him by hitting away from him, then hit him by moving away from him. Ramming into the opponent just doesn’t do it, you need to throw punches, and depending on the impact velocity, even that might not be enough. You can throw double-punches to make sure you land a solid hit and take off an item.

Development

It was made in Unity, with me on C# script and Aliceffekt on every asset including music and sound effects. I see it as one of our most successful jam games; it even won the judge award at our local GGJ space, and it was just so much fun to make, test and play.

I was surprised how well the rigid body physics worked out in the game. I had to use continuous physics on the players and tweak the gravity/mass to get the quick & reactive feel we wanted, but the game was basically playable 6 hours in! After that it was all tweaking the controls, adding visual feedback, determining the endgame condition and coerce the GGJ theme around the game.

I’ll be porting the game to the Arcade Royale in the coming days/weeks, and it should be a blast to play on a real arcade machine :)

Back in November 2011, I gave a talk at the Montréal International Game Summit in the Technology track called “Cubes All The Way Down”, where I talked about how FEZ was built, what’s the big modules, the challenges and intricacies of making a tech-heavy indie game from scratch.

It went okay.
I was really stressed, a bit unprepared due to FEZ crunch time, and just generally uncomfortable speaking in front of an audience.
I spoke so fast that I finished 15 minutes early and had 30 minutes for questions, which worked great for me because the relaxed setting of a Q&A session meant better flow, better information delivery, I really liked that part. Also I had friends in the front row that kept asking good questions and were generally supportive, so all in all a good experience. :)

So, imagine you’re writing a shader instancing shader (sounds redundant, but that’s actually what they are) and you’re trying to pack a lot of data into a float4 or a float4x4 in order to maximize the amount of instances you can render in a single draw call.

My instances had many boolean flags that changed per-instance and that defined how they were lit or rendered. Things like whether or not they are fullbright (100% emissive), texture transform flags (repeating on x or y, more efficient to rebuild the texture matrix than pass it), etc.
Using one float out of your instance data matrix for each boolean is doable, but highly wasteful. A natural way to fit in many flags into an integer is to use a bitfield, but there’s no integer arithmetic in HLSL, and they’re floating point values… how does one proceed?

Here’s how I did it.

Application side

First, this is how I pack my data into floats from the application side (setting the effect parameter) :

Just putting an OR operator between the flags you wanna put, and keep the flag bits powers of two.
Ignore the rest of the matrix contents, they’re just here for show. (in my case : position, rotation, scale, color, opacity, animation frame and the flag collection).

A note on floating point : in a single-precision floating point number as defined by the IEEE, you’ve got 23 bits for the significand. That means you can theoretically put 23 flags in there! That’s a lot of data.
(also, considering the decimal point is floating, you can effectively put much more than 23 bits if some of them are mutually exclusive…!)

Vertex shader

Now in the vertex shader, they get passed to an effect parameter through vertex shader constants, and here’s now the decoding works :

I know my flags reside in the 3rd row, 4th column of my matrix, so I grab ’em from that. Might as well cast them to an integer right now since I won’t be using decimals.

Then I can test for values by testing the remainder of the division of each power-of-two. There is no integer modulo intrinsic function in HLSL for Shader Models 3 and lesser, but the floating-point version works fine.

If I set the first (least significant) bit of a number and divide it by two, the remainder will be 1 if that bit is set. Basically, we test if that number is odd or even; odd means the bit is set.

For every other test, we can test whether the remainder is greater or equal to half the divisor. Effectively, we’re masking the bits greater than the one we’re testing, and testing remaining bits for the presence of the one we’re looking for. Here, if we test for the 3rd bit (from the LSB), so masking with 8 (1000 in binary) and testing against 4 (0100 in binary) :

Even though the game’s been out for a long while and even has an official page, I’ve never made a post about it, and now that we’ve been elected #3 Free Indie Game of 2010 on Bytejacker (!!!), now seems like a good time to spread the word!

Multiplayer underwater mayhem!

We originally made the game for Gamma IV earlier this year, and released a Windows version when the competition ended, but recently we went back and finished up the Mac and Linux versions. It’s great that porting the game didn’t involve touching any of the game code (which is in Lua, and MIT-licensed).

So whatever platform you’re running on, try the game out! It’s great fun in multiplayer, and the learning curve is almost inexistent.

How to play

You can place Projectors that redirect cells or combine them, if different cells hit the projector simultaneously.

The challenge is to combine colors at the right time, with the given resources and world layout. It becomes an intricate resource management/puzzle game, and even the simplest-looking puzzle can prove almost impossible!

There is only 13 levels in this version, which was made for a party setting. The difficulty curve proved to be very harsh for new players, and even seasoned players (like me) can’t reach the end. It’s a hard game — Aliceffekt’s trademark game design. ^_^

Science! (shot by Aliceffekt at the Prince of Arcade)

It is played with mouse+keyboard on all platforms, but also supports the Xbox 360 gamepad (either wired or wireless with an USB receiver) on Windows by using Rémi Gillig’s XInput.NET for Unity. I made my own wrapper over it to detect press/hold/down, actually the code was ripped out of my XNA code. That’s the fun part of using C# scripting, I can just share code between projects even if it’s not the same technology!

Controls

If you’re too lazy to read the tutorials :

Right click and drag to rotate the camera round the world, scrollwheel to zoom in/out

Left click to create a Projector, and left click on a face to select its direction

Z to undo the last Projector (or hover any Projector and hit Z to undo that one)

R to restart the level

Escape to return to the first Level

ALT+F4 or Command+Q to quit

Hope you like it, it was a a lot of fun to make and I’m already looking forward to my next Unity creation… It’s a great work environment.

The Cloud is a Lie is a game that me and Aliceffekt (our team name was “Les Collégiennes”) made at a 36-hour gamejam/competition in Québec City called Bivouac Urbain. (Last year I also attended the event, and made Stimergy with Heather Kelley).

Download

Controls

WASD or Arrows keys move. (you need to hold them)
Spacebar shoots.
M toggles the music.
Escape quits. (there may be a 2-5 seconds pause when quitting the game on Windows)

Gameplay

The Cloud is a Lie is a LAN multiplayer game for any number of players, but best suited for 2 to 4 players. It can be played alone too, it’s just less fun.

Otherwise, it’s like Tower Defense meets Tron.

There is a constant flow of enemies (the spinning cyan cylinders) coming in from the end of the map, and their goal is to reach your home base.

By moving around, the players create walls that eventually fade out, but that can slow down the enemies’ movement.

You can shoot lasers using your headpiece/weapon, and one shot kills an enemy (but there’s a cooldown time).

You gain experience points by killing enemies, and experience points levels up your weapon (faster kills, up to 3 attacks per shot).

The more experience you and other players gain, the more enemies are produced.

If an enemy makes it through your defenses to your base, every player loses a level.

The game never ends, but eventually there’s just too many enemies, everyone falls back to level 1 and the game falls back to its initial state.

Concept

The idea was to make a multiplayer game without a server, that happens “on the wire” and free for any one to drop in or out.
So it kinda goes against the idea of cloud computing, where the client is as thin as possible and the server (or server farm) does all the work and keeps all the state. In our game, the clients are as heavy as can be, and try to maintain the state of the whole game based on the messages that are passed around.

Also, the theme of this year’s Bivouac Urbain was the song Dan Dan by Misteur Valaire. The song that is played in-game is Aliceffekt’s remix of that song, and it complements the gameplay nicely.

Post-Mortem

This year’s jam was very different from last year’s. Aliceffekt is a super-productive multi-talented artist/designer/hacker and he was quite an asset at a gamejam.
The game’s design was already decided before the jam started, so that saved us a lot of time. And 12-hours in, most of the art was already done, and I was really lagging behind. :P

Concept art for the player model

It was a huge challenge to me for two main reasons :

It was my first real game in Unity (I only skimmed through tutorials before, but I use C# daily)

It also was my first network-multiplayer game, and a weird one at that.

Most of my time at the jam was spent debugging the network code, and just messing around trying not to crash Unity. Even at the end of the 36-hours, the game had pretty bad synchronization issues between clients, different enemies on-screen and lasers shooting in the void. People seemed to like it nonetheless. :D

I can’t say I regret decisions that we’ve made, or that I/we should have done things differently. It was a great learning experience, stressful but gratifying, and jumping into unknown territory like that is one of the best ways to kick yourself in the butt and learn a technology for good. I feel infinitely more confident in using Unity now than before the jam.

About the initial concept (a headless LAN multiplayer game), I’d say that it’s feasible, but keeping the clients in sync is a big challenge. I’d also say that my implementation is pretty poor and doesn’t play well with lost packets (and it uses UDP, so no guarantee) or an unstable connection. I didn’t do any kind of client-side prediction either, but I literally flood the network with packets (every client sending 10 packets a second) so interpolation isn’t really necessary if the network can stand it.

A couple of things annoyed me with Unity, but I was at such an early learning stage that I probably did things all wrong, so they’re not worth pointing out. The general thing that stood out is that Unity is fantastic when you use the built-in stuff, and less fantastic when you want to hack it your way… but everything’s possible if you have sufficient google-fu and patience. :)