Unity's Source Code Control System Bug

You can stop banging your head against the wall because you've had to revert for the 8th time this week. Your co-worker, remote development group, or whomever it is that keeps overwriting your code is actually not at fault (well, most probably not at fault). We have confirmed that at least three other dev firms are running into issues with 2.6's SVN support.

If any representative from Unity is listening, pretty pretty please patch this bug!

Here's the update that I received from our CTO:

"I interviewed someone yesterday who said he ran into exactly the same problem that we did. Even more telling, I had a phone conversation with someone at a game development studio called ******* (they did *******, among other games; there are approximately 60 employees there) and they have not only run into this same problem (although in their case it was using Unity with Perforce) but also, in conversations with Unity about the issue, were told that Unity is working on fixing the problem."

I can't find any public comment from Unity on the Bug... Anyone?

The Two Pizza Paradigm

What is your ideal team size? I'm going to side with Jeff Bezos...

"two-pizza team": If you can't feed a team with two pizzas, it's too large. That limits a task force to five to seven people, depending on their appetites.

My new agile mentor Mike Cohn explains why this works:


- There is less social loafing

Psychologist Max Ringelmann coined the concept of Social Loafing, aka the Ringelmann Effect, in 1913.

[wikipedia on Ringelmann Effect] "...the lack of simultaneity of effort in groups, which interferes with efficiently combining individual inputs."

In other words - this concept explains the tendency that individuals have in larger groups to exert less effort because they believe that the mass will overcompensate for their minimal exertion.

- Constructive interaction is more likely to occur on a small team

Mike cites Stephen Robbins here:

[Stephen] has concluded that teams of more than 10 to 13 people have a difficult time establishing feelings of trust, mutual accountability, and cohesiveness. Without these, constructive interaction is difficult (2005, Essentials of Organizational Behavior)

- Less time is spent coordinating effort

This is a no-brainer... More bodies = More logistics. Trying to herd 10 people is exponentially more challenging than half that.


- No one can fade into the background

Yes, yes, and Yes. I don't know if you believe that humans are innately evil or good... but I believe that they're innately lazy. Let me ask you a question. What would you do with $1,000,000.00 lotto winning? Most folks that have taken my informal poll answer something to the effect of... "move to an island." God love them but most humans are lazy or at least exhibit laziness when given the chance.

- Small teams are more satisfying to their members

I concur. You get to feel like you're moving the needle. When you're just one of many, the joy and accolades of your accomplishments can get lost in the clutter.


- Harmful over-specialization is less likely to occur

I'm a fan of the generalist. Why not know as much as you can about numerous subjects?

Unity 3D Terrain Tutorial

Here's a quick tutorial, created by Will Goldstone, that teaches you how to create an island terrain:

Video tutorial on creating a terrain in Unity 3D

It goes over adding/customizing a particle effect, adding a lightbox, adding a First Person Controller, & Etc. The presenter has goes over each aspect at a great pace. Kudos to you Will!

Here's the exact syllabus:

PART 1 covers creating a new project and exploring the interface.
PART 2 covers terrain extrusion and texturing.
PART 3 covers Trees and further environment topography.
PART 4 covers Lighting & First Person Control. In this part we introduce the First Person Controller, a ready made prefab allowing you to walk around using the keys and mouse, and lighting the scene.
PART 5 covers Water Elements and Light Flares.
PART 6 covers using a particle system to add smoke to our volcano.
PART 7, the final part covers improving our volcano's particle system by creating a material for the smoke.
This tutorial series is a great way to learn how to create an entire terrain from start to finish including effects and lighting in Unity 3D and is a grea lesson to learn how to use the Unity 3D game engine software.

You can see how mine turned out here:

(use the W,A,S,D keys to navigate)

http://www.jasonleon.com/unityTerrainTest/unityTestIsland.html


Here's a picture if you're too lazy to click on the link:

Ain't she a beauty?


Following this tutorial is a great way to get familiar with the tools that Unity provides!

Story Points

What are Story Points?

Story Points are units of relative size used in estimating software requirements. This is an alternative measurement to time based analysis. Points are estimated by assessing complexity rather than duration. Story points work in conjunction with User Stories.

What are they good for?

Story points are a fantastic way to estimate how long it will take to finish a product. They replace the standard time-based estimate with a more detached concept. Story Point is not the only vernacular around to describe this measurement. Some XP teams also call them cheezits or acorns.

We use story points when estimating for the long term, for instance against the entire product backlog. It's not a good idea to use them in planning for a particular sprint, as sprint velocity will vary.

Good quote from Mike Cohn on Velocity,

"This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.

Velocity will bounce around from sprint to sprint. That’s why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning."

How to Prioritize Your Product Backlog

