Thursday, November 29, 2012

Battle Maiden Part 2

Day 2: Saturday

Fixed shoulder joint twisting.

Had to leave early because like mentioned, it suddenly turned out to be cleaning day.

It turns out Saturday was also when the meetup for the Game On! Philippines 2012, a game development competition for students. Me being one of the mentors for the participants, and that day was when the participants would meet with the organizers to show progress on their game, I attended the meeting to talk with the participants.

I'll talk about that some other time, but long story short, I wasn't able to do much progress on day 2.

Day 3: Sunday

Got things set up back at home. It's kinda hard to get back to the rhythm since the 48 hour hackathon didn't push through.

Suddenly I'm having crash problems with my Unity.

Every time I click "Apply" on changed prefab settings, there seems to be a 2 out of 3 chance that Unity will crash.

I guess it's because I'm using an old version, 3.5.5f2. So I tried finding 3.5.6, the latest one in the 3.x versions.

The official Unity site, for some reason, doesn't show the links to older versions of Unity. Since Unity 4 is out, this means there's no links to any 3.x versions.

I had to find it from the forums, and even the site had problems.

Dark forces are at play here.

When I finally got to it, the download is slow, as expected. Oh Asian Internet, you so crazy.

It would have been nice to just press Ctrl+S in the Unity editor and be assured that everything was saved in case a crash happens again.

Unfortunately, this isn't the case. When you change settings in prefabs, or GUI skins, or ScriptableObject files for example, Unity holds off saving the changes to the disk until you quit Unity. So I find myself closing and opening Unity after every significant change I make.

Meanwhile, I got the Locomotion system working a little more smoother and I got to test the player model in the game.

Times like these I wish we had motion capture studios. I heard you can use a Kinect as a low-cost makeshift motion capture device.

Day 4: Monday

Have I mentioned that I go to the office only when I feel like it? Yeah, so Monday will be devoted to finishing this, because I say so.

Day 5: Tuesday

Have I mentioned I rarely ever get any work done while at home? Yeah, so I slept all day long yesterday. But I was able to test attack animations today.

Also, seems like the version update for Unity got rid of the crashes.

Day 6: Wednesday

I did a few thumbnail sketches so I wouldn't forget what animations I wanted to do. I should've done this earlier.

Right now the game is sort of on-hold as Wednesday is usually the time I go to the office.

Wednesday, November 28, 2012

Battle Maiden Part 1

In the small game development studio I work in, I wanted to have what we ended up calling "Free Fridays": Every first Friday of the month, everyone stops doing work for clients and make personal projects. At the end of the day, you show your work to everyone.

This was an excuse to find the time to do crazy ideas that we get every now and then.

One such idea came to me when I was about to sleep, I just thought all of a sudden "Damn it, I want to play Assassin's Creed style combat right now on my Android tablet."

I thought, yeah that could work. I actually like the easier, free flow approach in Batman: Arkham Asylum. Batman can dart from one end of the arena to the next so easily, hitting opponents here and there.

H-Here We Go

So when our Operations Director mentioned we forgot to do Free Fridays again for this month, I thought I'd do that idea.

I also requested that Free Friday be lengthened to 48 hours (up to Saturday), since the idea I had was a lot of work. Game jams are mostly 48 hours anyway.

Even with the extended duration, I knew I had to cheat a little. I'm only one guy doing both code and art so 48 hours was probably still not enough.

Day 0: Wednesday-Thursday

I stole some time from work to prepare the 3d models I'd use. For the enemy I used the soldier model I already made from before.

For the player, I used MakeHuman to create a base mesh, then added hair and clothes in Blender.

I did this with the understanding that I'm making a throwaway model just so I can finish this as soon as possible. While her face shouldn't be anime like my old sketches, it shouldn't be the one that MakeHuman comes with either.

I downloaded a bunch of Assassin's Creed 2 and Batman Arkham Asylum YouTube videos for reference.

The idea was that we'd start at 00:00 of Friday and end at 23:59 of Saturday, to really squeeze the 48 hours. It wouldn't be wise to extend to Sunday, and the higher-ups didn't want us to start earlier than Friday.

So by about 1 AM of Friday, I was still preparing the player 3d model. I had a headache and felt like vomiting (as always when I stay too long in the office), so I had to sleep it out.

