In Unity we use Mono to do game code (well, Unity users are doing that, not us). Overall it’s great; it has tons of advantages, loads of awesome and a flying ninja here and there. But no technology is perfect, right?

Edit: Miguel rightly points out in the comments that Mono team is solving or has already solved some of these issues already. In some areas they are moving so fast that we at Unity can’t keep up!

#1: Garbage Collector

Most game developers do not like Garbage Collection (GC) very much. Typically, the more limited/hardcore their target platform is, the more they dislike GC. The reason? Most GC implementations cause rather unpredictable spikes.

Here’s a run of something recorded in the (awesome) Unity 2.6 profiler. Horizontal axis is time, vertical is CPU time spent in that frame:

At the bottom you see dark red thingies appearing once in a while. This is garbage collector kicking in, because some script code is allocating some memory at runtime.

Now of course, it is possible to write your script code so that it does no allocations (or almost no allocations). Preallocate your objects into pools, manually invoke GC when there’s a game situation when a small hickup won’t affect gameplay, etc. In fact, a lot of iPhone games made with Unity do that.

But that kind of side steps the whole advantage of “garbage collector almost frees you from doing memory management”. If you’re not allocating anything anyway, GC could just as well not be there!

A little side story. Me and Unity’s iPhone tech lead ReJ tried to explain what GC is to a non-programmer. Here’s what we came up with:

Garbage Collection is this cleaning service for lazy people. They can just leave any garbage on the floor in their house, and once in a while a garbage guy comes, collects all the garbage and takes it outside. Now, there are some intricacies in the service.

First, you never know when the garbage guy will come. You might be taking a shower, doing a meditation or having some “sexy time” – and it’s in the service agreement that when a garbage guy comes, you have to let him in to do his work.

Second thing is, the garbage guy is usually some homeless drunkard. He smells so bad that when he comes, you have to stop whatever you were doing, go outside and wait until he’s done with the garbage collection. Even your neighbors, who might be doing something entirely else in parallel, actually have to stop and idle while garbage is being collected in your house!

There are variations of this GC service. One variation is called “moving GC”, where the garbage guy also rearranges your furniture while collecting the garbage – he moves it all into one side of your house. This is so that you can buy a bigger piece of furniture, or throw a huge piece of garbage – and there will be enough unused space for you to do that! Of course this way GC process takes somewhat longer, but hey, you get all your stuff nicely packed into one corner.

Can’t you see that this service is the greatest idea of all time?

This is quite a harsh attitude towards GC, and of course it’s exaggerated. But there is some truth to it. So how could GC be fixed?

GC fix #1: more control

More explicit control on when & how long GC runs. I want to say to the garbage guy, “come everyday at 4PM and do your work for 20 minutes”. In the game, I’d want to call GC with an upper time limit, say 1 millisecond for each call, and I would be calling that 30 times per second.

GC fix #2: sometimes I want to clean garbage myself

Inefficiencies and unpredictability of GC cause people to do even more work than a normal, oldskool memory allocation. Why not provide an option to deal with deallocations manually? I.e. a keyword reallynew could allocate an object that is not part of garbage collected world. It would function as a regular .NET object, just it would be user’s responsibility to reallydelete it.

Mono is already extending .NET (see SIMD and continuations). Maybe it makes sense to add some way to bypass garbage collector?

#2: Distribution Size

Using C#/.NET in a game requires having .NET runtime. None of the interesting platforms are guaranteed to have it, and even on Windows you can’t count on it being present. Mono is great here in a sense that it can be used on many more platforms than Microsoft’s own .NET. It’s also great on distribution size, but only if you compare it to Microsoft’s .NET.

In Unity Web Player, we package Mono DLL + mscorlib assembly into something like 1.5 megabytes (after LZMA compression). Which is great compared to 20+ megabytes of .NET runtime, but not that great it you compare it so, say, Lua runtime (which is less than 100 kilobytes).

On some platforms (iPhone, Xbox 360, PS3, …) it’s not possible to generate code at runtime, so Mono’s JIT does not work. All code that’s written in C# has to be precompiled to machine code ahead of time (AOT compilation). This is not a problem per se, but because .NET framework was never designed with small size and few dependencies in mind, doing anything will ultimately pull in a lot of code.

