How to Survive a Game-Dev Event

How to Survive a Game-Dev Event (for Indies that Pay Rent)

by Tanya X Short on 04/02/14 12:25:00 pm      

---

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

---

Tanya X. Short leads 4-person Kitfox Games, who just released Shattered Planet on iOS.
GDC’s over, but PAX looms on the horizon. Any other collection of 3 letters could be close behind. The string of events and meetups and conferences never end. You may feel a crushing pressure to perform at each of these, especially if you’re an indie with rent that needs paying and food that doesn’t buy itself, like me. You're spending money and time and energy that could go towards making your game.
You need to justify the cost.
But that pressure can make you do dumb things. You'll be tempted to act selfishly, cowardly, be indecisive, or run away. So here's a few things to refer back to, when you feel your heart start to beat just a little too fast.
You probably already agree with the things written here in principle (they were inside you all along), and the big’n’famous names have been using em for ages now. Even so, I consider them best practices, worthy of a reminder now and then.
At the risk of being a self-parody of my own 50 Easy Steps to Indie Success, I have to note that your mileage may vary.

The Scene

I was enjoying GDC 2014, having meetings and playing cool games and sharing drinks with great people.
Then, on the second evening, there were two different parties that I needed to attend: a chiptune concert where literally all my game-dev friends would be (some of whom I hadn’t seen in years), and a publisher party, where I was hoping to make a connection and find some work-for-hire for my company so we can survive until our next major release.
A tiny indie sat on one of my shoulders, chiming: “You’re not a corporate lackey, are you? Your friends deserve your time and respect! You have to show you care about them or they'll forget about you! Plus, your personal hero is going to be there!”
On the other shoulder, a tiny CEO chirped: “How selfish can you be? Kitfox Games depends on you to look out for their best interests, and you just want to burn money dancing in a club and getting drunk with your friends? Unprofessional.”

No matter what, I would be losing out. I could feel my blood pressure rise and I began to hyperventilate.

Survival Tip 1: Chill the F*%& Out

Events are full of opportunities. Every meal, every session, every lobby, every hallway, is crowded with potential new friends, business partners, and collaborators. The human mind cannot possibly comprehend the fractal of alternate universes that are spawned every second of every conference.
Furthermore, nobody can help you with your priorities. You'll be torn in five different directions. You're in a unique position and have to make the best call you can, given the information you have. You can't possibly know exactly what the best combination of decisions is, but nobody else can make a better guess than you can, either.
Don’t try to min/max it too much. Trust yourself.
The only way out of analysis paralysis is to take a deep breath and then act. Let the logical part of your brain do the best it can and in the long-run, it will work itself out. You’ll miss a few opportunities along the way, but that’s how it is. Breathe, think it through, weigh the pros and cons, and let it go.
You can do anything, but you can’t do everything. Accept that.

Survival Tip 2: Be Giving
 

Some people you know are already your friends. They’re people who are cheering for you, hoping your games do well, and maybe even putting in some effort to help make it happen.
These people deserve more than just gratitude; they deserve your respect and mutual support. They’ve been earning it for weeks and months and years, supporting you emotionally.
When I met Harry Lee (Sokobond) this year, he said, "This year, I'm not promoting my own work. I want you to try my friend's game, Push Me Pull You. I have it here in my backpack. Do you want to play?" The selflessness of that gesture -- of taking the value of a self-promotion opportunity and giving it to someone you want to succeed -- touched me, and I think we should all take it to heart.
Of course, just by making friends you'll be promoting yourself. We can't all be selfless Harry all the time. But now is not the time to ask for favors -- now is the time for building better relationships. You’ll want a few petty things (introductions, recommendations, invitations), but it’s far, far better to invest in your future now. Wherever you can, be the giver. Be the supporter. Offer to help others where you can.
If nobody asks for favors, that’s fine; go out of your way to show your appreciation for the kindness others have shown you. It sounds trite, but really do pay it forward. Especially while you're under this crushing performance anxiety.
Psychologically, this is likely to make you happier anyway. It seems Rami Ismail of Vlambeer spends most of his time helping others, and I would bet that the goodwill he's generated is a big part of Vlambeer's success. Real, demonstrable karma. If you want to be completely mercenary, then try to see conferences and events as great times to make brand deposits and not-great times to make brand withdrawals.
This past GDC I didn’t practice this tip as well as I could have, and I asked for a few petty favors that didn't really matter (but felt uber-important in the moment) instead of being my best self. So I wrote this note to myself, so I can improve.

