Unite 2010 took place in Montreal, Quebec, Canada.  The following are some notes about the conference.

Venue and Logistics

The conference was held at the Marche Bonsecours, which was a great location.  The only problems with it (and the logistics of the conference) were with seating, both at lunch and during some of the advanced sessions.  In both instances, I found myself at least once sitting on the floor.   Hopefully, this was a result of the 2010 conference being more than twice the size of the 2009 version and will be fixed for next year wherever the conference is held.

Both breakfast and lunch were provided at the venue during the conference which made networking a bit easier.  Without the option to stick around the venue for meals, it is easy to end up with a small group to eat with and not meet as many people during breaks.  I met several people as a result of hanging around the Marche Bonsecours at lunch and breakfast.  In addition to these times, there was a short break between the afternoon sessions.  Before arriving, I thought these might be boring as I would be sitting around waiting for the next talk to start (checking Twitter or doing something else just as productive…).  However, I found that these times offered me a chance to relax, prepare for the next talk, and discuss either the previous or upcoming talk with fellow developers.

Sessions and Hands-on

I won’t talk about the individual sessions (they should be available at Unity3d.com soon), but overall, the talks were quite informative and at an appropriate level for me.  Some of the more experienced developers at the conference indicated they would have liked more depth in the advanced talks, but for me, the advanced talks gave me some ideas about how to tackle current problems and shed some light on topics I hadn’t considered before the conference.

One of the other main attractions of the Unite conference is the hands on time attendees are able to get with the creators and developers of the Unity software.  For me, this alone was worth the registration cost of the conference.  What made this truly worthwhile was the enthusiasm the developers had while helping me.  Despite my inexperience (I’ve only been working with Unity for about 6 months, 3 of those part time), I never felt like a question was too simple or easy to solve for those helping out.  When we ran out of time fixing a particular problem on day one, the developers made sure to book me some additional time on the second day to finish finding a solution.

Unity in the future

In addition to the growth of the Unite conference year over year, the attitudes of the Unity employees I met and heard speak at the conference gives me confidence that Unity will continue to improve rapidly.  It was evident through several of the sessions that despite the recent improvements to the engine, those at Unity realize that there are a great number of additional features and fixes that can make Unity even better.  Critically, the company seems to be taking input from the community of users seriously in considering which of these should be tackled first.

After this experience, I’m already looking forward to Unite 2011.

The first example of this came when my colleague decided to mock-up a martian landscape.  We had been discussing using a martian landscape with a space station as the main setting for weeks.  Seeing the basic landscape allowed me to consider the finer details of the scene instead of just the big picture.  It also assured that the picture in everyone’s mind for this space station was nearly identical, rather than the unlimited possibilities we leave open by simply discussing it and not having any visual representation.

The second major breakthrough came when I was able to convince my boss that having controllable 3D characters was a perfectly reasonable possibility for this game.  At one point, we were debating having much of the story happen through comic strip-like interludes with text possibly supplemented by movies.  But with Unity, I found it was not much of a challenge to put together a control and camera scheme for any 3D model that we have.   I thought perhaps my boss was simply more fond of the movies/comic idea than having controllable characters until I showed her a demo with a controllable character having a discussion with an NPC (non-playable character).  She then informed me that she previously was concerned that controllable characters would have taken more time than we would be able to allocate.

Giving visual representation to ideas can serve two purposes in software design (games or otherwise):

1.  It gives your team a unified representation of the visual object you are discussing.

2.  It proves that the idea can be put into action.

In creating the dialogue between the playable character and the NPC, I presented a basic paragraph about Mars (borrowed from the wiki entry), then presented the user with a question and the ability to offer 3 answers, each with its own response from the NPC.  While the code for this would be quite inefficient for a larger dialogue, I have proven that dialogue between characters can be done in a short time. While I’ll need to tackle the dialogue problem in the near future, this prototype demonstrated to my boss that player controllable characters can be used to do nearly anything we require in order to convey the story.  With only a few hours of work, I was able to settle a debate we had been having for months.  Even if this wasn’t what we wanted, having this decided for only a few hours of work is certainly worth the small investment.

In order to get familiar with the Unity engine, I followed two tutorials I found in the Unity forums. The first was a basic shmup.

The second tutorial was a redux (in C#)  of the first plus an extension that included models for the ship and asteroid.  While I followed along with this tutorial, I decided to keep everything in JavaScript.  This helped me to clarify some of the elements of the Unity engine independent of language.

After completing the tutorials, I decided to extend the game a bit to include bombs, more asteroids and large asteroids.  As of this writing, I haven’t made final decisions for how to complete the game (whether it will be a score the player must or a set time limit), but the current version can be found here:

http://programmingmylife.com/spaceShooter/spaceShooter.html

Unity makes the process of uploading any game you build in the engine to a website incredibly easy.  When making a build of a game you simply have to use the following settings:

File >  Build settings > web player      (make sure to include all scenes)

When you build the game it will create a *.unity and a *.html file (the * represents the name of the game that you set).  Assuming your web host knows what to do with the .unity file, you can simply upload the two files and the game will run at that web location.  If, like me, your web host doesn’t support the .unity file format likely this will cause your browser to fail to download the content.  I received an error on Chrome stating ‘Failed to download data file’ with details ‘Download failed, try again’, but on Firefox, the download status simply stayed at zero. To fix this,  you will simply need to include in the directory with the .unity and .html file the following in a file called web.config:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>
    <system.webServer>

        <staticContent>
            <mimeMap fileExtension=".unity3d" mimeType="application/vnd.unity" />

     </staticContent>
    </system.webServer>

</configuration>

I was able to find these instructions from this query at Unity Answers.  Unity Answers is a great service that runs in addition to the Unity forums.  These two complementary services along with the users give Unity a strong community that should allow users from novice to advanced to find answers to any problems they might have.