Day 1: Friday

By morning I was ready to tackle it on.

This was my first draft for the ideas.

I thought I'd try Unity 4 with all its fancy new animation systems with the blend tree. Hopefully that would make my work easier.

As I tried getting myself accustomed to the GUI changes in Unity 4, this happens.

I can't rely on a tool that crashes, given that I have a tight deadline for this, so off I went back to Unity 3.

These were my first few tests:

I wanted a way for the enemies to figure out the path to get to the player's backside. I also wanted them to move in an encircling fashion. So I made a simple waypoint system to track the player's front, back, left, and right sides.

Next I had the enemies actually follow that path.

By afternoon, I swapped in the enemy 3d model. I used Rune Johansen's Locomotion System to make the walk animations look better. Props to Rune!

Unfortunately we were suddenly told that Saturday can't be used anymore because the office will be cleaned. I guess I just have to take my work home or something.

To tell the truth though, not a lot of people in the office was taking Free Friday very seriously. Some understandably still had deadlines to meet and some were just playing videogames.

I actually still needed to fix the player 3d model. It wasn't even rigged/skinned yet, so I ended up taking too much time there.

I wanted a lot of fancy physics effects on the player. The skirt and ponytail should sway, and her boobs should *ahem* move naturally.

For cloth swaying, Unity has the built-in Skinned Cloth component for that and it works as expected. The interface to configure it isn't exactly great, but it works as advertised.

Doing the same thing for the ponytail would be overkill, and besides, it should move more like linked pieces of elongated chains than like a strip of cloth anyway.

I found a link in reddit that explains a simple trick, just use rigidbodies with joints on them and add some swaying motion:

The only problem was that the tutorial needed me to configure my 3d modeling software to specifically disable keyframe animation on the bones that need to jiggle. Unfortunately, no such option exists in Blender, so I just did something quick to fix it.

I made a script in Unity that detaches the ponytail's bone from the skeleton then reattach it again quickly. This would cause it to stop being moved by the skeleton's animations, while still being connected to it.

For the boobs, the wiki site has something just for that:

The code for that needed some cleaning up and it didn't seem to work reliably at all for a 3d model created in Blender, so I took some time to fix it.

The day ended with me staring at bouncing boobs.

While I feel a little stupid for doing this, I made pretty sure the physics don't go so far as this:

Damn, I haven't even added combat yet.

Saturday, October 27, 2012

Combat-esque conversations?!?

So, to open my argument, here it is:

What if you could take the idea of a combat system, and use it for your NPC conversation system?

We all know dialogue trees are a drab workaround to letting a game's main character partake in conversations with the game's make-believe world.

Aren't you sick of that? Can we try to find a way around that somehow? Isn't it worthwhile at least to experiment, see if there is indeed some better way?

Craig Stern has this to say about dialogue trees in his article:
...This emergent quality makes combat a tempting choice to form the backbone of a cRPG, since it offers a much higher ratio of entertaining possibilities relative to development time spent than a more static system (such as, say, dialogue trees) would.
That was actually what led me to think about this whole idea in the first place.

If combat systems were designed to be so emergent (you can explore so many decisions and tactics) while only an economic amount of programming is required, why can't we try the same idea for conversations?

So how is it going to be? For starters, we can take this:

and turn it into this:

Its a very superficial take, but you get the idea, don't you?

When you choose "Attack", you see your character swing his sword and the enemy takes a hit. Then the enemy takes his/her turn.

When you choose "Insult", you perhaps would hear your character say a pre-recorded line of (insulting) dialogue, chosen partly in context and partly in random. And you'd see the expression on the other person's face, and see/hear his/her reaction.

I'm not proposing some sort of procedurally generated lines of dialogue. I certainly don't think our best technology so far can do it reliably.

What I'm thinking is scripts will still be made, its just that instead of choosing exact lines to say, the player "macromanages" the conversation.

Looking at that, its not such a radical idea, really. Many games experimented with this style before.

In Indigo Prophecy, instead of choosing specific lines of dialogue to say, you choose some topic, and your character automatically shifts the conversation to go there.

Same goes for Mass Effect to an extent.