Survival Tip 3: Make New Friends. (Corollary: Be Visible)

It’s not “just networking” -- making friends is legitimately about becoming closer to someone, such that they grow from stranger to acquaintance, and acquaintance to ally (see previous tip).

Be friendly, but be yourself. The more friends you make, and the more effort you put into being visible (so others can approach you), the more you can contribute to the greater community. As the latest corporate shenanigans prove, being a dev means being sincere and true to what you believe.
So get to know these people. Learn about their work. Listen to the words they say. This means that generally, you have to put in effort. Actually learn their name and pay attention to what they’re working on, and be sincere. Be patient. Friendship isn't Kool-Aid mix.
It’s easy to slip into friend-bot mode and just stick your hand out at everyone and try to collect as many business cards as possible, but this isn’t actually to your benefit, as a passing face in the hall will never be a friend.

Survival Tip 4: Not Everyone Will be Your Bestie
 

In the process of becoming more visible and making more acquaintances and budding friendships, you'll realise you don't enjoy the company of some people. Even some people that maybe could be "useful". You won’t like everyone. That’s okay.


People have different priorities and tastes. Accept that. The last thing you want is, as Lana Polansky put it later in that Twitter conversation, is for your friends to feel that "your value is rooted in what you symbolize/how useful you are to us."
I'm not saying shun people you don't immediately click with. You're at a professional event, not a middle school dance. But recognise when you are interacting as Part of a Community (which can be "useful") and when you are interacting as a friend.
The developers-and-such surrounding you in the middle of crowded festival halls and lectures may not all be “useful”, at least not now, and maybe not ever. But if you really try, there’s always something to learn from another person, if you get to know them.
On the other hand, there are times when you have to give in and... feed the beast

Survival Tip 5: Feed the Beast
 

“Feeding the Beast” is a phrase I first heard uttered on the Friday of GDC by Alex Martin, better known as Droqen (Starseed Pilgrim). It refers to when you have to do "real work". You have to do something for the good of your brand/company/product/insert-business-word.
Going to events you don’t care about, or even feel morally conflicted about. Talking with investors. Giving talks. Tweeting when you’re not in the mood. Everyone has their own approach to feeding the beast, but the truth is there: you have to make some sacrifices to power the engine. It can’t run on rainbows all the time. I personally feel I’m feeding the beast when I have run out of the energy to have a sincere conversation, yet continue to “network”.

Don't decline something because it sounds tedious. Don't run away to your hotel room. At least, not every time. Don't cancel meetings because you're nauseous from nerves. Buck up.

Returning to the party-hyperventilation example, I ended up going to both parties. I went to the fun one first, danced around, had fun, and then (slightly bummed) went to the publisher party. I had to “feed the beast”, and ended up meeting a few “useful” people. They won’t be my friends anytime soon, but it’s better than nothing.
This is mostly included as a counter-point to Tip 1. Even without min/maxing every moment of every day, you still have to work. So no matter how you manage to chill and trust yourself, be prepared to be exhausted.
Survival Tip 6: Don't Compete
It was two hours after I had given my GDC talk. After four days of navigating the tight-rope of friend-making and networking, just as my nervous energy started giving out, I crashed. Hard. It was like a sudden, full-body experience of the indie shame spiral.
I wasn’t indie enough, wasn’t connected enough, wasn’t savvy enough, wasn’t tech enough, wasn’t professional enough, wasn’t stylish enough, wasn’t extreme enough, young enough, old enough, anything enough. I felt I didn't belong, because I failed every possible comparison.
Now, of course my thought patterns were unhealthy and self-destructive, regardless of setting, but it's especially easy to fall into that trap in a conference setting. Especially if you let yourself get competitive. Amazing, talented, wonderful people are all around you, and while that's inspiring when you're happy, it can feel damning when you're vulnerable.

To put it another way, feeling insecure and walking into a competitive atmosphere is a recipe for Impostor Syndrome on steroids.

Luckily for me, I went to Lost Levels that afternoon in the park. In addition to dancing to Professor Oak’s music and being inspired/amused/educated by the many brilliant folks giving micro-talks, I was also reassured. My sense of competitiveness faded*. I felt a small sense of belonging, bouyed by the warm sunshine and the fresh springy scent of the grass.