After watching Mike Cohn of Mountain Goat Software speak on the subject, I thought it would be useful to jot down my takeaway as well as some screen caps of the presentation:

(If you're new to scrum, here's a quick video primer on the topic of the history of scrum and its components...)

User Stories - Short to epic statements told from the perspective of the user.



The Iceberg - A pyramid of backlog items which appear in groups of small Items at the top and larger scope items in the middle and bottom.



Kano Analysis - The process of using exciters/delighters, linear, and mandatory features to adjust the priority of features in the product backlog.



Kano Analysis Process - Here's a glimpse of what the process looks like in action...



Theme Screening - Identify the selection criteria for what is important and evaluate against the baseline (mandatory) features.




Baseline Theme - The baseline theme is one that is likely but not guaranteed to be included in the upcoming release.

Theme Scoring - Similar to Theme Screening but avoids category compression by adding a weighting system. Doesn't have a single baseline theme but instead offers reference themes per attribute.




Relative Weighing - a prioritization approach that considers both the positive benefit of the presence of a feature and the negative impact of its absence.



Other Neat Recommendations that popped out:

- spend 10% of each iteration (sprint) working on the next iteration

- avoid including backlog features in the sprint that can not be encapsulated

- groom the product backlog often

- survey of 20-30 users is large enough to qualify as a quick representative sample

Problems with the Lock-Modify-Unlock Solution

As I investigated TortoiseSVN for the first time, I came across their explanation as to why they prefer the Copy-Modify-Merge Solution over Lock-Modify-Unlock. Here's what they had to say:

Courtesy of TortoiseSVN help files:

Consider this scenario: suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost - or at least missing from the latest version of the file - and probably by accident. This is definitely a situation we want to avoid!


The Lock-Modify-Unlock Solution
Many version control systems use a lock-modify-unlock model to address this problem, which is a very simple solution. In such a system, the repository allows only one person to change a file at a time. First Harry must lock the file before he can begin making changes to it. Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then Sally cannot make any changes to it. If she tries to lock the file, the repository will deny the request. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, his turn is over, and now Sally can take her turn by locking and editing.

Figure 2.3. The Lock-Modify-Unlock Solution





The problem with the lock-modify-unlock model is that it's a bit restrictive, and often becomes a roadblock for users:

Locking may cause administrative problems. Sometimes Harry will lock a file and then forget about it. Meanwhile, because Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an administrator to release Harry's lock. The situation ends up causing a lot of unnecessary delay and wasted time.

Locking may cause unnecessary serialization. What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don't overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There's no need for them to take turns in this situation.

Locking may create a false sense of security. Pretend that Harry locks and edits file A, while Sally simultaneously locks and edits file B. But suppose that A and B depend on one another, and the changes made to each are semantically incompatible. Suddenly A and B don't work together anymore. The locking system was powerless to prevent the problem - yet it somehow provided a sense of false security. It's easy for Harry and Sally to imagine that by locking files, each is beginning a safe, insulated task, and thus inhibits them from discussing their incompatible changes early on.

It's common sense but a nice reminder as to why a merge solution is superior. You can read about their explanation of the Copy-Modify-Merge Solution here.

FreeRealms Age Breakdown

FreeRealm's has done a fantastic job of hitting their target demo. Check out the breakout that John Smedley shared with the folks at the Austin GDC:

Sid Meier's Talk at GDC

Well, not really Sid... Here are some notes that Matt Bowman took while at Sid's talk at this years GDC. I have to agree with a lot of Sid's stances. Some great observations here.

The winner paradox
Keep winning percentage abnormally high. In real life, not everyone wins. Only one of the 25 teams in the NBA can win the championship, but not so in games. The player is looking for a satisfactory conclusion. Developers should make sure players win big and win often. Skew the “winning percentage."

Reward vs Punishment.
Players like to find gold coins. Players are very inclined to accept anything you give them and think that’s the result of their own merit. If you punish bad behavior, the game is wrong, it’s cheating, players think. When there’s a negative consequence, it’s important that the player understand why that’s happening and how to avoid it next time. If you can emphasize that “next time” aspect, you increase replayability. Antime you can plant the seed of replayability, do it.

Also, the first 50 minutes have to be really cool. Let them know they’re on the right track. Cool stuff is happening and even cooler stuff will happen later on. In the first 50 minutes, you almost cannot reward them enough.

Difficulty Levels
I used to think we needed four difficulty levels. Apparently, I was wrong; we need nine. The reason we have these levels is to create a sense of progress. There always need to be more challenges. Desiring to make it to the next level enhances replayability.

You always want your player to feel they are above average. They are doing well, and they will probably do better.

The Unholy Alliance
This defines the relationship between the player and the designer. I’m going to pretend certain things; you’re going to pretend certain things, and together we’ll have fun. The terms of the alliance are as follows:

1. I’m good! (the player). Designers went off track with more and more realistic plane simulations: realistic crashes created the impression “I’m not good, my plane is on fire and I’m falling out of the sky.” Keeping them feeling good about themselves is an important part of the designer's role.

2. Suspension of Disbelief. The player needs to inhabit that character. That’s his part of the bargain. When my wife comes out of a movie and I ask what she thought of it, she says things like “I came out of that movie twice” or "I never got into it," or “never came out of it.” Players need to stay “in it” and designers need to help them.

3. Moral clarity. Imagine you are conquering cities. You have one town left to occupy, you outnumber them and can squash them in a second… but they’re defiant! It would be more realistic if they wanted to surrender and asked for pity. But that would put the player in a moral dilemma—you always want the player to feel he is making the right decision by continuing to play.

4. MAD: mutually assured destruction. The Cold War balance of powers is paralleled in the player-designer relationship. Players can play in all kinds of ways that destroys the experience. Designers can do the same. You need to keep the balance to maintain the suspension of disbelief.

5. Humor/ Style/ Music/ Atmosphere. If you start with lighthearted music and cartoony graphics, then all of a sudden heads start exploding, you’re not living up to the alliance. You don’t want to fool the player. To help the player maintain his suspension of disbelief, you need to consistently keep the player in your world.

Math 101
Often games give odds for the player’s chances of defeating a foe. For example, the Attacker Player has a 1.5 score and the opposing Barbarians have a 0.5. There’s a 3-to-1 chance that the Attacker will win. When polled, however, players thought they should always win when they have a 3-to-1 advantage, but weren’t surprised when they would lose if they were at a 1-to-3 disadvantage. Around 3-to-1 or 4-to-1 advantage, players expected to win every time. So we adjusted the computer to appease the player.

Players felt they could lose a 2-to-1 battle every now and then. But they had a problem if they lost a 20-to-10 battle. So we adjusted, and asked, “Now are you happy?” “Well kind of, but there's one more thing: I had a 2-to-1 battle and lost, which was fine (we went over that). But right after that, I had another 2-to-1 battle and lost again—how can that be!? The computer’s out to get me, obviously!” So we made sure that occurrence wouldn’t happen, and the player was happy.

When something happens that feels wrong (even if it isn’t), we start to lose the player’s suspension of disbelief.

My Bad (errors Meier made)

* Real-time Civilization. When we introduced real-time play with others, the player became an observer of other players. The game’s mantra was “It’s good to be king.” We needed to put the player at the center, so we took away real-time action.

* Rise and Fall. We thought, “Wouldn’t it be great if you are crumbling and just at the last minute before all is lost, you come in and save the situation and then rise again to an even greater status than before?” No. Players would reload at the cusp as things start to go badly. They would never experience the comeback, so Civilzation is a game of progress only.

* Don’t Randomize. Players want to be in control. Whenever anything random happens to the player, paranoia sets in. They feel the computer rolls that random number to make their life more difficult. Random events at a large level have to be treated very carefully. Low level randomization can help things seem more realistic, but if they are large events, players come up with worst possible explanation for it.

* Civilization Network. This network is built on the Facebook platform, and is social. We played with idea of being able to give gold to other players. They could trade or beg or give out of pity if they wanted. What we found was that nobody ever gave gold to anybody else.

under 13 sign up process of FreeRealms

The CEO of SOE gave the keynote for GDC Austin and, in it, he went over a lot of very useful info about their trials and tribulations.

One thing that was interesting, a larger % of kids <13 do not know what year they were born!

I've created a side by side comparison of the changes that SOE made to their sign up screen which took them from 60% success rate to 90%.

You can hear the keynote, if you're interested, by visiting www.gdcvault.com.

Topography of Space

Basis of Spacial Design

A unit of measurement must be defined before you begin construction on a 3D game. So what do you design this metric around? The potential chicken and egg of game design is to design around the avatar or the geography. Consider this from Richard Bartle's Designing Virtual Worlds:

"The religious view of the real world is that one or more deities created it. Normally, the deities put the world together before introducing humans into it (rather than creating both at once or the humans first). However, from the beginning, the deities intend to populate the world, and therefore design it with the humans who will live there in mind.

For the real world, you should decide for yourself which of these views is the more correct. For virtual worlds, discount the first one. Deities create virtual worlds; designers are those deities."

Linear Working Units

As far as my research has stretched, it's best practice to measure via the metric system and, for god sake, use meters not centimeters or decimeters.

That said, here's what I ended up with for MyMiniPeeps at the end of the day:



With this in tow, the sky is the limit! Now you can describe the geometry of interiors, stairwells, doorways, and etc! I definitely do not recommend starting any asset creation until you have decided on and COMMITTED to the bounds of your avatar.