We joke that doing anything in C# will result in an XML parser being included somewhere. This is not that far from the truth; e.g. calling float.ToString() will pull in whole internationalization system, which probably somewhere needs to read some global XML configuration file to figure out whether daylight savings time is active when Eastern European Brazilian Chinese calendar is used.

Size fix #1: custom core .NET libraries?

For game uses, most of “fat” stuff in .NET runtime is not really needed. float.ToString() could just always use period as a decimal separator. Core libraries could consist just of essential collections (list, array, hash table) and maybe a String class, with just essential methods. Maybe it’s worth sacrificing some of the generality of .NET if that could shave off a couple of megabytes from your iPhone game size?

Of course this is very much doable; “all that is needed” ™ is writing custom mscorlib+friends, and telling C# compiler to not ever reference any of the “real” libraries.

Size fix #2: make Mono runtime smaller

Uncompressed Mono DLL in our Windows build is 1.5 megabytes. We have turned off all the easy stuff (profiler, debugger, logging, COM, AOT etc.). But probably some more could be stripped away. Do our games really need multiple AppDomains? Some fancy marshalling? I don’t know, it just feels that 1.5MB is a lot.

#3: Porting to New Platforms

You know this classic: “There’s no portable code. There’s only code that’s been ported.”

Most existing gaming platforms are quite weird. Most upcoming smartphone platforms also are quite weird, each in their own interesting way. Porting a large project like Mono is not easy, especially since parts of it (JIT or AOT engine) highly depend on the platform.

For Unity iPhone, unexpected discovery that it’s not possible to JIT on iPhone made the initial release be delayed by something like 4 months. It did not help that in early iPhone SDK builds JIT was actually possible, and Apple decided to disable runtime generated code later. Making Mono actually work there required significant work both from Mono team and from Unity. We still have one guy working almost exclusively on Mono+iPhone issues!

Of course, maybe all the Mono iPhone work made porting to new platforms easier as a byproduct. But so far we don’t have Mono ported to any other platform, up to production quality. So judging from experience, we now always assume Mono port will be a pain, just because “some nasty surprises will come up” (and they always do).

#4: Small Stuff

There is a ton of small bits where extending .NET would benefit gaming scenarios. For example:

Suppose there is some array on the native engine side; for example vertex positions in a mesh (3xFloat for each vertex). Is it possible to make that piece of memory be represented as a native struct array for .NET side? So that it would not involve any extra memory copies, but N vertices somewhere in memory would look just like Vector3[N] for C#?

On a similar note, having “strided arrays” would be useful. For example, mesh data is often interleaved, so for each vertex there is a position, normal, UVs and so on. It would be cool if in C# position array would still look like Vector3[N], but internally the distance between each element would be larger than 12 bytes required for Vector3.

Where do we go from here?

The above are just random ideas, and I’m not complaining about Mono. It is great! It’s just not perfect. Mono being open source is a very good thing, which means pretty much any interested party can improve it as needed. So rock on.

why would you want sound and physics when you can have sparsely clothed ninja space marine amazon secret agents riding on chainsaw-hoofed flying pink stealth space unicorns through a brightly colored dystopian african urban jungle fantasy wasteland island state populated with mutated propaganda-spewing gas mask-wearing alien nazi zombie demons that entered this island planet dimension through a hellgate portal invasion triggered by a black magic freak teleportation experiment resonance cascade accident caused by a power-hungry mad scientist wizard evil genius working for a multinational corporation conspiracy of lawyers and weapons manufacturers without morals, and all that in its proper realtime dynamically lit globally illuminated deferred-shaded parallax-occlusion-mapped ambient-occluded shadow-buffered high dynamic range silky smooth glory?

Pretty much sums up the mainstream game industry!

The theme for the games was “as long as we have each other, we will never run out of problems”. Additionally, games had to be short (5 minutes of play or less), and somehow incorporate one of “affectionate”, “patriotic” or “missing” words.

I worked on a Missing Peace game. It’s nothing really fancy, does not quite follow the idea and incorporates the above mentioned words in a cheap way (“just stick it into a title! haha!”). It was probably the most polished game from all games made there though (for some definition of polish)… too bad it’s not actually fun to play :)

Oh well. I just did not have any interesting ideas, and wasn’t particularly inspired, so there is the result. Probably burnout of trying to finish Unity 2.5 at work had it’s toll as well.