A few days later, when I confessed my anxieties to Damian Sommer (The Yawhg), he said that he felt the opposite. We all should -- seeing these amazing, talented, wonderful people should help ground them as humans, rather than disembodied voices of perfection that only tweet pearls of wisdom. We're all just people. Everyone poops.

I challenge you to recognise when someone subtly ramps up the competitive atmosphere, comparing themselves (or their games) to others, and to ramp it back down. Find ways to be supportive. Raise others up, don't tear them down. Be an example of how to always, always learn.

Your uniqueness is what makes your post-mortems possibly less than useful to others… and yet it means both your triumphs and your setbacks are something to be proud of. Only you can achieve them.
The only failure is to stop, to conform, to give up, to believe there is nothing left to learn.
So stop comparing yourself and keep making games. You're already winning.

* The collaborative, supportive environment of Lost Levels is really what every dev-targeted event organiser should be trying to achieve. Planned chaos doesn't make your event less important. On the contrary, it emphasises the humanity and immediacy of your attendees.

Nightmare Mode: Trying to Pay Rent

As in every creative industry, anyone with ambitions to actually express something about the human condition and get paid for it suffers from enormous pressure. Like so:

The frog wears sunglasses to mask her insecurities.

Indies trying to pay rent are both artist and businessperson and neither.
“Pure” artists are either martyrs or dilettantes -- they give their games away for free and subsist on scraps thrown by passersby and/or rich relatives. But not you. You need money to live.
“Pure” business-minded developers couldn’t see a bigger waste of time than “indie games” -- they make investment-ready products and companies for the express purpose of becoming wealthy. But not you. You need art to live.
You live a life amphibious. You attend business meetings and nod sagely, drawing dollar-signs onto your eyelids to fit in. You delight in playing and making weird games that nobody would ever pay money for, but when you do this, the pressure of rent/family/hunger/medical bills/whatever makes you wonder if you are being irresponsible.
You’re under constant stress from this dual identity because it gives you goals that can sometimes converge (“just make a good game!”), but often don’t. Conferences are a particularly dangerous setting because avatars of these angry gods start to collide, often in a drunken, disorderly way. You're pulled, sometimes literally, in different directions.
This whole "survival guide" was originally directed only at indies trying to pay rent, but I realised most of it applies even to devs who can focus honing their craft. I miss those days.

Summary

Making games is hard. Worrying about money makes it harder.
When you're in a conference setting, the pressure is higher, making any gaps in your psychological defenses dangerous. The six areas I recommend patching up before entering the arena:

1. You can only optimise your opportunities so much. Trust yourself.
2. Build others up.
3. Reach out of your comfort zone to make new friends.
4. Some people won't be your friends.
5. Suffer for your business as necessary.
6. Don't compare yourself. Make games.

Do you have other tips to share?

C4 Engine Interview: Developing A Next-Gen Engine For PS4 And PC

Next gen consoles are a special breed these days, despite being so familiar in so many ways. Their x86-based architecture ensures that PC developers have an easier time ensuring parity while developing for either the PS4 and Xbox One, but their unique architectures mean they have their own hooks. And while Terathon Software’s C4 Engine might not be the first middleware company to take advantage of next gen hardware, it’s certainly one of the few to work its way up.

The C4 Engine was first created in May 2005 and was only ever made available on the PS3. With its migration to the PS4, GamingBolt spoke to Ph.D. founder, president and chief technology officer of Terathon Software Eric Lengyel about how the engine takes advantage of the next gen console (and vice versa), its overall functionality and distinguishing features from other engines, and why it’s not available for Xbox.

Rashid Sayed: Could you tell us about how C4 differs from most other engines in terms of performance and functionality?

Eric Lengyel: It would be possible to compare feature sets and benchmarks all day long, but I think all of the major engines can demonstrate the same general capabilities with some strengths and weaknesses here and there. I’ll instead comment about some less visible characteristics of our engine that may only become apparent when a developer digs in and starts doing real work on their game. The most important thing to understand when comparing C4 to other engines is that the time and care has always been taken to build C4 the right way from thestart.

The C4 Engine has been in development for a very long time, and it has never suffered from the pressures of corporate deadlines and poor management that has a notoriously negative impact on code quality. Everything from large engine subsystems to each minor feature has been designed with careful consideration for correctness, implemented with meticulous attention to detail, and refined over many years of real-world usage.

