The objective of my project was to develop a toolset for the Unity Editor which would streamline and improve the workflow involved in creating realistic terrains for games. It contains a range of
'filter' style tools which allow a Unity artist to easily generate, erode and texture terrain objects.

I worked on the project alone, but had help along the way – both from developers who were willing to share bits of code and of course support from the Unity team.

I actually don't have a background in game development as such. I started out my career as a designer, mostly focusing on editing, motion graphics and visual effects. I later switched into working
in digital and I currently work in the role of Art Director at Amnesia Razorfish in Sydney where I've been involved in the creation of quite a few Flash games for a number of high-profile clients
including Microsoft, Pepsico and Smirnoff.

I’ve had an interesting in creating games for a long time. I grew up with a Commodore 64 and I remember reading books about coding in BASIC, but none of it really made much sense to me at
the time. I wrote my first actual working game in Director about ten years ago while was at university and started to get more seriously into game development about 3 years ago. I've been using Unity
for the last 2 years.

The idea behind the project was to enable indie developers to create large scale, realistic and playable game worlds within a short time span. I think procedurally generated content is a great
solution, particularly for indie game development projects with limited time, budgets and human resources.

Unity already has a great terrain engine as one of its core features - I believe my project expands on this by providing the user with the ability to rapidly create a variety of different
landscapes directly within Unity without needing to use third party software. An additional advantage is that landscapes can now be generated dynamically at runtime. This means a Unity game can have
a potentially infinite number of levels with a negligible impact on the file size.

Unity is a game engine with a clean and very user-friendly integrated development environment. I think its strongest feature is in its flexibility. On one hand it allows indie game artists and
developers to jump in and start actually creating a game without a long and time consuming learning process – instead it encourages you learn as you create. On the other hand, it does this
without becoming oversimplified or by losing any of the more complex features that one expects from a game engine and therefore is a viable solution for small and middle sized teams to develop
commercial games.

When I started looking for game engines, everything seemed to be very much focused on the PC platform only. I did try Torque, but found the learning curve too steep and didn’t make much
headway, especially due to the need to learn C++ which I had never used before. Unity on the the other hand was available for the Mac platform and was quite easy to get into and start using,
especially as I had prior experience in Flash development – Unity JavaScript being structurally quite similar to ActionScript.

I also like the fact that it was originally developed for the Mac platform, rather than ported from a PC product. Previous to the release of Unity 2.5 it got a bit of criticism for being limited
to Macs only, but when you look at the software now and see the attention that has been given to the interface, the workflow and the user experience, I think you can really see the great benefit that
a Mac-centric design influence has brought to it.

I develop for Mac and PC. I haven't really delved into the iPhone side of things quite yet, but I definitely intend to. I’d also really like to have the opportunity to develop for the
Nintendo Wii in the future.

I’ve had an interest in game development for quite a while and I thought the Unity Summer of Code was a great opportunity to get more involved in the game development community as well being
as a chance to get my name out there.

Yes, for sure. Though, it probably would have taken a lot longer to complete.

I was a bit surprised. I don't think I really expected to be one of the successful applicants. I think it was a great opportunity and I'm really keen to see the response of the Unity community to
my project as well as the projects developed by the other participants. I'll definitely be looking into how I can benefit from using their Summer of Code projects in my own games.

I began the project by prototyping some of the more basic erosion scripts. These scripts were originally implemented as ‘wizards’, but once I had a system in place for applying various
kinds of filters to terrain objects, I later turned them into filters which could be run directly from the component inspector. I then focused on creating a usable interface for the toolkit and began
working on and adding the various planned features.

As early on as possible I integrated features that were fundamental to the usability of the tools such as quality settings, a progress bar to give the user feedback on the application of filters,
as well as features such as the brushes. Throughout this time I continued to work on, test and optimise the existing erosion scripts as well as constantly testing new ideas and methods for erosion
using more advanced techniques such as velocity fields. I also added the generator tools, which allow for the creation of base terrain using Voronoi, fractal and Perlin noise algorithms. It was quite
late in the timeline to add completely new features, but I think the value they added to the project far outweighed the investment in time.

Towards the end of the project timeline my main focus was refinement of the existing features and writing documentation for the tools, including a scripting reference for the runtime API.

A bit of both really. I scoped out most of the features before I started and for the most part I stuck to that plan. However, there were definitely a few completely new ideas that found their way
in to the final version.