Update: A whole list of other games with similar ideas by reddit include: Monkey Island's Insult Sword Fighting, Leisure Suit Larry, Deus Ex: Human Revolution.

But instead of choosing contextual topics at hand, what I want to see is a fleshed out system with rules akin to combat and everything that supports it: the importance of movement, targeting, stats, skills, perks and whatnot-- but for dialogue.

Skills and perks... all of that sounds overkill for a conversation system. But its worthwhile to study if some things can be translated here.

Interrogations in L.A. Noire comes very close to what I'm getting to.

Here was another impetus for me to jump-start the idea. Tonio Barmadosa has this to say about behavioral game design in this article:
Very interesting indeed. I can't help but draw an analogy with a totally different field, called Pickup Artistry. Pickup artists pick up hot babes in night clubs using methods from Behavioral Psychology. They push a girl's psychological buttons in order to create attraction, qualification, comfort and eventually seduction.

They use the exact same techniques, for example, being unpredictable and pushing and pulling all the time, which is equivalent to variable ratio reward / punishment.
We're getting somewhere here aren't we? "Picking up" can be thought of as a game. But one thing to note here is that you are not the player anymore, at least not purely. You also partake the role of umpire. You hand out the rewards to the player (i.e. the hot babe/guy) when you deem so. You make the player feel like s/he worked hard for something.

This is, of course, for seduction, but I think we can work out how it plays for other goals.

Goals for why we "talk" to NPCs may include:
  1. To get useful information1
  2. To get useful feedback (as in suggestions, criticisms)
  3. To progress in the story, main storyline or otherwise
  4. For romance, as noted earlier
  5. To coerce, persuade, or fool them for your advantage (bribes, taunts)
  6. etc.

[1]: And this can even be while in a hostile environment. Black Widow's first scene in the recent Avengers movie, is where she fakes naïveté while actually collecting information from the enemy.

Let's see all of our tools at hand in a combat system.

In a combat system, the very first thing you want is a way to assess the enemy and the surroundings.

Practically, this means a health bar, maybe a grid to see how far they are, fog-of-war, etc.

In a conversation, maybe you can have a hostility/friendliness meter on your NPCs. Maybe even an irritability meter, or a boredom meter akin to The Sims.

Your high-level options then fall somewhere along these lines:
  1. Inspection: assess the enemy
  2. Aggression: extinguish the enemy (attack)
  3. Conservation: survive/outlive the enemy (heal/defend)
  4. Subversion: weaken the enemy from within (poison, slow, etc.)
  5. Augmentation: strengthen yourselves (buffs)
  6. Concession: surrender, truce, agreement, etc. (forfeit, load game, etc.)
This is all well and good, but how does "extinguish the enemy" translate to "find out why he's hiding from the bandits" for example?

Let's say that's our "victory condition".

For a goal of "find out why he's hiding", the enemy is not "he", it's his reluctance to say his reason for hiding.

These could be some examples of how it would pan out:
  1. Inspection: asking questions
  2. Aggression: pressuring, convincing the person
  3. Conservation: defending your argument
  4. Subversion: intimidating, lying
  5. Augmentation: make yourself sound credible
  6. Concession: bribery, bargaining with the person
Again, these are high-level examples. In the same way that saying "attack" in combat can be done in a multitude of ways, the act of convincing or intimidating would also be achievable in several ways.

I'm particularly interested in how spatial movement of combat can be translated to a conversation system. Perhaps that can represent the topic of conversation?

The same way attacking the rear of an enemy can deal critical damage, perhaps pushing the topic of conversation to something the person is uneasy with will make your persuasions "deal critical damage".

Even with having these commands and "movement" options, I think the end result of the player inputting such commands should still show two guys talking, complete with dialogue text, and prerecorded lines of dialogue if need be.