The result is that the C4 Engine simply works better than many other engines (meaning that features are complete and function properly when used in combination), it exhibits far fewer technical problems than other engines (like crashes or features not working as expected), and the cleanliness of its source code is undisputedly unrivaled. This means that developers will be able to spend more time making their games instead of trying to figure out how some convoluted hack inside the engine is supposed to work.

“The C4 Engine uses a combination of direct dynamic lighting (with real-time shadows), static precalculated radiosity volumes, and our own flavor of screen-space ambient occlusion. There is no limit to the number of dynamic light sources that can exist in a single level, and the engine can handle several hundred light sources within the current camera view as long as most of them have limited bounds.

Rashid Sayed: One of the bigger talking points for next generation games is realistic lightning. How does C4 accurately render light, and how many light sources could it effectively create in real time on a next generation consoles like the PS4?

Eric Lengyel: The C4 Engine uses a combination of direct dynamic lighting (with real-time shadows), static precalculated radiosity volumes, and our own flavor of screen-space ambient occlusion. There is no limit to the number of dynamic light sources that can exist in a single level, and the engine can handle several hundred light sources within the current camera view as long as most of them have limited bounds.

The radiosity volumes capture directional ambient lighting at many grid points inside a three-dimensional volume and apply this data to both static and dynamic objects in real-time. The data stored in these volumes includescontributions from indirect light bounces, emissive material lighting, and hemispherical sky lighting.

Rashid Sayed: What are your thoughts on the PlayStation 4 especially in comparison to the Xbox One? Is there any specific reason why C4 is exclusive to one next generation console and not the other?

Eric Lengyel: Sony made a lot of good decisions when it comes to the technical design of the PS4. It’s awesome to have a fast, featured-packed GPU that can access a huge amount of fast memory. The Xbox One isn’t a whole lot different, but the slower memory and the irritation of still having something like eSRAM are disappointing.

C4 is currently exclusive to the PS4 for the sole reason that Sony was much more cooperative than Microsoft when we were first exploring conversion to next-gen consoles. Sony treated us with respect and made sure that we had everything we needed to get C4 running on the PS4. Microsoft did not respond to us in any way that included the slightest bit of professionalism, and that’s just one more thing to throw onto the pile of PR missteps surrounding the Xbox One.

“The engine contains a compiler of sorts that takes a user-supplied shader graph (built in the shader editor) and performs tasks such as scheduling, register allocation, dead code removal, and common subexpression elimination (merging duplicate code) at the flow-graph level. Then, it generates the actual text-based shader code that gets sent to the driver (or an offline tool) to be compiled into GPU microcode.

Rashid Sayed: C4 was originally on the PS3 but it was reported that the process of porting it over to the PS4 was much smoother than anticipated. What can you tell us about the process and how does it bode for development in general on the platform? Also, is it easier to optimize the engine for the PC or the PS4, and why?

Eric Lengyel: There are three main reasons why porting to the PS4 went smoothly for us. First, we were able to use all of our SIMD-optimized PC code without modification because the PS4 is based on x86 processors. Second, many of the APIs used by non-graphics components of the engine (like low-level threading, audio, and networking) are very similar between the PS3 and PS4, so we didn’t have to do much work to get them running. Finally, and possibly most importantly, Sony has provided an excellent integration with Visual Studio that makes debugging on the PS4 a pleasant experience.

It’s always going to be easier to optimize for a console because the exact hardware is known. On the PC, we have to consider a huge range of CPU and GPU capabilities, and that often makes straightforward optimizations impractical.

Rashid Sayed: How does the shader technology of C4 work and how does it work towards making the game more realistic? What about next-gen consoles helps to enhance the shaders, especially in comparison to other commercial game engines?

Eric Lengyel: There are two aspects of the C4 shader system that I should talk about here. First, the engine uses a graphical editor to build shaders. A lot of people don’t like these and would prefer to write shader code directly, but the editor has proven to be an extremely practical solution for a cross-platform engine.

At one time or another, the C4 shader system has internally supported four different languages (GLSL, PSSL, Cg, and ARB assembly), and it has been able to do so without any changes being made to the original graphical representation of the shader code. When we ported to the PS4, we never had to touch a single shader (out of many thousands) to get them working properly. A developer can design shaders on a PC, and they “just work” on every other platform supported by the engine.

