PAGES

Archives

Category: Games

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. :)

Details

Heather did most of the game design, defined the graphics style and did the sound effects. I did the programming and some game design.

The game was made from scratch in C# 3.0 using the Truevision3D engine with no prior design, graphics or sound work. All the graphics in the game are procedural, and the gameplay itself is based on AI rules, basically a cellular automaton plus the notion of “stigmergy” from the insect world. (We dropped the G in the game title.)

I used a more recent version of my components system, which now has a sound interface via IrrKlang. It’s the same system I used for Super HYPERCUBE and Trouble in Euclidea, growing quite fond of it.

Goals

Guide the ants using suggestive pheromone trails towards or away from the picnic blanket, or killer antlions.

There are 4 levels. Each level has different goals, which are explained when it begins. Some have time limits. If you fail the objective, the level will restart until you get it.

Controls

Requirements

This game uses the .NET Framework 3.5, installing it is mandatory. I suggest you install the SP1 version just in case.
You will also need a bunch of DirectX DLLs that are provided by the DirectX Web Setup.

Because of the fancy blur effect, the game requires a Shader Model 2.0 compatible graphics card. This type of card is fairly commonplace now.

Post Mortem

This was my first real rapid game prototyping experience. The shortest project span I had seen for a game before was about 15 days… so this was something else. Here’s a couple of random thoughts about that :

I need a proper system for timers and interpolators, similar to what Nick Gravelyn posted, or maybe just steal that. It’s really annoying to have a dozen TimeSpan variables to keep track of what changes over time and how long the transition lasts.

I need to learn other languages than C#, and other frameworks than TV3D/XNA. I’m making big efforts in my “engines” to cut down the redundant code, but even then I feel like I’m programming much more than is needed to describe the game mechanics.

A big part of what makes a game actually fun, is how much direct feedback you get from interacting in the gameworld, and how much you feel like you can control these interactions. Stimergy is a pretty slow game, almost an RTS (funny, because I hate this genre), and I’ve seen other competitors value the responsiveness of player input more than the complexity of game systems, and it ended up being a lot more fun. Maybe it just fit the “jam” context better, too.

I need a system for game screens. Something that puts game components in a context, that gives them lifetime. I tend to make all the major components global and automatically-loaded, which is the easiest way, but it makes game state management pretty hard. And it’s dangerous for memory usage. There’s actually a good XNA example that I just need to look at in detail.

If I’m going to do more 2D games in TV3D, I need to build something that will load GIF animations and non-power-of-two textures. Material management for stuff that changes color or opacity was kind of a mess too. I may need to wrap it in something more concise. Switching engine would probably be the more logical choice.

I spent silly amounts of time on tweaking graphical things that I ended up not using. This time would have been better spent balancing the difficulty level or adding more gameplay elements. I’m used to making demos look pretty,… I have to remind myself that I’m making a game here.

I may sound like I’m complaining about everything, but I’m actually really happy about how the game turned out. It’s fairly fun/challenging and it looks pretty good. I’m still wondering whether I’ll release the code because it’s kind of a mess. I suppose I will if I get a request. The source is available up in the Download section!

Super HYPERCUBE (capitalization may vary) is a game I made with the fine folks at Kokoromi for this year’s (2008) Gamma art/game show in Montréal. Gamma is a themed game party that’s been happening for three years now, each year with a design constraint for all the games that apply; this year’s Gamma 3D was about red/cyan stereoscopy aka color anaglyphs.

SHC Logo/Splash Screen : It’s actually all 3D and animated.

The idea is that you have to fit a cluster of cubes inside a wall that represents a projection of that cube on one of its faces, with a series of rotations applied. So it’s a bit like the Japanese “Human Tetris” game shows, which is the comparison that our recent blogcoverage have been using, and it’s exactly right. Except you’re handling a random cluster of cubes.

Development Timeline : From concept art, to Sketchup mockup, to early prototype, to final product!

The game, like all other Gamma games, was made to be easy to learn and fun within 5 minutes, because it was to be played by the public and we want to get as many people to play as possible. So the concept is fairly simple, but I was surprised about how competitive the gameplay was on the showfloor! Until the last minute, I had a fight with a fellow party-goer for the #1 high score, which I won by an unfair margin, which I assume was due to luck and… well… hours of testing the game while making it. ;)

Good Luck With That : The shapes get pretty crazy in the last moments.

But our game’s most awesome feature is not just stereoscopy, it’s wiimote headtracking! Which is a bummer, because even if the game is now available for download, I assume noone will have the setup to play it as it was meant to be played. (The most important part being IR-LED-mounted glasses!)

You can still use an Xbox 360 gamepad or just the keyboard to play it, and that’s how I’ve been testing it most of the time. It’s just nowhere as immersive without the headtracking… the combination of that and stereoscopy worked really well for us. There will probably be videos of people playing at Gamma 3D sometime soon, I’ll update this post with links.

The game itself was programmed using C# 3.5, the Truevision3D 6.5 engine and part of the XNA framework (I’ve bundled the DLL) for full Xbox controller support. There is no sound, this is voluntary… there was a DJ at the actual event. :)

Chances are that if you’re reading this blog, you’ve already heard of this, but I’ll put it here for archiving. :)

Trouble In Euclidea is a game I made for the TIGSource Bootleg Demake Competition as an obvious demake of Geometry Wars. My intent was to demake the graphics (by using ASCII art for everything) more than the gameplay, but it turns out most people did both, which makes much more sense as the gameplay ends up being more original and it plays less like a cheap clone. Mine kinda does. :P

I ended up with five votes in the competition, which places my game 26th out of 30 positions. It may not sound like much, but I’m really happy that I got votes at all! There are really amazing entries that scored around mine, SHADE: Ghost Academy and DamN for instance…

It was also a nice experiment in fast prototyping. I did the game in a single month, but only on weekends except for the last week. Which means I spent at most 15 days on the game, from start to finish, from graphics to game code.

I used C# 3.5, IrrKlang.NET, TV3D and my spiffy new XNA-inspired Component Framework to build it. It worked really well for me, so I decided to release the source of the whole project. As with most of my code recently, it has an almost complete absence of comments, but should be fairly self-explanatory.