Overall, the good parts about this game jam:

• It was fun (hey, that’s the whole idea)
• Some very positive progress, compared to LTGameJams 2002/2003: more people (20-25, up from 10-15), much better proportion of artists (about 30%, up from almost zero), more people who don’t know each other, more games made by folks outside of nesnausk! group :)
• Some of the ideas that were brainstormed have interesting bits.
• Did I mention it was fun?

On the downside, I get the feeling that the games made this time were not crazy enough. GameJams are meant to generate totally whacky, crazy and amazing ideas; however this time most of the games were known game mechanics, pretty safe idea and so on. Have to improve on that the next time.

So that’s about it!

Everyone knows the Valve’s hardware survey. But what if your target game players are not the traditional “big budget AAA game” type? For example, at the moment most Unity Web Player games are oriented to much more casual market, so hardware there might be very different. And indeed, turns out it is quite different.

Without further ado, here’s the data we have: Unity Web Player hardware statistics.

It’s about two million data points since we started gathering it earlier this year.

Some subjective points of interest (I’ll be using current data for 2008 Q3 here):

• Operating systems: Mac OS X is 2.5%, the rest is Windows. 64 bit Windows haven’t really picked up yet (0.7%). Windows 2000 is dying fast (0.7%). OS X Leopard already took over OS X Tiger.
• CPUs: poor Transmeta :) Dual core CPUs are becoming the norm (46%).
• Graphics cards: quite sad, in fact… top 15 cards are slow or horribly slow. Capability wise, they are quite good, with about 70% having shader model 2.0 or higher. Shader model 1.x cards are dead. “Can has DX10” is 2.7%.
• Casual machines don’t have lots of RAM. Nor lots of VRAM.
• Most popular nvidia driver? 56.73. Looks like this is the driver that comes integrated in XP SP2… Now, who says regular people ever update their drivers? Likewise, vga.dll (i.e. standard VGA) is 1.6% of machines; additional 1.5% don’t report any driver (not sure how that happens…).

So yeah. Casual machines: capabilities quite okay, performance low, low, low. That’s life.

So it’s a small very small 2D game without any next-gen bells and whistles. It can probably be done casually on the side, by allocating an hour here and there. We’ll see how it goes. Hey, I never actually done any game in Unity, I only make or break some underlying parts…

Of course, first I start with no game, just imported graphics. Hey look, I can do sprites!

Then cook up some base things: define the game grid, throw in some basic user interface on the right hand side, and make it actually do something. This wasn’t so hard; that already gets me an almost working level building functionality. It does not have fancy block building delay or block deletion yet; that will come later.

Next come basic physics. Danc’s design calls for simple arcade-like physics (things moving at constant speeds, bouncing off at equal angles, and so on), but in Unity I have a fully fledged physics engine just waiting to be used. Let’s use that.

The design has sloped ramp pieces, which are hard to approximate using any primitive colliders, so instead I’ll use convex mesh colliders for them. Now, on this machine I only have Blender, which I totally don’t know how to use; and I was too lazy to go to PC and use 3ds Max there. What a coder does? Of course, just type in the mesh file in ASCII FBX format. Excerpt:

; scaled 2x in Z, by 0.85 in Y
Vertices: -0.5,-0.425,-1.0, 0.5,-0.425,-1.0, -0.5,-0.425,1.0, 0.5,-0.425,1.0, -0.5,0.425,-1.0, -0.5,0.425,1.0
PolygonVertexIndex: 0,1,-3,2,1,-4,1,0,-5,2,3,-6,0,2,-5,2,5,-5,3,1,-5,5,3,-5

It’s a left ramp mesh! So much for fancy asset auto-importing functionality, when you don’t know how to use those 3D apps :)

After a while I’ve got peas being controlled by physics, colliding with level and so on. Physics is very bad for productivity, as I ended up just playing around with pea-stacks!

So far there’s no game yet… Next up: implement some AI for the peas, so they can wander around, climb the walls, fall down and bounce around. I guess that will be more work and less playing around… We’ll see.

It’s probably three frames per second. In the menu!

I did not see the game itself yet, got bored while waiting for the after-menu-but-before-game intro movie to end (it’s not skippable, and it also ran at about three FPS). This is after watching half a dozen obligatory before-menu intro movies at 3 FPS with stuttering sound (“nvidia,vidia,vidia,vidia… the way it’s meant,meant,meant,meant…” – TWIMTBP).