The engine contains a compiler of sorts that takes a user-supplied shader graph (built in the shader editor) and performs tasks such as scheduling, register allocation, dead code removal, and common subexpression elimination (merging duplicate code) at the flow-graph level. Then, it generates the actual text-based shader code that gets sent to the driver (or an offline tool) to be compiled into GPU microcode.

The second noteworthy aspect of the C4 shader system is that shaders are separated into three orthogonal components, and these are created by the developer in different contexts. The first component, for which most shaders are written, pertains to the surface material and describes only how incoming light from one direction is reflected toward the direction of the camera. The second component describes what happens to light as it travels from the light source to the point being shaded and accounts for things like attenuation and projected textures.

The third component describes what happens to the light after it has left the surface but before it reaches the camera and generally has to account for atmospheric effects like fog. We call these material, light, and fog shaders, respectively. Whenever the engine needs to render something that requires some new combination of these three types of shaders it hasn’t seen yet, it connects their graphs together and generates a complete text shader to be used for all future occurrences of that exact lighting and fog environment for that exact surface material. The developer is able to introduce new types of lights or new types of atmospheric effects without having to modify any existing material shaders.

“From time to time, our existing customers are surprised by a significant speed boost when a new version comes out, and it’s something they just get for free because we included some kind of internal change that made the engine better at what it already does.

Rashid Sayed: What are your thoughts on C4 being an alternative to engines like Unity, which is present on both the PS4 and Xbox One?

Eric Lengyel: The C4 Engine appeals to developers who want full access to the source code and who intend to write their games completely in C++. (Note, however, that C4 also includes a graphical script editor.)

Rashid Sayed: Sony has opted for a pretty fast 8GB GDDR5 RAM of memory. What kind of advantages will it bring to games when used in conjunction with C4 engine?

Eric Lengyel: The fast memory will allow larger textures to be used, and this will enable higher detail on objects when they are close to the camera. Compute shaders are also able to stream data into the GPU faster, and this allows more computation to be done for a large variety of tasks.

Rashid Sayed: Are there plans to develop the engine for the Xbox One? If yes, how do you plan to overcome the bottlenecks [specifically eSRAM] so that C4 engine can take maximum advantage of the hardware?

Eric Lengyel: That depends on Microsoft. If we do port to the Xbox One, it will be unfortunate that we still have to deal with things like the eSRAM in this generation of consoles. Many of the methods established with the 360 still apply, and they’ll provide us with some solutions.

Rashid Sayed: What kind of updates can we expect to see in the C4 Engine?

Eric Lengyel: The C4 Engine is updated regularly, and each update always includes new features in the engine and productivity improvements in the tools. Additionally, we frequently make improvements to existing features whenever we realize that something could be done a better way, and this comes from our first priority being to make the highest-quality product possible and not to make as much money as possible.

From time to time, our existing customers are surprised by a significant speed boost when a new version comes out, and it’s something they just get for free because we included some kind of internal change that made the engine better at what it already does.  Some specific features that we currently have in the works are new foliage painting tools, new river sculpting tools, and a new particle system editor.

Rashid Sayed: Is there anything else you want to tell us about the C4 Engine?

