There's a pure C# implementation of Lua here: https://github.com/xebecnan/UniLua

And we've sold 26 out of the 100 tickets available.  Make sure you get one if you're planning on attending!

Tickets now available!  And other logistics details: http://www.tigjam.com/

Do they still email people the judge reports? I haven't read all of the pages... 

that's a good point. i'm faintly curious myself.

There are 1,200 pieces of judge-to-entrant feedback in the system (there is also a lot judge-to-jury feedback, in addition to the option judge-to-judge comments).

It's on my todo list!  Just been super busy pre- and post-GDC.  Sorry about the delay :/

June 20-23rd:  http://www.tigjam.com/

We'll have more details (and tickets available) in the next few days.  Just wanted to get the dates out so people can start planning!

Any updatery on this yet? 

Very soon!

Cool, thanks!  Was 16 the number of games 'assigned' to each judge?

Not really.  There wasn't one batch of assignments this year, but a continuous process of assigning games up to a threshold.  If you judged three of the games in your assignment pool, you'd get another three games to judge a day or two later.  Game assignments were prioritized on a few criteria.  This let the system assign games that needed more ratings, or games that needed particular hardware configurations, while still letting judges investigate games on their own.  There was a "checkout" limit where the system prevented you from downloading additional games if you had a high number of downloaded-but-unrated or assigned games pending.

Later in the judging cycle, I added a "Help Out" section to the filter options, which showed the 10 least-rated games.  We emailed judges about this, which helped bring up the minimum ratings-per-game.

Paul:  As near as I can tell, games with more views (and therefore more ratings) are more interesting games, and more interesting games tend to be finalists.  Comments on entries were visible to all judges, which helped with discovery.

[5]

Very interesting... Any chance you could post medians instead of (or in addition to) means?  Means are outlier-sensitive and clearly there are outliers here.

Sure!  I might be able to scrounge time to do a more detailed analysis, but for now:

Median ratings per entry:

5 - All entries
8 - Top 200
23 - Top 30

Median ratings from each judge:

16 - All judges
42 - Top 50
75 - Top 10

Not related to winners, but during my IGS soapbox talk I released some IGF judging stats: http://www.matthewwegner.com/igs-2013-soapbox-talk/#igf

How do the Enemy layers work? With multiple enemies, how's it set up so that enemies don't collide with each other? I'd also be interested to know how the Sensor layers function.

EDIT: Oh I see. You must have it set so the Enemy can only collide with the Player and Player Attack layer. Do you use Unity's gravity then, for things like jump?

We use a mix.  Usually global gravity is handling everything, but for some character/move time scaling I modify gravity per-object (just ForceMode.Acceleration on an AddForce call).  The moves themselves can also have translation objects that override all gravity temporarily, for i.e. an air dash move.

On collision, you can also do things discretely with Physics.IgnoreCollision and Physics.IgnoreLayerCollision.  I find it's much more sane to just use more layers, though, and shift the active layer around on the objects you want to screw with on the fly.

Was the time-dilation set in place to let players savor their feats of awesomeness?

We haven't used it too much yet.  Some moves slow global time (think some of the jumping attack scenes in 300).  Character time can be scaled, too, which we haven't played much with yet...

Yeah, I was already separating hurtboxes from collision, but the separate upper and lower is a pretty great idea that I hadn't thought about.

In Unity, toggling the actual colliders will trigger center of mass recalculation, and probably screw with inertia and movement too.  Might be better to change the collision layer (although I'm not sure if compound colliders use individual layers from the colliders or just the rigidbody's layer--something to test!).

I have a question.  Do you guys change the capsule size ever (say when going into a roll the player is shorter, or something like that)?  If so, how do you handle making it not fall through the floor or something like that.

We don't change sizes.  And we actually don't have a concept of defining hurtboxes during moves.  The character hurtbox is always the same slim capsule used for physical collision.  We do sometimes toggle some collision on/off entirely for certain moves (in your roll example, you can actually go through enemies entirely).

If we were doing a fighting game I'd want to worry about defining hurtboxes for accuracy, but for Aztez we've been fine with the capsule approach.

If we were, though, I would separate the capsule (physical collision) and hurtboxes (triggers used to detect moves connecting).  For any kind of platformer I would consider using two capsules, upper and lower, and toggling the upper off for things like crouching movement.

Okay thanks
And what about the ai?

Nothing fancy, at the moment, but we're also mid-development.

Aztez has some assumptions:  You're the only "player" avatar in the game, and everyone else is an enemy.  You're the only object everyone cares about (so a lot of this AI is actually you emitting raycasts and things).  With that in mind:

- Enemies maintain a list of their close neighbors

- Right now, characters have "confidence", "bravery", and "presence"

- Confidence goes down heavily when they get hurt, some when their nearby allies get hurt, and back up when the opposite is happening (they're hurting you)

- Bravery is just a number that affects how quickly they return to baseline confidence, presence how much they affect their friends

- You shoot out a big capsulecast in each direction.  Enemies are aware of which # they are in order from you (in the orange sphere):



- They have a target position from you, modulated by their confidence and the order they're in.  If you're fighting a bunch of guys of the same type, they'll stack.  If you scare off the closest guy (or kill him), they'll fill in.  If someone from the rear does a jumping forward attack, the others will make room, etc.

- Target position in that screenshot is the gray box in front of them

- Enemies do dice rolls every so often for a variety of attacks.  Some attacks are frequently attempted by have strict requirements (you in an airborne state, you in a particular relative position i.e. for defensive slashes if you get too close, etc).

- When an attack is attempted, it can have a desired target position relative to you.  Some ranged enemies move into position first, for instance.

@Matthew
Are you using 3d models or sprites on billboards? If the latter do you orient them vertically or with look at camera?

I have never used the layer collision matrix but it sounds interesting.

Everything is a fully-animated 3D model.  Don't have much advice on billboards, sadly!