All of this on a half-decent PC, I think – Intel Core 2 Quad, 4GB RAM, Radeon 3850, Windows XP, latest drivers, none of extra stuff running; the PC is able to run other 3D stuff just fine. I’m sure the developers and EA’s testing labs have tested everything extensively, but sometimes something completely random apparently can make things be oh so slow. Oh well. Get back to work.

You drive a jeep with a spiky ball, and your goal is to chase down raptors and send them to the future, presumably to end world hunger. Or you can do stunts. And you the driver are a raptor, only you wear a hat and a monocle.

Just go and play it already: raptorsafari.com. It’s free.

Or watch a trailer if you want to miss all the real fun, or read a press release. Of course it’s made in Unity, in two months from start to finish.

To me, this is a perfect example of focus. Basically there are three things – 1) vehicle, 2) raptors, 3) physics mayhem – and that almost describes a game. Yes, there are crates and stunts and achievements and online leaderboards, but that’s just additional stuff on top of the core game.

Sounds like a good plan for making game prototypes:

1. Think up a game idea and describe it in one concise sentence. The idea may be totally crazy, like in this case. I guess an idea like Velociraptor Safari would not fly in a pitch at any publisher, but that does not matter at this point.
2. Get a small team of smart people. In Flashbang’s case, it seems they were 4 to 7 person team.
3. Choose a game engine/toolset that will allow you to make your game fast. *cough cough*
4. Do it!

All the above requires is a small smart team and groceries/rent for a couple of months.

Your original idea may be totally crazy, but with the actual working prototype at hand it might just work. Looks like Velociraptor Safari really clicked something on the internets (see Kotaku, JayIsGames, Destructoid, TIGSource, AtomicGamer, …).

It’s a cute little gem, or alternatively, “Puzzle Bobble meets Ageia’s PhysX engine”. Lots of levels, user level editor, some AJAX magic and so on, and everything made in about four weeks. Matthew has some technical details for the curious.

Here are some shots and a youtube trailer for the lazy ones. The youtube trailer uses music from 8bitpeoples which can’t be bad :)

But really, you should just go and play it: splume.flashbangstudios.com

* I stand corrected: When Orcs Attack also was made with Unity 2.0, and it was released earlier!

I like it! That says a lot, because last time I played FPS was ages ago. Finally, someone made a game that I can like again. How much I’m biased because it’s made with Unity… decide for yourselves :)

Now the killer part: the game is designed and developed solely by a 15 year old – Forest “Yoggy” Johnson. How cool is that?

Enough talking, just go and play it. And remember that you didn’t see cool until you get to the robot level!

Zen Bondage is a puzzle game about control. The
motivation was to try to make a puzzle game which
evokes adult emotions.

However, it fails to evoke any “adult emotions” in me. Maybe I’m just not into this bondage thing :)

I like the simplicity/pureness of the idea, and it’s executed very well.

I few weeks ago I was visiting OTEE and over the weekend we were jamming on a small game called Pakimono! The idea of the game was pretty cool – you’re the naked guy and have to ruin tourists’ photos :)

The whole experience was great. It was my first time using a Mac, first time working with Unity (their game development tool) etc. I coded&tuned most of the bullet-time character controller, where you drag your limbs with a mouse, trying to cover as much of the sight as possible.

The coding was a bit unusual – most of my coding life I was doing pretty low-level C++ programming. This time it was completely different – I’d setup “the game” directly in the editor, write some short C# scripts and boom! – everything works, without me having to worry about any of the low-level stuff. No recompiling or any of that stuff. Cool.

Ironically, I did not see the final Pakimono build yet. I left earlier than the others and do not have a Mac anywhere nearby. But the guys promised me a windows build!

And if you ever hear an indie game developer talking about level design, either shoot them in the head now to help them avoid their future misery, or direct them towards this essay.

It ownz, period.

Go to downloads section at the site and get this large video presentation. It’s really good.

38% of Americans own game consoles. Around 40% of Americans own guns. The gun lobby is damn powerful. We shouldn’t need anywhere near as much money as the gun lobby, because unlike games, we are absolutely, 100% sure that guns actually do kill people.