In this manner you could say in the end this is actually more complex than a simple dialogue tree system. It is, but imagine how this could change your game (I'm actually content with just text dialogue, but having audio dialogue will definitely make it harder).

If the player is losing, he'd usually just load a saved game, but what if he can bargain with his enemy?

What if the player can talk to a merchant to drop his guard or distract him?

It can open up more emergent possibilities.

Monday, October 15, 2012

Unity Game Jam Manila 2012 Part 3

On the final day, things started to get hectic. As the staff needed to go to the associated event to give a talk about game development, Charles and I found ourselves having to man the game jam (I couldn't find the marshals for a time, they probably needed to be elsewhere too!).

We needed to facilitate getting the participant's builds into the officially designated machine to be used to demonstrate the game during judging. We needed them to submit their builds, let them test it on the machine, and make sure they don't do something horrible like delete the other teams' folders.

Then Charles said he needed to assist some guests from the industry looking at the game jam, and I was left to man the machine (see what I did there?).

Occasionally manhandling the mic to nag them about the deadline, I was checking off which teams have submitted at least one build.

Some cut it close to just 10-20 minutes before the 5pm deadline (I'm not actually sure if it was an exact 48-hour jam).

And there was even one who, get this: she only attended the first day, then left for home, did the jam by herself in her house, then came up like 20 minutes from the deadline asking to get submitted.

As facilitator, Brett was a nice guy and let her submit for presentation, but it was up to the judges if she was eligible for the prizes.

Paul Gadi of IGDA Manila came by the jam venue and went just as fast. Apparently he was on short notice.

Then a guy gave me a scoring sheet and said, "You're going to be a judge. Paul Gadi couldn't make it to the judging so you'll stand in as the IGDA representative."

Haha. Oh wow.

Thankfully, all teams were able to submit before the deadline.

I would have loved to post screenshots of each game made but I don't have them.

And so after presenting the games, and us two mentors presenting our games too, I had to go and judge.

There were immediately three games that stood out to me:

Prologue: Primitive Life

Pretty unusual game. You see a planet in XCOM geoscape style, and your goal is to fling asteroids at the right position and moment to start the seeds of primordial life.

Crystal Boom

A shooter reminiscent of Clean Asia (the Attractor ship) and Gradle Unison, you dash to attack instead of shooting bullets. I'm a big fan of these games. As a cool bonus, your super attack is you can set arbitrary way-points and your ship will dash to all of them instantaneously.


These guys went for a safe bet and made a side-scroller of the popular running-man subgenre (i.e. Canabalt clone) but it was an interesting take in that you need a light source to see where you're going. You need to collect glowing spheres to charge up your light, so in addition to avoiding obstacles, catching lights is very important.

Playable Web Build:

I am going to share my personal opinions here:
  • Prologue: Primitive Life
    • Pros:
      • Has a good amount of challenge, testing your aim and ability to time your shots.
      • Impressive graphics for something done in 2 days.
      • A very unique game, I don't know of any game similar to this.
    • Cons:
      • Not enough variation. Once you master the skill needed, the fun wears off. My suggestion is to add more types of asteroids in addition to the life asteroid and death asteroid. Perhaps an asteroid that makes depressions on the planet, or ones that build mountains. Perhaps ice asteroids that make oceans, fire asteroids that make volcanoes, etc.
      • The presenters themselves noted there were some bugs.
      • The presenters did a poor job of explaining the game to the judges. Brett had to re-explain how the game works to the other judges so they could understand it. Remember, some of the judges know very little about video games beyond what they have in their smartphones, so that needs to be taken into account.
  • Crystal Boom
    • Pros:
      • Again, a challenging game. Like I said, I'm a big fan of shooters like these.
    • Cons:
      • I find little relevance to the theme of "Primitive Life". Even the title, Crystal Boom doesn't have anything to do with the theme. I think the enemies were supposed to look like biological viruses, so there's that. Thing is, they cajoled an existing game genre into the theme, not the other way around. In the end though, I don't care as a gamer, cause I like to play these kinds of games.
      • Graphics weren't so good. Check Clean Asia and Gradle Unison for ideas.
      • Same problem with Prologue, the judges couldn't understand how the game works even with the presentation that was made. I had to go and explain them.
  • Silhouettes
    • Pros:
      • Challenging game. Running-man games are inherently challenging.
      • Easy to understand how to play. Only one judge didn't get it, and still, after a little explaining, he immediately got it. That's a given though, since running-man games always have simple controls.
      • Very very good amount of polish to the game, they can take the game as-is, and release it on the appstore. And they should.
    • Cons:
      • Not that it matters to me, but I also find little relevance to the theme here, if at all. They explained it was "primitive" in the sense that you're running in fear of the dark, like primitive instincts kicking in. But the truth is, again, they cajoled an existing game genre (Canabalt clones) into the theme. It feels like cheating to me on that bit, resting on some sure-win mechanics that other people came up with. But again, its ok. The thing is, they added their own little twist to the running man genre so it wouldn't be generic.
If it were up to me, all these three would win, but all of us judges had varying opinions. The only thing we could universally agree on was that Silhouettes was very nice overall, so it was no question that that was first place.

What hampered the other two games was that the judges didn't get how those games were played, and presentation was part of the judging categories. In contrast, Silhouettes was easily understandable.

For future games, my tip is to add in-game tutorials, perhaps in the same way Silhouettes does. Also I did that in my game, TopSide.

To the game jammers, here's a tip: NO ONE WILL WANT TO BOTHER READING THE HELP/CONTROLS SCREEN. You can't expect people to be patient when all they want is to see how the game plays.

If you find people getting stuck and you have to explain verbally how the game plays, you're doing it wrong.

The game should naturally teach the player how to play, as part of the playing experience.

It could be in-game tutorial text like in Silhouettes or TopSide, it could be some character in-game talking to you how the game plays, it could be tutorial levels, like in Valve's Portal.

Play again the videogames that you play on your PC's and consoles. You'll see these things. And they're very important. The player won't get to experience the fun part of your game if they can't understand the controls in the first place.

Here's part 1 and part 2 of this 3 part post.

Sunday, October 14, 2012

Unity Game Jam Manila 2012 Part 2

So with that previous part about the new keyword, I spent time fixing my code for Tactics Ensemble.

By 7pm of Oct 11, Thu, the participants entered. More than 30 people came in (16 teams were ultimately formed).

After the introductions and FYI's with the student's curfews and everything, Brett announced the theme:

"Primitive Life"


To help, Brett showed some examples, "Ok, what do you mean by primitive?" It could be, primitive geometry, primitive behaviour, and some other examples I forgot. It was "primitive geometry" that stuck in my head.

Brett told us mentors, "You know, this first half of the jam, you don't need to worry about anything, cause they're still mostly in the planning phase. You might as well get some rest. It could actually get pretty boring so you may even want to actually do the game jam too, you know, while waiting for people to ask for your help, you could do it as well, cause you're gonna get bored."

I actually had a headache that night (was not able to sleep the night prior to that because friends were playing multiplayer Borderlands 2 nearby, shouting all night) so after commiting my changes to Project Tactics Ensemble, I called it a night, & went back home to sleep.

On the way home though, I thought if I was participating too, then I mulled on the theme.

Primitive Life.


The usual thing to go for here is some sort of caveman game. But that's too bland.

What about a game where you beat up programmers who have such a primitive way of thinking in making their code? Yeah that'd be fun, I'd play that. A lot.

All I could remember from Brett's examples was primitive geometry.

So between last night and the following morning, my train of thought led me to this old 1884 novel called Flatland: A Romance of Many Dimensions. I actually found out about that a long time ago in college, thanks to Project Gutenberg.

I never really got around to reading the novel but, long story short, its about a fictional world where 2d shapes were living, breathing characters.

One of them, a hexagon, thought, "What if there's a 3d?". And such ideas were pretty much taboo in 2d land. So she ended up in a journey going to 3d and even 1d. (As a nice bonus, there's actually an animated film adaptation of the novel released back in 2007.)

That was where I got the idea. Some game where you transition between 2d and 3d. And I thought, practically that would most likely be transitioning between side-scroller and 3d isometric.. or should it be between side-scrolling and 3rd person view?

And I thought the idea is good but I'm going the wrong direction here. There's not much sense in doing those.

So I thought, what about a game where you transition between side view and top view? That's probably more useful. There are things you can only do in side view, and things you can only do in top view.

Then I thought, ok, I'll make it that you can only jump in side view, and that you can't in top view, because it's hard to notice such a thing in top view anyway.

Side view is how you normally move left to right, but top view is useful if you want to "change lanes", so to speak, get behind or in front of things.

So the moment I got back to College of St. Benilde, I was surprised to see my other mentor partner (Charles Cue) was already working on his game jam game too!

Ok, a little competition now, is it?

I started working on my idea as soon as I could. I checked around and it seems like the participants have yet to run into problems.

This obstacle was the very first thing I set up to do.

I might as well link the actual game I ended up with here. Make sure to click in the game so it can get keyboard input:

There are only 3 levels so far; the 3rd level simply loops back on itself when you finish it.

I tried making myself useful for the participants but I got the feeling I was being brushed off. All the other mentors there were faculty staff of the school. I was the only outsider. Some of them probably didn't even know I was a mentor! Brett had a better rapport with the students cause, well, he was visibly the guy from Unity Technologies.

I felt I looked rather stupid roaming around and getting strange looks from the students.

Nevertheless there was at least one participant who was friendly with me. Admirably, she was the only one who went solo while the others were all in teams.

Ok, I'll stop here. In part 3 I'll explain how the jam ended.

Here's some photos I took (since no one was asking for my help!):

Having neglected to bring a sleeping bag, this was
where I slept. I used some t-shirts as a makeshift pillow.
Toilet paper? Check. Food? Check. Laptop? Check. All set!
Billy here used to be an intern in our company, now he's
landed a job! Not in our company, but I'm still happy for him.


Unity Game Jam Manila 2012 Part 1

I got a rather surprising email last Oct. 2. A notification for a Unity Game Jam here in Manila, Philippines. Amid the looming deadlines I have for both work and personal projects, I thought that more stuff to do was the last thing I wanted to see.

Then I thought, what if the prize is a Unity Pro license?

I read the email more and what I got from it was this was meant more to be for learning Unity, other than it being a game jam (i.e. the whole "learn how to make a game in 48 hours!"). Also it turns out, De La Salle-College of St. Benilde is one of the sponsors of the event, so I take it students will be joining.

So, for the most part, I just ignored it.

The week that game jam is gonna take place, I see the usual announcements on our little IGDA Manila Facebook group, and silly me, I neglected to announce it on our Unity Philippines Users Group too. Though pretty much the people in Unity PUG are in IGDA Manila too. Nevertheless, I probably should have made some announcement too. I was hoping Mars Balisacan would do it; I'm only the guy who answers newbie programming questions in the group!

Then I got a private message, "Hey Ferdi, would it be ok if you come in the game jam as one of the mentors to the participants?" And having gotten that message while I was in the office in the middle of work, it was like a nice little distraction to go on some event for a while.

I also convinced myself that it would look good for the company if we participated in official Unity events. So I decided I would go.

So come the starting day of the event, straight from Quezon City (where our office was) I took the railway transit back to Manila.

When I got to the event's location (i.e. College of St. Benilde) I got stopped by some pretty strict security and it turns out the guards didn't even know the game jam is about to take place in their school.

Fortunately things cleared out amidst many phone calls and forms to sign.

Brett Bibby of Unity Technologies was coming in as the facilitator and the first thing to do was a briefing of us mentors. Apparently his flight got delayed so I was able to take some time to rest and chat with the people there.

When Brett arrived, we set up our things in the game jam's venue, the school's "Alienware Lab". Pretty much a big open space with a bunch of Alienware PC's. Unfortunately those things weren't set up yet so I couldn't get to try them.

So the briefing? It was this: Brett wanted to see how good we are with Unity so he asked us to come up with a game from scratch in 1 hour. Understandably it only needed to use cubes, and spheres, and whatnot.

My throat dried and my heart pounded fast. Being something of a perfectionist, I didn't want to settle for making a game that can't be completed in one hour. You could say I'm a completionist.

Ah, I know which game to make.

The simplest thing I could do: a side-scrolling shooter.

I did one before when Mars and I conducted the seminar about making a game using Unity. But I can easily recreate it from memory, more or less.

The challenge was doing so in under one hour.

So off I went.

I kept on checking for the time, glancing back at Brett. He was eventually getting into small talk with the other facilitators of the event; the faculty staff from College of St. Benilde (CSB).

Oh, good, good, looks like Brett is getting distracted from checking the time. More time for me!

Brett Bibby (left), and Patrick Williamson (right) of Unity Technologies

So I had my player ship moving and shooting, some enemies continually spawning, some particle effects, and I was about to finish some simple powerup feature when Brett called time.

Mine got looked at first, and pretty much the mistakes I did were:
  1. If you are continually moving something (via code) that has a collider, you always, always will want to put a kinematic rigidbody on it. Failing to do so will cause Unity to be forced to recompute the whole world's static collision data.
  2. Do not instantiate while in the middle of the game. Allocate everything you'll ever need at the loading screen or startup only. i.e. use a resource pool. Regardless if this is a mobile or desktop game you will want a resource pool. The enemy here is Mono's garbage collector. Unity is still in the process of updating the version of Mono that they use. In the meantime we're stuck with the old version (Mono 2.6) which reportedly has a slow garbage collector. [1] [2] [3]
The red line shows how bad Mono 2.6's garbage collector is.
The blue line shows the new garbage collector since Mono 2.8.

Point number 2 was understandable because I can't divide my attention at making a resource pool and the game's code and still complete in one hour.

And so point number 1 was really my mistake there. And Brett said, "Don't worry, even I forget sometimes." The problem also was that you'd only notice this if you have the Profiler, which only comes in Pro.

The effect then, is that people using the free version don't know why their framerate gets so low at times, and in effect they may get the wrong impression that Unity is slow.

Brett was actually wanting that some form of warning be made when the user makes this mistake (a message in the console, some explanation on the user manual perhaps, etc.). They're still arguing about how to go about it, it seems.

NCarter in the Unity IRC chat recommends people read up on the Nvidia PhysX User Manual. Since PhysX is what Unity uses, it will clear up a lot of mysteries for the common user if they read how PhysX works.

The only other mentor who I was with, Charles Cue, did a cool job too. It was about feeding food to a dragon, all in cubes and spheres, yes, but that was the idea. It reminds me of Papo & Yo.

Charles Cue, one of the faculty staff and mentors of the game jam.

The marshalls did an ok job too with the one hour hackaton, some were understandably struggling but they all got somewhere at the very least.

Brett gave some final tips for us:
  1. These students who are entering the game jam? They will almost always want to use physics. The problem is that they will likely misuse it and you will end up with something that you might as well throw away. You need to explain the gotchas of combining physics with user-input and animation.
  2. Sometimes they will ask how to do some particular thing which sounds rather strange. The proper thing to do is to ask "Wait, what are you trying to achieve in the first place with doing this?". And they go something like "Oh it's because I want to build a bridge that breaks." And then you realize "Ok, what you were asking for? That is totally not what you need to do to make a breakable bridge. You can forget about that. You need to do this instead..." and they realize they were needlessly doing things the hard way.
He then explained some intricacies with the Unity engine.

When Unity gets memory to use, even when garbage collected in Mono, Unity NEVER releases that memory back to the OS. Naturally when the Unity game closes, only then will it get released.

Apparently, this is actually a feature of any professional game engine: you will always want to allocate everything you'll ever need in a loading screen first, and never do any memory allocation while in the middle of the game proper. This is to ensure a reliable framerate for the game.

Second, things you know about .NET do not necessarily apply with Unity. For the simple fact that Unity uses Mono, and not .NET. Structs always get allocated in the stack? Not in Mono (ergo, not in Unity).

Thing is, in Mono, whenever you use the new keyword, that will always make use of the heap (memory allocation). If you're in Update(), you will not want to initialize a Vector3 with new Vector3(0,0,0) because that will make use of the heap.

Instead, use the handy, or, if you need to give some specific values, do this for example:

Vector3 myPos;
myPos.x = 345;
myPos.y = 0;
myPos.z = 23;

Don't worry, a struct (like Vector3) can never be null, so this is fine. While it is admittedly a little more wordy (what used to be one line is now four lines of code), it will actually be faster this way. The point is, just don't bother with using new if you're in a tight loop (i.e. Update).

I'd like to clarify that this issue with new is because of the way Mono works, not necessarily something Unity Technologies directly chose to do.

They argue about this in length in this Unity forum thread, and here's some tips on the user manual.

That's it for now, I think this blog post is long enough as it is. In part 2 of this post I'll explain what happened in the game jam itself and share some more photos I took. Part 3 explains how the jam ended.