[Note: As you see in my graph, I've left room for bulky accessories. My game requires loads of customization. Yours may as well so remember to plan for them.]

Other things to consider...

Does Size Matter?

How large should a virtual world be? My vote, it should be as large as it needs to be in order to be entertaining. If you build a giant map with nothing to do then you'll bore your audience. If you build a small map and don't shard, then you'll frustrate your audience (not to mention you'll overload your servers).


Speed's effect on Size

We must consider how fast our avatar's move in order to really comprehend how large our world will feel. Feel is different than the actuality of the geometry. Consider this passage also from Bartle:

"Speed of travel affects size: If it takes you half an hour to traverse one virtual world and two hours to traverse another, the former may appear to be smaller than the latter even if it isn't; if you can teleport anywhere, the world will feel smaller still."

This has been an exercise to investigate various ways of capturing a spacial definition. I hope you've enjoyed our journey. Seriously, if you take anything away from this blog make sure that it's this... Plan ahead when it comes to your unit of measurement and your avatar's bounds. You'll be happy that you did.

Preventing Burnout

This was pulled directly from wikipedia and is certainly worth the read. In the start-up world as well as in game production you need to be aware of what keeps a team fluid and happy. Burnout is a genuine concern. My vote, burn the candle at both ends when necessary but make sure to enjoy the process and be true to the "work hard and play hard" adage.

Preventing burnout

While individuals can cope with the symptoms of burnout, the only way to truly prevent burnout is through a combination of organizational change and education for the individual.^[11] Organizations address these issues through their own management development, but often they engage external consultants to assist them in establishing new policies and practices supporting a healthier worklife. Maslach and Leiter postulated that burnout occurs when there is a disconnect between the organization and the individual with regard to what they called the six areas of work life: Workload, Control, Reward, Community, Fairness, and Values.^[12] Resolving these discrepancies requires integrated action on the part of both the individual and the organization.^[13] A better connection on workload means assuring adequate resources to meet demands as well as work/life balances that encourage employees to revitalize their energy.^[14] A better connection on values means clear organizational values to which employees can feel committed.^[15] A better connection on community means supportive leadership and relationships with colleagues rather than discord.^[16]

One approach for addressing these discrepancies focuses specifically on the fairness area. In one study employees met weekly to discuss and attempt to resolve perceived inequities in their job.^[17] This study revealed decreases in the exhaustion component over time but did not affect cynicism or inefficacy indicating that a broader approach is required.^[18]

Stop Unity Player Browser Flicker

We ran into this problem and found a nice fix care of Russian Madman on the Unity forums:

http://forum.unity3d.com/viewtopic.php?p=247286#247286

Communication for a remote team

I've been producing a new Virtual World, utilizing, Unity 3D for close to seven months now. This is one of the most challenging satellite operations that I've been a part of. Our development pipeline touches down in Chicago, San Francisco, Mexico, China, Los Angeles, Naples (Florida), Orange County, and Sacramento! Suffice it to say, the time zone are killing me!

Keeping a team, such as the aforementioned in sync, requires more than one project management solution. Here's a list of the tools that we've attempted for better or for worse:

Basecamp

I can't complain about basecamp as project management tool. The file section has proven very valuable for disseminating assets as they are turned in. The message threads also work pretty well for giving notes on art assets. Rarely, the todo and milestone sections find their way into use. Not sure why that hasn't taken off. Perhaps this could be a separate post.

Fogbugz

There are tons of bug tracking solutions out there. Ours is Fogbugz. It works but is nothing to write home about.

Internal Wiki

We use tiki (http://info.tikiwiki.org/tiki-index.php). Sadly, this was only recently introduced as a means of recording/sharing information so I can't really report all that much.

Email Lists

We have various email lists (engineering, All staff, etc.). These are useful for blanket spam and rarely result in a positive outcome. However, if you want to fill an inbox, utilize ASAP.

IM/VOIP

In projects past, I've separated my IM from VOIP but for this particular project we all settled on Skype. Skype has proven very effective for state of the union calls or for the quick hash out.

Excel

Probably the least dynamic of the editable tools at our disposal. We all keep various excel sheets of various tasks at hand. These sheets are occasionally passed back and forth but are certainly one of the most antiquated means of info transfer.

Cell Phone

Skype is not, unfortunately, a one stop across the board for reaching all members of the team.

Text Messaging

Text messaging is used when someone is late for a conference call and is not at their computer.

Conference Calling Service

Occasionally, we'll need to book a room with the folks a free conference call dot com.

Meeting Scheduling Service

Can't forget about Time Bridge! This is a gem of a service. Definitely try them out if you haven't.


Off the top of my head, there you have it. *bows*