Eric Lengyel: If you’re going to be at GDC 2014, please stop by the Terathon Software booth (#741) and check out the C4 Engine for yourself! We’ll be demonstrating the engine with a few levels from our upcoming game The 31st.

Read more at http://gamingbolt.com/c4-engine-interview-developing-a-next-gen-engine-for-ps4-and-pc#GPSsdhbziaiq9LRq.99

Unity Test Tools 1.2 have been released

Assertion Component

Code stripping

We’ve been hearing from lots of people that the main issue that prevents them from using the assertion component is the lack of the option to strip the code out of the release builds. As we faced this issue, we came up with a solution, which is (duh!) very trivial.

We implemented scene post-process mechanism that removes all components from the builded scenes. Nevertheless, the code of the assertion is still being included in the builds. This is due to Unity’s nature and the potency of managed languages (you still might want to use reflection on non-referenced code, don’t you?). But no worries! It’s not anything you can’t deal with.

The solution to completely strip the code from your build would be to implement your own build pipeline and build your project with BuildPipeline.BuildPlayer. See an example of custom build pipeline implementation below:

using UnityEngine;
using UnityEditor;

public class StripCodeAndBuild
{
   private static string assetsPath = "Assets/UnityTestTools";
   private static string buildTempPath = "Assets/Editor/UnityTestTools";

   [MenuItem ("Unity Test Tools/StripCodeAndBuild")]
   public static void StripCodeAndBuildStandalone ()
   {
      AssetDatabase.CreateFolder ("Assets", "Editor");
      var result = AssetDatabase.MoveAsset (assetsPath, buildTempPath);

      if (string.IsNullOrEmpty (result))
      {
         BuildPipeline.BuildPlayer (new[] {EditorApplication.currentScene},
                                    @"C:\temp\release.exe",
                                    BuildTarget.StandaloneWindows,
                                    BuildOptions.None);
         result = AssetDatabase.MoveAsset (buildTempPath, assetsPath);
         if (string.IsNullOrEmpty (result))
            AssetDatabase.Refresh ();
         else
            Debug.LogWarning (result);
      }
      else
      {
         Debug.LogWarning (result);
      }
   }
}

The StripCodeAndBuildStandalone will move the whole UnityTestTools folder to a path underEditor folder, build a WindowsStandalone player, and then move the tools back to it’s original location. Any file under Editor folder is not included in the build.

We hope this will make some people happy and encourage them to use the assertion as a first barrier of defence against bugs!

Performance

As an assertion, the component should have as little performance impact on runtime as possible. We took a closer look and redesigned Assertion Component’s background code to make it run faster… almost 5 times faster! That is at least for a benchmark scene with 1000 check calls per frame.

Assertion Component overhead before optimization (~10ms per 1000 calls):

After optimization  (~2ms per 1000 calls):

Integration tests

Hierarchical structure

If you like nesting and grouping your test, this feature is for you! We made it possible to put one integration tests under another one (just like you would with GameObjects) to clear out the structure of tests. Once a test becomes a parent for another tests, it is treated as a test group. A test group can contain tests or more test groups. See the following screenshot:

 

The tests on the example scene were grouped by their result. Also the result triggers were placed accordingly. We hope this feature will make test scenes with large amount of tests more readable and easier to manage.

Platform Runner

Once you have your integration tests written, a natural thing to do is to run them on your the platform you are developing for. The Platform Runner was created to help you in automating this process. It will build selected scenes for the platform you choose and run it. Additionally, it allows you specify a path to save the results at.

A quick run option for running current scene is also available from the menu.

Reporting Results

Until now, the only way to get the results of a test run was to read the result file that was generated… if it was generated. Not every platform Unity can build for supports file system, and if they do, sometime it get tricky to get use of it (due to system permissions or accessing the file on the device).

To address that issue, we added a result report showed right on the screen of a device you are running the tests on. I will show you a list of failed tests and the logs that appeared while the test was running.

Unit Tests

Background runner

For your convenience we have rewritten the background runner mechanism to run unit tests even though the Unit Test Runner window is not focused. It will run seamlessly and notify you only if any of your unit tests failed.

Undo System

Instantiating GameObjects in a unit test is not a good idea in general, however, sometimes you might have no other choice (or no will to refactor your code!). The Unit Test Runner gives an option to run unit tests on a separate scene, which is a fast and easy way to clean the ‘pollution’  from the scene. This however gives some overhead of reopening your current scene after every run. To make unit tests execution fast and seamless you should avoid running them on a separate scene and use Unity’s undo system to backout any changes to the scene you make in your unit tests. Simply register them with Undo class or utilize the UnityUnitTest base class that comes with the tools.

Continuous Integration Systems accomodation

One of the most commonly asked questions from you are related to continuous integration systems. It’s quite obvious that once you have the automation written, you don’t want to run them manually every time but delegate this task to the machines. It’s called an automation for a reason.

To accommodate some of your requests we redesigned the batch runner for both unit tests and integration tests runners. We added possibility to specify result file path from as a command line argument and enabled integration tests to be run and build in a player from batch. See the documentation for changes.

Summary

Once again big hugs to all of you that contributed, shared their opinion and reported issues. There is a reason we released  the tools via the Asset Store and it’s all about you being involved in development. It allows us to rapidly respond for you feedback and accommodate your needs. We make the tools for you and we encourage you to contribute. Share your opinions and experience of using Unity Test Tools at Unity Forum or via Twitter (#UnityTestTools).

Along with working on the tools, we actively develop best practices and patterns for testing games. Stay tuned for a series of blog posts about that!

And remember: Don’t just make games, make them better!