For this project the testing process was continuous. All of the erosion and terrain generation filters were tested extensively as I refined them. I also wrote some additional code to visualise
erosion data such as terrain height, water flow and velocity fields, which were exported as image sequences so I could really see what the filters were doing to the terrain heightmap at each
iteration.

Not really, and looking back I think I really should have done so more. Aside from another Unity developer I work with and the guys at Unity, no-one else really got to see it. I did get some
assistance indirectly from a couple of other developers who shared some of their code. This meant that I didn’t have to write fractal and Perlin noise algorithms from scratch, which was a big
help.

I think pretty much everything in the early stages of the project went quite well. All of the basic features like getting the simpler erosion filters working and creating a user interface for the
toolset got completed in less time than I had originally expected. After that everything started to get a bit complicated!

Unsurprisingly, I struggled in trying to understand computational fluid dynamics – shallow water models, Navier-Stokes equations and so on. Without a degree in physics, I didn't get very
far. It was too ambitious for such a short time frame. I hope to revisit this in the future to come up with a better solution for hydraulic and glacial erosion.

I also ran into problems in capturing mouse events. I was pretty unhappy with the solution that I had to use for applying erosion brushes. I hope this will be one of the first things to get fixed
in the first update.

I would do more research in the early stages of the project. As it was, I did some research to start off with, then jumped into writing code and only got back to looking at the research side of
things again quite late in the project. However, by this time there wasn’t really enough time to implement anything new that I was able to learn.

The tools for generating base terrain weren’t part of the original scope of the project, but I think they really added a lot of value to the end product and really helped to create an
integrated solution for creating terrain. If I were to do the project over, these features would definitely stay in.

Learning how to create custom component inspectors for the Unity editor was quite cool. My job (during daylight hours) involves a lot of interface and user experience design, so it was satisfying
to be able to utilise the full extent of Unity's Editor GUI to put this knowledge into practice.

Writing the documentation was probably the least fun part - tedious, but necessary.

I have enough commercial experience (including some bad experiences!) to know that I needed to start out by setting realistic deliverables for the project. I divided my feature set into 'must
have', 'should have' and 'nice to have' features and agreed on a minimum number of deliverable features with the guys at Unity. While I ended up both exceeding the minimum amount and delivering a
couple of originally unscoped features, there were still some features that never made it in, mostly due to their high level of complexity. I will definitely continue to support the project with
improvements to existing features as well as the addition of new features. Destructible terrain is something I’d really like to see in a future version.

I really wanted to find a better solution for hydraulic erosion that was based on real fluid dynamics but as I discussed before, these simulations were far too complex to include within the time
span, they would be a whole other project unto themselves.

I can’t stress enough how important it is to scope the project properly. Set yourself or your team realistic and achievable goals, particularly when there’s a client involved.
It’s far better to under-promise and over-deliver than to over-promise and under-deliver.

Unity is a great environment to work in and though it has a reasonably smooth learning curve – like all software it takes time to really get proficient at it, so this was definitely a
learning process for me. I think the main challenge in creating tools for other people to use is getting the interface design right. The things that are second nature to you as the developer will
probably not be so obvious to other users. For this reason I probably spent only half the time working on the erosion, generator and texturing code and the other half was all about the interface
elements.

Yes, definitely. If I create something that is useful within my own projects, then I’m sure that it may be helpful to other Unity users as well. Also, I think there is a real advantage in
creating tools and features for games in an ‘add-on’ format. This means that the features will be easily portable and the features they provide will be more high-level rather than being
too specific to single game.

Our main line of support for the Unity Summer of Code was an email mailing list. The benefit of this was that everyone was able to see the challenges that were being faced by other participants
and be able learn from them. It also meant that most of the issues we ran into were resolved pretty quickly.

I will continue to work on and improve the Terrain Toolkit, but first I’m keen to hear the response of the Unity community to the tools I have developed, as their feedback will definitely
affect which features that I add or improve. Other than that, my main focus will be on other projects including getting back to work on a game I have had in production for a while. I also have plans
to release one of the planned features of this game as an add-on for Unity. It's a procedural combat animation system, which should be quite cool – if it works.

Possibly, but I'd also be very keen to see what great ideas other Unity developers can bring to the community.

I'd just like to thank the Unity team for giving me the opportunity to get involved in this project, and I also want to thank the community for being so supportive of this great piece of
software.