Category Archives: Unity3D

Configuring Cross-platform DLL’s in #Unity3d automatically #UnityTips

Leave a reply

Many Unity devs don’t use DLL’s, but they save a lot of time and effort. Unity hasn’t documented much of the process, but it’s surprisingly easy when you know how.

Previously, I showed how to use MonoDevelop to make C# DLL’s that work in all versions of Unity, and intelligently switch between different versions of the Unity SDK’s.

Today we’re going to finish by automating the setup, so that you can edit source code and ship C# DLL’s from any version of Unity, on any computer, on any Operating System – and they seamlessly interact with all the other people on your project (no conflicts, no errors).

Continue reading →

A safe and accurate .gitignore for #unity3d (Unity5 onwards)

Leave a reply

Github has a website for hosting gitignores. I learnt the hard way that they are NOT vetted, they can lose critical data from your project if you use them blindly.

But Unity doesn’t provide a standard gitignore for Unity projects, so people often ask: Well, OK, so what should my gitignore contain?

I’ve screwed it up a few times over last 8 years, but my current approach seems to work well. This may work for you, or not. Either way: read the notes, understand each line, and be sure you know what it’s doing before you adopt this yourself!

Problem summary/recap

Unity creates a LOT of temp files. Some of those can speed up loading time on your computer. But many of these cannot be used on other computers. e.g. Macs make incompatible files from the ones Windows PCs make. Even different Windows PCs can make incompatible versions with each other (off the top of my head: e.g. pre-compiled shaders for your current platform).

Unity also creates temp files in bad locations (e.g. the root) that follow naming conventions of critical source files (e.g. C# projects).

If you want to share your code with other projects, Unity has zero backwards compatibility, and so you MUST maintain complete separate copies of your project for every version of Unity you might ever want to use that code/unitypackage with. In most hobby game projects, you don’t care, this isn’t a problem – but we’ll go with a general solution since it’s actually no extra effort.

Finally: given Unity puts some files in the root, and it creates magic metafiles for every file it can see, you want to keep your files and Unity’s files separate. If you share the root, you’ll never know what it’s safe to delete. And if you put your non-Unity files in the Unity folder, Unity will waste time constantly indexing and interpreting them.

Solution part 1: Folder structure

Here’s the simplest correct structure for a two new Unity projects, one called “Game 42” and the other called “Some Other Game”:

/[My Game Projects]/
[Game 42]/        <- this is the folder you add to git
UnityProjects/        <- this is the Unity project folder
Game42-Unity-5.1.3/
Game42-Unity-5.3.0/
Game42-Unity-5.5.5/
[Some Other Game]/        <- this is the folder you add to git
UnityProjects/        <- this is the Unity project folder
SomeOtherGame-Unity-5.1.3/
SomeOtherGame-Unity-5.3.0/
SomeOtherGame-Unity-5.5.5/

Key points:

  • Each game has its own repository in git (this should be obvious)
  • You do NOT use the Unity folder as the root – you make it a subfolder (this allows us to know, in git, whether a file is a Unity file or not, just by looking at the parent folder)
  • You can have MULTIPLE unity folders per project, one for each version of the Unity Editor
  • Each Unity-folder is named after the Unity version it contains AND after the project; this way you get all the info you need both inside Unity and outside it to know which folder is which, e.g. when deleting files, or packaging them

Solution part 2: .gitignore

Now we build a gitignore that uses its knowledge of Unity to exclude Unity-temp files, but keep all other files. Note the [syntax] in case Unity uses different case in the folder names. I’ve never had this cause a problem, but it’s a clever feature of gitignore and I see no harm in keeping it in. Note that Unity is NOT compatible with case-sensitive file-systems.

/UnityProjects/*/[Ll]ibrary/
/UnityProjects/*/[Tt]emp/
/UnityProjects/*/[Oo]bj/
/UnityProjects/*/[Bb]uild/
/UnityProjects/*/[Bb]uilds/
/UnityProjects/*/Assets/AssetStoreTools*
# OPTIONAL: if you have huge assets you’re not ready to commit to source-control yet:
/UnityProjects/*/Assets/UNCOMMITTED.*
/UnityProjects/*/Assets/UNCOMMITTED/*

# Autogenerated VS/MD solution and project files
/UnityProjects/*/ExportedObj/
/UnityProjects/*/*.csproj
/UnityProjects/*/*.unityproj
/UnityProjects/*/*.sln
/UnityProjects/*/*.suo
/UnityProjects/*/*.tmp
/UnityProjects/*/*.user
/UnityProjects/*/*.userprefs
/UnityProjects/*/*.pidb
/UnityProjects/*/*.booproj
/UnityProjects/*/*.svd

# Unity3D generated meta files
/UnityProjects/*/*.pidb.meta

# Unity3D Generated File On Crash Reports
/UnityProjects/*/sysinfo.txt

Key points:

  • DO NOT EXCLUDE .sln, .csproj etc from your whole project! If you create any DLLs (speeds up your Unity development time, and makes it easier to share code), you NEED those files in source control.
  • …unless they are Unity’s internal ones, in which case: ignore them
  • The “OPTIONAL” line is for when e.g. you add a 4 gigabyte texture pack, and not sure you want to keep it in your project. Before blowing your git-lfs budget, you can keep those files in Assets/UNCOMMITTED, and they will be ignored by git. When you’re ready to keep them in your project, move the folder into Assets. This is slightly tricky because it needs two lines to support the existence of a possibly-empty folder, hence I kept it in.

Changing scene/level smoothly in Unity 5 (5.5+) #unitytips

1 Reply

Changing scenes in Unity is harder than I expected. Since version 2 of Unity, we’ve had a deceptively simple and easy to use API call:

Application.LoadLevel() // Easy to use, but wrong name, wrong parameter, no status

It’s easy, but the player-experience was horrible. Unity Pro users had access to a better API. Then, in Unity 5.3, they added the new SceneManager class, and deprecated all the old methods.

So … what’s the best practice for loading a level / changing a scene in Unity 5?
Continue reading →

A real IDE for #unity3d: how to install JetBrains Rider C# editor on Mac (2017) #unitytips

10 Replies

I joined the EAP for Rider about a year ago, but it had too many problems for me (personally) to make it my main editor on Mac (mostly: it coped poorly with running on non-Windows machines, integration with Unity was wonky). These were all workaroundable, but life’s too short to use a wonky IDE, so I waited, and periodically re-tested to see if it was easy yet.

That day has come! Installing the C# IDE on Mac is finally quick and easy.

August 2017 update: if you’re using Unity v2017, Rider is now supported by Unity directly, so you shouldn’t need to do most/any of this!

Pre-requisites

  1. A Mac, running a recent-ish copy of OS X (I tested on latest: 10.12.3)
  2. A copy of Unity 5.5.0 or later installed on your machine

If you only make games, you probably have 5.5.x or 5.6 installed by now. My game is built in 5.4, and Unity’s backwards compatibility is non-existent (my experience so far: most versions of Unity 5 seem to corrupt each other’s project files), but you only need a copy of 5.5.x+ installed, you don’t need to be actually using it.

(as an Asset Store developer, I have copies of: 4.6, 5.0, 5.1, 5.2, 5.3, 5.4, 5.4.3, 5.4.4, 5.5.0, 5.5.2 currently installed. Unity is cool with this – no problems. Everything “Just Works”)

Alternatively, you can download and install a separate version of Mono, for your Mac, but I had a lot of problems when I did this – it got MonoDevelop confused, it got Rider confused, it got OS X confused. My advice: just don’t. Mono is not supported well enough on OS X yet.

Steps

This bit was confusing. There is no documentation anywhere from Rider explaining how to install Rider with Unity. Instead, there are partial docs, in different places, which pretend that you know everything and that you will read the minds of JetBrains dev-team and guess what to do.

So, to be really clear:

  1. Install Rider (obviously)
  2. Install the Resharper-Unity plugin (not obvious: you’re not using Resharper, and the docs suggest you don’t need it. But you do. NB: this is “auto suggested” by the installer – the installer is great)
  3. Configure Unity to use Rider
  4. Configure Rider to use Unity
  5. Install the Unity3DRider plugin

Every step is required! (as of April 2017) Do not be fooled into thinking you need fewer than “all” of them. i.e. “don’t do what I did the first time round”.

Install Rider

Easy … https://www.jetbrains.com/rider/download/

Install Resharper-Unity plugin

For me, this was automatically offered during the install process, so I accepted it. It Just Works, so I recommend you accept it too.

Configure Unity to use Rider

From the official Jetbrains instructions at bottom of this page:

Set Rider as the default External Script Editor

“This only needs to be done once.

  1. Open Unity.
  2. Go to Edit → Preferences → External Tools.
  3. Select “Browse” in the External Script Editor dropdown and select the Rider application.
  4. On Windows, navigate to %APPDATA%\Microsoft\Windows\Start Menu\Programs\JetBrains Toolbox and select “Rider”
  5. On Mac, select ~/Applications/Jet Brains/Toolbox/Rider.app or /Applications/Rider.app
  6. On Linux, select rider.sh

”

Install the plugin into your project

From the same official page – except their instructions are slightly wrong (they work, but are overkill).

This needs to be done for each project.

Copy the folder Assets/Plugins/Editor/JetBrains from this repository into Assets/Plugins/Editor/JetBrains in your project.

…Note: you do NOT need to copy the linked files (currently: two .cs files) into “Assets/Plugins/Editor/JetBrains”. The code works fine if you follow whatever standard you’re using in your project. The only requirement is that ONE of the parent/grandparent/etc folders is named “Editor” (this is a Unity feature).

e.g. I put mine in: Assets/Plugins/3rd-party/RiderEAP/Editor/

Configure Rider to use Unity

Tricky. First of all:

Quit Rider and restart it via Unity

Do this by finding any of your scripts in Unity Editor and double-clicking them. If you’ve done the steps above correctly, a new copy of Rider will open, and will open the script automatically.

If you don’t do this, Rider will try and get you to create a new project, which is a road of pain and suffering you want to avoid (you want Unity to managing the project, not Rider).

Nothing works; Fix the bug

If you wait a bit, and watch the status-bar at bottom of the screen, you’ll see an error appear. Click on the status bar for more info (this is standard JetBrains IDE behaviour). You’ll see this error:

Solution ‘MY GAME HERE’ load failed
Rider was unable to detect a Mono runtime on this machine.

Don’t click the link in the error message! The error comes because OS X doesn’t include Mono, and nor does Rider. But this is where your copy of Unity 5.5+ comes in handy. Courtest of this Rider bug report, we learn that we can use the copy of Mono in Unity 5.5, and how.

Open up Rider’s preferences (cmd-, as normal for OS X):

UPDATE June 2017: Jetbrains has made a breaking-change to Rider, and this setting no longer exists. If the old way was working for you, you must now re-do it with the following setting instead:

…thanks to Ilya for figuring this out, and Kirill from JetBrains for telling us the new setting-name.

…hit the button on the right to browse, and navigate to the folder: " /Applications/Unity/Unity.app/Contents/MonoBleedingEdge" (NB: if you have different versions of Unity installed, you’ll want to navigate to /Applications/Unity-5.5, or Unity5.6, instead – wherever you installed your 5.5+ version to).

Rider will think for a bit – watch that status bar – and you should see the left-hand pane auto-update to look exactly like it does in MonoDevelop (sorry no “before” screenshot, I didn’t think to capture it in time):

Party

Final step: realise you now have a real IDE, with wonderful, 21st-century, source control options, formatting THAT WORKS (@MonoDevelop/Xamarin: don’t call us, we’ll call you…never), intelligent code-hints and auto-fixes, etc. Knock yourselves out…

Correct code to add a mouseover/mouse-hover/pointer-enter to #unity3d

1 Reply

This should be a 1-line feature, but Unity screwed it up. You can do it in approx. 12 lines of code, but I couldn’t find anywhere showing how, so I’ve written it up and you can copy/paste.

This is missing from the Unity docs (as of summer 2016).

This is missing from the Unity API’s and SDK (they implemented the code for “onClick” but failed to implement the code for the other GUI events – onHover / onEnter / onExit – etc).

The most-popular code on the internet is much too long and over-complicated, and requires creating new classes (that you don’t need) which pollute your code-base.

The less-popular but mostly correct code only works for Unity 4.6, and has some bugs that will prevent it working in most cases.

So I fixed it…

How it should work – but doesn’t

This is Unity’s code for adding a “click” handler to a button in their new (post-4.5) GUI:

Button b = ... // your button, from your code
b.onClick.AddListener( () => { YOUR_CODE_HERE } );

So the code for adding a “hover” handler (or, in 99% of SDK’s and platforms, an “enter/exit” pair of handlers) should be:

Button b = ... // your button, from your code
b.onEnter.AddListener( () => { YOUR_CODE_HERE } );
b.onExit.AddListener( () => { YOUR_CODE_HERE } );

Or, if they wanted to go with the 1% solution, that is only used by CSS:

b.onHover.AddListener( () => { YOUR_CODE_HERE } );

None of these work, because Unity’s API is incomplete.

Correct solution, Unity v5.0 – v5.4

Instead, you have to implement the missing code from Unity yourself. You can use this to do manual click detection, and to distinguish between mouse down and mouse up (a “click” is traditionally a pair of events: down followed by up. This is standard in all windowing systems and GUI API’s).

The most commonly needed case is hovering, so you’ll need two pieces of code, one for “mouse moves over” (enter) and one for “mouse moves away” (exit).

/**
 * replace the code "YOUR_CODE_HERE_1" and "YOUR_CODE_HERE_2"
 */
Button b = ... // your button, from your code

EventTrigger trigger = b.GetComponentInParent<EventTrigger>();
if( trigger == null ) trigger = b.gameObject.AddComponent<EventTrigger>();

EventTrigger.Entry entryEnter = new EventTrigger.Entry();
entryEnter.eventID = EventTriggerType.PointerEnter;
entryEnter.callback.AddListener( (eventData) => { YOUR_CODE_HERE_1(); } );
trigger.triggers.Add(entryEnter);

EventTrigger.Entry entryExit = new EventTrigger.Entry();
entryExit.eventID = EventTriggerType.PointerExit;
entryExit.callback.AddListener( (eventData) => { YOUR_CODE_HERE_2(); } );
trigger.triggers.Add(entryExit);

#unity3d #missingdocs: CanvasRenderer.SetMesh() – making it work (mostly)

Leave a reply

This once-obscure method, that – I guess – is the low-level call used by most of the new Unity GUI … is now the only way of drawing meshes in GUIs. The previous options have been removed, with brief comments telling you to use .SetMesh instead. Half of the DrawMesh / DrawMeshNow methods have also been removed (no explanation given in docs), which were my other go-to approach.

Unfortunately, no-one has documented SetMesh, and it has significant bugs, and breaks with core Unity conventions. This makes it rather difficult to use. Here’s the docs I’ve worked out by trial and error…

Continue reading →

What one #unity3d private class should be made public? @shawnwhite

Leave a reply

Shawn asked on Twitter:

We only get to pick ONE? :).

How do we decide?

There’s two ways to slice this. There’s “private APIs that would hugely benefit us / our projects / everyone’s projects / 3rd party code that I use (e.g. other people’s Asset Store plugins I buy/use)”. We can judge that largely by looking at what private API’s I’ve hacked access to, or decompiled, or rewritten from scratch.

Then there’s “what CAN’T I access / hack / replace?”. That’s a harder question, but leads to the truly massive wins, I suspect.

Stuff I’ve hacked access to

The Project/Hierarchy/Scene/Inspector panels

So, for instance, I made this (free) little editor extension that lets you create new things (scripts, materials, … folders) from the keyboard, instead of having to click tiny buttons every time.

There are no public API’s for this; that’s a tragedy. Most of these Unity panels haven’t been improved for many years, and are a long way behind the standard with Unity’s other improvements. They “work”, but don’t “shine”.

What could I do with this?

Well … a few studios I know have completely rewritten the Scene Hierarchy panel, so that:

  • it does colour-coding of the names of each gameobject
  • clicking a prefab selects both the prefab and any related prefabs, or vice versa, or hilights them
  • added (obvious) new right-click options that are missing from default Unity Editor
  • automated some of the major problems in Unity’s idea of “parenting” (parenting isn’t always safe to do; you can enforce / protect this with a custom scene hierarchy)
  • made it put an “error” icon next to each gameobject that is affected by a current error.
  • …etc

All massively useful stuff that helps hour-to-hour development, reducing dev time and cost.

It’s all “possible” right now by writing lots of horribly ugly and longwinded boilerplae code, and using the antiquated Editor GUI API.

But to make it play nicely with the rest of Unity requires also hacking Unity API’s for the various panels/windows, and detecting popups (and adding your own popup classes, since Unity keeps most of theirs private), and detecting drags that started in one panel but moved to another, detecting context-sensitive stuff that is not exposed by current API’s, … etc.

A better List editor

The built-in sub-editor (like a PropertyDrawer – see below) is very basic – really a “version 0.1” interface.

There is a much nicer one, that does what most Unity developers need – but it’s private and buggy (last time I tried, it corrupted underlying data. That’s presumably why it’s still private?)

Editor co-routines

Co-routines work perfectly in the Editor. (EDIT: thanks to ShawnWhite for the info): Unity doesn’t use co-routines outside of runtime; what appears to use them is OS-provided multi-threading. Strangely, when using that, I haven’t seen any of Unity’s ERRORs that are usually triggered by accessing the Unity not-threadsafe code from other threads – something weird happening in the OS?

Why doesn’t Unity support co-routines in the Editor?

I’ve no idea. There are many people who’ve re-implemented co-routines in editor, exactly as per Unity’s runtime co-routines. As a bonus, you end up with a much better co-routine: you can fix the missing features. But there’s some strange edge-cases, e.g. when Unity is reloading assemblies (which it does every time you save any source file), for a few seconds it presents a corrupt data view to any running code, and you if start running a co-routine in that time, it will do some very odd things.

Unity recently exposed some API’s to detect if Unity was in the middle of those reloads, but last time I tried it I couldn’t 100% reliably avoid them. An official implementation of Unity’s own co-routine code, that was automatically paused by Unity’s own reload-script code, would neatly fix this.

Until we have something like that, we’re forced to write two copies of every algorithm (C# doesn’t allow co-routine code to be run as a non-co-routine) so we can test in Editor, do level editing, debug and improve runtime features, etc … which is silly.

Stuff I CANNOT hack into/around

Serialization

Unity is the only engine I’ve worked with where the core data structures and transformations are opaque, hidden, can’t be extended, can’t be debugged. Tragically: also has many missing features, bugs, and serious performance issues.

There are good reasons for why this remains in such a bad state (It’s hard to fix. Meanwhile … it sort-of works, enough to write games in – you just have to occasionally write a lot of bad code, have to rewrite some ported libraries, have to know a lot of Unity-specific voodoo, etc).

But if it were exposed – we could (I would start on it tomorrow!) fix most of the problems. I’ve done proof-of-concepts with some terrifying hackery that show it’s possible – and a lot of the architecture is well explored, other ways it can be implemented, that could be given to developers as options (some would work better for your game, others might not; but you could pick and choose).

It’s too much to ask for (it intersects so much of the engine, and it would unleash a horror of potential bugs and crashes), but my number 1:

Callbacks for ALL core Unity methods

This sounds small but would have positive impact on a lot of projects.

c.f. my reverse-engineered callback diagram for EditorWindow in Unity:

…but we have the same problems for MonoBehaviour, for GameObject, etc. Not only are lifecycles poorly documented, but they’re inconsistent and – in multiple places (c.f. above diagram “Open Different Scene”) – they’re not even deterministic! It’s random what methods the Editor will call at all, let alone “when”.

Under the hood there must be reliable points for doing these callbacks … somewhere.

Undo

Undo has never worked in Unity. The worst stuff I narrowed down to ultra-simple demos that Unity’s own code was broken, I’ve logged bugs and Unity fixed them – but the current system is a horrible mess, much too hard to use. Many methods only randomly do what they’re supposed to, and there’s no way to debug it, because the internals are hidden.

If Unity exposed the actual, genuine, underlying state-change points, we could correctly implement editor extensions that support Undo 100%. I’d be happy to also use them to write an Asset that implements “easy to use Undo”, based on how other platforms have implemented it (e.g. Apple’s design of NSDocument is pretty clear and sensible, based on lists of Change Events).

Unity could then make “Undo that works” a mandatory requirement on the Asset Store. Currently it’s listed as mandatory, but no Asset has ever been checked for it (so far as I can tell).

Not least because Unity’s own code has had such problems supporting it!

PropertyDrawer: doesn’t quite do what it claims to (yet)

Recall what I said above: most of the Editor GUI/UX itself “hasn’t been improved for many years”. Unity made it user-extensible/replaceable many years ago – so in theory you could update / replace whatever you want. There’s a huge amount we’ve been able to update and customise (although it’s very expensive in coding time, due to a lack of modern GUI API’s, sometimes it’s well worth it).

But you can only replace the Inspector for a particular Component/MonoBehaviour. You cannot say “I want to replace the Inspector for GameObject’s that have Components X Y Z”.

Worse, if you wanted to replace e.g. the part of the Inspector that automatically draws a Vector … you can’t.

Unity had a great idea to solve one of these: Property Drawers. These would let you customise the rendering of sub-parts of an Inspector – the rendering of individual labels for member variables, list items etc.

IN THEORY this would let you write your own list-renderer that would work everywhere, and make lists very easy to use in the Editor – but only write the code once.

IN PRACTICE it was only implemented in a very basic way, and most of the things you want to use it for are blocked / inactive. There is NO WAY to fix this in user code.

(well, actually there is … c.f. . But this is a horrendous amount of work – AI’s author did a Herculean task! – and means you’ll never the benefit of future Unity UX / GUI updates, if there are any).

So: big upvote for exposing more of PropertyDrawer

Simple #civ5 clone in Unity: hexes, movement, unit selection

4 Replies

Current features

commit 26eafb7865965fd5ef5ee3ad4863f00acf8d10a2

  • Generates hexes landscapes, with heights (Civ5 bored me by being flat-McFlat-in-flatland)
  • Every hex is selectable, using custom fix for Unity’s broken mouse-click handler (see below)
  • Any object sitting on landscape is selectable (ditto)
  • Selected units move if you click any of the adjacent hexes (shown using f-ugly green arrows on screenshot)

The green “you can move here” arrows look like spider-legs at the moment. #TotalFail. Next build I’m going to delete them (despite having spent ages tweaking the procgen mesh generation for them, sigh) and do something based on wireframe cages, I think.

Screen Shot 2016-04-11 at 22.59.25

Techniques

Hexes

I started with simple prototyping around hexes, but soon found that it’s worth investing the time to implement all the primitives in Amit’s page on Hexagon grids for games: http://www.redblobgames.com/grids/hexagons/

In practice, especially the ability to create a class that lets you do “setHex( HexCoord location, GameObject[] items )” and “getContentsOfHex( HexCoord location )” and things like “getNeighboursOf” … is very rapidly essential.

Mouse clicks in Unity

IMHO: work pretty badly. They require the physics engine, which – by definition – returns the WRONG answer when you ask “what did I click on?” (it randomises the answer every click!). They also fundamentally oppose Unity’s own core design (from the Editor: when you click any element of a prefab, it selects the prefab).

So I wrote my own “better mouse handler” that fixes all that. When you click in scene, it automatically propagates up the tree, finds any listeners, informs them what was clicked, and lets you write good, clean code. Unlike the Unity built-in version.

Procedural meshes for arrows

With hindsight, I should have just modelled these in blender. But I thought: I want a sinusoidal curve arrow; how hard can it be? I may want to animate it later, by destroying/adding points – that would be a lot of work with Unity’s partial animation system (it’s great for humanoids, less great for geometry) – but animating points in a mesh from C# code is super-easy.

In the end, I spent way too long tweaking the look, and on having 2-sided polygons that broke the Unity5 Standard shader by being too thin (on the plus side: I now know what that mistake looks like, and I’ll recognize it in future Unity projets. It has a very peculiar, unexpected, look to it).

I should have just made them in Blender, and – if I got as far as wanting to animate them – re-modelled in source code later (or found a “convert blender file to C vertices array” script, of which I’m sure there are hundreds on the web. Doh!

#lessonLearned.

What makes a great #Unity3d asset? Which do you recommend?

1 Reply

Unity is still the only major game-engine with an effective, established Asset Store. This is an enormous benefit to game developers – but do you feel you’re making full use of it?

I’ve bought and used hundreds of Unity plugins, models, scripts, etc from 3rd parties. I’ve found some amazing things that transformed my development.

TL;DR: please share your recommended assets using this form: http://goo.gl/forms/G3vddOdRL3

Things we want to improve

This is a shortlist; if you’ve got areas you want to improve, please add a comment.
Continue reading →

Improved interactive GUI for Snap-and-Plug (glue/vertex snapping for complex objects in #Unity3d) #screenshotsaturday

Leave a reply

Some screenshots from today’s improvements. I’m moving gradually towards releasing version 2. Shortlist of changes/improvements below…

From this mess … to this:
Screen Shot 2016-03-12 at 14.59.24 Screen Shot 2016-03-12 at 20.43.32
Building some odd machines to test it works:
Screen Shot 2016-03-12 at 15.00.21 Screen Shot 2016-03-12 at 19.50.44

Features and fixes recently added

  • Use shaded, materialed meshes for in-editor handles, instead of flat ugly rectangles and tris
  • Click/tap a socket’s handle to directly select it in the Scene view
  • Meshes are resized to fit the user-selected “socket size” variable
  • Only handles that are facing you are rendered; HUGE improvement for complex levels/machines/buildings/etc
  • Only handles you can see are clickable/draggable; HUGE improvement for complex scenes (where accidental clicks happened too often!)

Simple #unity3d bugs and flaws fixed by Entity Systems – number 1

7 Replies

I periodically write massive long documents detailing all the bugs in Unity that I know, have memorized, and have to workaround on a day-to-day / hour-to-hour basis. But it makes me so angry and frustrated – so much terrible coding, so little technology-leadership at the company – that I end up deleting it. Life is too short to be daily reminded how crappy (and yet easy to fix) our tools are.

Then, every 6 months or so, when people ask me for simple examples of how ECS’s fix Unity, I have to wrack my brains for something simple.

So I’m going to start blogging simple examples as I run into them, with only enough context for me to understand them. Here’s the first…
Continue reading →

Unity: the “real” version 5 just released (#Unity3d 5.2 fixes many severe issues!)

3 Replies

A new version of Unity is now out – https://unity3d.com/unity/whats-new/unity-5.2 – and it’s a doozy.

I don’t normally blog a blow-by-blow account, but this set is particularly interesting.

It suggests the tech team has been focussed on fixing many “critical but un-sexy” problems. That is a noticeable change in direction from the past few years. Possibly this is a one-off to get Unity 5 working properly.

If you’re still using Unity 4.x, it is finally safe to move to Unity 5.

Unity 5 is not a complete replacement for Unity 4 – there are still major featuers of 4.x that have been removed from Unity 5 and have no upgrade-path – but it’s finally production-ready (or very nearly). That … is big news!

Hilighted improvements / fixes / changes

Please note: there will be a lot of negative comments here; that is inevitable, considering most of the change-list is “things that were broken, or wrongly implemented, or poorly designed – and are now not”.

To be clear: I’m pleased and excited by the overall shape of these changes.

Graphics: Added CullingGroup API, which allows you to specify a large set of bounding spheres that are integrated into the culling pipeline and subjected to frustum and occlusion culling

Unity has (amazingly) never had built-in culling accessible by developers, which is almost unheard-of in game-engines. This suggests we’re getting towards it (although spheres are only a first-approximation for culling, and I wonder how deep the interaction is with Unity’s pipeline here. I’d assumed we’d get access to something more like BSP)

Application.UnloadLevel. Unloading scenes is now possible while the game is running. References to lightmaps are cleared but you have to call Resources.UnloadUnusedAssets() to actually unload them.

Scenes in Unity are very much FUBAR as a concept – they were created by people who had very little understanding of computer-game design and development. Ideally, we’ll see Unity remove the whole “Scene” concept in a future major release, but in the meantime this is a significant step towards reducing their weaknesses, which is good to see.

Layout elements under a ScrollRect component may not work properly

No s***, Sherlock! Yeah, most people using Unity’s “new GUI” have found it’s fundamentally broken in a bunch of places. Good to see Unity working on this, and hilighting some of the issues – but really they need to create an entire webpage listing “the following parts are broken, don’t use them – or beware if you do”.

Right now, you tend to waste hours, half-days at a time … re-discovering known bugs in Unity’s GUI.

Scene view picking in linear color space does not work for DX11 when MSAA is used (quality: fantastic)

If you’re on Windows and have the highest quality settings, this is lethal: Unity simply doesn’t work. But it’s coming in an emergency patch very soon.

Mecanim: Playable API.

If this does what I think it does, then it was essential back when Mecanim was released (3 years ago); glad to see it’s finally here.

between 5% and 30% lower CPU cost for rendering

That’s an enormous speed-up for an engine as old as Unity – this is big news. Reading between the lines, the speed up is partly a side-effect of them making it a bit more multi-threaded (which became normal for game engines many years ago).

If we thought that was a lot, wait till you see:…

Particle rendering optimizations (especially for VR), with speed improvements varying from 15% to 50%

… 50% performance improvement! Wow. Name-checking VR here is probably the key item. We keep seeing VR’s extreme performance-requirements forcing engine-makers to up their game, and dig deep to find perf boosts. The “minimum” hardware reqs for basic VR rigs are very high even now, several years after Oculus Rift launched.

UI now uses multithreaded batching & geometry generation backend

This was the minimum we expected from the “new GUI” when it launched in Unity 4.6 almost a year ago. This fix brings the GUI most of the way towards being “production ready” … ironically, 6 months after Unity changed their website to hide the existence of the “old (but works) GUI” and pretend it didn’t exist.

Added parameter QueryTriggerInteraction to all physics queries (raycast, spherecast, overlap) to allow any query to override whether or not the query should hit Triggers

This is patching a MAJOR design bug in core Unity that has plagued Unity for many years. I want to play with this some more, and see how much we can un-**** Unity’s ****ed ray-casting system using it.

(I don’t believe any experienced game-developer would have accepted Unity’s original design here – it was clearly a terrible approach that would cause never-ending head-aches when making games. It mixed concepts that were very obviously unrelated and distinct)

Fixed Function shaders work on all platforms now (including consoles)

This one has been blogged about extensively by some of the graphics team, IIRC.

In my experience, Unity’s shaders have been OK, with a few that were terrible (e.g. all the Mobile ones), but the framework which holds them has generally been excellent: it’s isolated us from the pain and suffering of GPU-specific shader bugs. This house-cleaning doesn’t make much (if any) difference to most of us, but apparently keeps Unity’s internal code clean in a way that will facilitate rapid changes and improvements going forwards.

2D Rect Mask

TL, DR: “we finally implemented masking properly in the new GUI”.

See previous comments on the new GUI, and how it’s getting much closer to production-ready.

UI: Dropdown control

Yes, really – Unity has finally added the “dropdown”, which has been a global expectation in UI design for 20+ years (it was made compulsory in web-browsers back in the 1990’s).

Editor: Remove legacy Mac OS X corner window resize behaviour

Apple told devs to remove this … um … about 3 or 4 years ago? At first, it was broken (couldn’t resize windows), then it was annoying (Unity added optional resizing on all edges, but put an illegal resize-hot-corner in bottom right that broke all EditorWindow code, because they made it a private API).

Working around that on Mac … forced you to mildly break things on Windows.

TL, DR: custom editors (as found in many/most of the best Asset Store plugins) will now be a little less-broken across the board.

Substance … All crashes and hangs at build time, level load/change time, playmode entry/exit should be gone

Yay! I’ve not been using Substance, but I’ve met several developers who’ll be breaking over the champagne over this, given how miserable they’ve been about crashes and hangs with this in the past.

CanvasRenderer now takes a Mesh instead of List this allows for the use of imported meshs as part of the UI

Without this feature, the new GUI was not usable in most non-trivial games. It’s hard to over-estimate the importance of this for declaring the new GUI production-ready.

Allow sprites to be dragged into scene view in 3d mode

Small but sweet. It’s a little thing, but makes a big difference to the frustration level of the user; in my experience, these things are often the real reason why you sacrifice the cost-savings and benefits of your own engine and use something like Unity instead.

i.e.: with your own engine, you can’t afford the time/money to polish every small interaction; 3rd-party game-engines can shine here, and should take more advantage of it.

I sometimes mention stuff like this as suggesting that Unity’s senior management team are out-of-touch with their product. Unity’s early community loved it largely because of small things, but as Unity grew, the company stopped sweating them. I suspect time will eventually tell that was a huge strategic mistake.

Improved Export Package window (now uses a proper tree view)

This window hasn’t correctly worked for at least three years; converting it to a “proper tree view” might – finally! – make the “Export Package” function do what it’s defined to, instead of exporting the wrong things, breaking keyboard and mouse interactions, etc.

(most of the bugs appeared to be a side-effect of the non-maintained, half-implemented, custom tree view code)

Make sure ObjectField and Object Selector shows icons for game objects and prefabs

Co-incidentally, I tweeted about this recently: Unity could make their engine noticeably faster to develop with if they provided visual feedback on these fields.

It’s embarassing, almost shameful, how poor the UX is on these fields today. By the sounds of things, this patch merely makes them “less crap”, rather than fixing them – but the last 5 years has been so awful that any improvement is welcome!

Selection.selectionChange callback triggered when selection changes

To call this “important” is somewhat of an understatement.

Substantial areas of the Editor API’s are surprisingly poorly maintained by Unity. The bugs undermine people each time they try to use one of Unity’s overwhelmingly greatest features: its extensibility.

Graphics: Added a quality setting ‘Shadow near plane offset’ to allow working around shadow pancaking artifacts

If this does what I suspect, it will make it trivial to fix a lot of common, frustrating “why do my shadows suck? OMG! UNITY SUXXS!!!!” situations.

Mecanim Improvements

SO MANY.

I don’t use Mecanim: it’s been slow, clunky, buggy – and it solved the wrong problems at launch. It felt more like a marketing excuse rather than a developer feature. For me, working x-platform and often on mobile: not very useful.

However, looking at how long the list of fixes is … it might finally be worth using it. In context of all the other changes we’re seeing – maybe production-ready for general use now?

(modulo: the performance. Last time I checked, it was still way too slow for cross-platform games unless you were happy to have a relatively small number of animated objects)

Go check it out! If you’re a long-time Mecanim user, let us know what you think of this list of changes!

Now a TerrainData object embedded into a scene (created by script) allows scene objects being selected as tree prefabs

Unity’s Terrain system was implemented using a nasty, ugly hack that should never have been used.

As I understand it, that was in itself an attempt to workaround some problems with the fundamentally broken – and allegedly “unfixable” – Serialization system that is core to Unity, but is too much code for anyone to fix (and will be thrown out / fixed / replaced around Unity v6 or v7. Maybe).

This change reeks of a “workaround to a workaround”: you can’t create TerrainData in the scene (which should be the ONLY option!), but you can artifically create one if you write a script to do it for you. Either way, it’s good news – TerrainData Assets are a common source of project-corruption, because they’re abusing a feature that wasn’t intended for this.

Stacktrace logging: Allow to log full (native/managed) stack trace when log is printed, the option is available in the console window in top right corner popup menu.

OMGWTFBBQ!!!!!!!!!!!111!11111!!!!11!!!1!

I frequently discover major bugs in Unity core; there is never anything I can do about it because Unity strips / deletes all stack traces (in most cases) before outputting anything.

If this fix does what it says on the tin … WOOOHHHOOOO! … we can finally workaround Unity crashes (by debugging them!) and give Unity much more detailed and accurate bug-reports (leading to greatly increased chances of them fixing bugs).

Cross those fingers…

Fix Cursor

As I recently tweeted, Unity’s support for custom mouse-cursors was recently broken. That’s a huge pain given most games today use custom cursors. Several fixes here, looks like they’ve cleaned them all up (I hope).

Fix possible data loss on Windows when renaming folder with locked files

:O

Fix occasional recycle bin bypassing when deleting assets on Windows

:O

Serialization: Fixed not being able to serialize a field called “Base”

:O

UI: Stop disabled graphics from blocking raycasts

If this is what I think it is, it’s another example of “should have been fixed before 5.0 was released” – but I’ve had so many problems with the bad system of Unity raycasts that I go out of my way to avoid them anyway.

Core: Fixed hang when passing large arrays to the Undo system

Sounds unexciting, but … I think I’ve encountered this on some of my projects: unexplained hangs that came out of nowhere and destroyed my ability to keep working on one particular game, related to Undo.

Note: I keep saying this in public: Unity’s Undo system simply Does Not Work, it’s appallingly buggy. As far as I can tell, the person who originally wrote it had little or no experience of what they were doing, and didn’t consult the literature to find out how to implement Undo systems correctly.

Some days, I genuinely feel it would be better for everyone if Unity removed the “ctrl-z” keyboard combo, because so often when you press those letters you corrupt your game project. A lot of the time, you don’t notice that Unity has just corrupted your project – not until much later, and then you don’t realise that it was Unity’s broken Undo that caused the corruption. Instead, you blame yourself, or your co-workers. Seriously, it’s that bad.

(I’ve stopped bothering logging bugs against it)

Importing: Changes to scripts are now correctly processed synchronously, fixing a range of issues with scripts relating to asset processing at import time

Subtle, but … I suspect this fixes a LOT of bugs we see on larger Unity projects, where you’re frequently hot-loading complex sets of scripts, assets, inter-related dependencies, custom asset-processors, etc.

…the end

So that’s it. What do you think? Any other major items you notice in the release notes that will make your life significantly better?

What’s still broken?

#Unity3d hardware usage + implications – Summer 2015

2 Replies

There’s tonnes of blogs out there, so I only talk about the bits that other people have missed, or were too polite or inexperienced to cover. Often that means I’m the one pointing out the flaws (most people don’t want to write bad things. Screw that; ignoring the bad points does you no favours!).

Sometimes I get to talk about the good bits that – sadly – few people have noticed. Here’s one of those.
Continue reading →

New #unity3d feature: Virtual Scenes

2 Replies

Unity3D has a great core architecture – it’s easy to understand and use. However, it has some significant flaws.

One of the recurring problems I run into is that Unity requirs you to have precisely one “Scene” at any one time, but often you need to have multiple scenes at the same time. Problem? Yes, lots…

Unity 5 has some hacks to make it “sort-of possible” to have multiple scenes at once in-Editor.

Note: these were mentioned by Unity corp in August 2014, but aren’t available to most users yet

But they (appear to be) hacks: they help for a fraction of the use-cases. That’s fine: Unity has 10 years of software written on the assumption there is only one “Scene”; that’s an enormous amount of code to change! But can we do something about this?

TL;DR: I’ll put this on the Asset Store

If you just want a working solution, here’s the Unity Asset store page / support page, new versions will appear here first.

I’m using it myself on my own projects, and will do some beta testing with other people’s games. If it works well enough, it’ll go on Asset Store. I suggest reading this full post anyway – it’s an example of how to creatively solve small issues like this in Unity.

(if you’d like to beta-test this, tweet me @t_machine_org or email me (address at top of page). Unity Corp only let me have 12 beta-testers, so you’ll need to give me some info about what you’ll use it for, how soon, how much feedback you’ll give me, etc! Sorry :( )

Continue reading →

Writing a #unity3d mini-game … to help you design a AAA game

4 Replies

One of my hobby projects is a testament to the Ultima and Elder Scrolls games – a massive open-world, where everything you do impacts the world around you. This has long been promised by commercial games – and it sucks from a gameplay perspective; it’s just not fun. But a very old ASCII-graphics game, Omega, showed a couple of ways of doing it that delivered on that promise while still being “fun” – very fun! That’s what I’m working towards.

It’s a test-bed for the high-performance Entity System I’m writing for Unity (more info here). I’m aiming for “gameplay considerably richer than Skyrim” with “graphics about the level of Oblivion”. To be clear: Oblivion was released almost 10 years ago! To reproduce those graphics today is fairly easy.

Challenge: Believable Cities that evolve over time

One of the things I have yet to see in any FPS RPG is believable cities, and more: cities that actually evolve. The nearest I’ve seen is the beautiful “large towns” of the Assassin’s Creed series (they represent cities, but the distances are way too small).

That doesn’t cover the “evolve” part though – even the AC cities are 100% static and unchanging. Hand-crafted, and because they cannot change (technical design choice) the player is incapable of altering them. You can’t burn down blocks, or build a new bridge. You can’t buy two houses and knock them together.

Hey, RPG industry, you can do a lot better!

This is one of the main new gameplay elements in my design. If all I managed was to take an off-the-shelf-RPG mod and add living, growing cities … I’d probably be content. What does this mean, though?
Continue reading →

#unity3d missing docs: EditorWindow lifecycle

6 Replies

If you do any non-trivial customization of Unity Editor, you’ll almost certainly extend EditorWindow. But Unity (to date) refuses to tell anyone how to do this legally, or what the contracts you’re being held to are. Without that, many plugins on the Unity Asset Store are wrong and buggy, and sooner or later accidentally cause problems for users.

Their fault? Partly, but I don’t blame them too much – rather: Unity’s fault for failing to document (and failing to test assets before approving them!).

For those of you who aren’t happy shipping crappy, broken, buggy plugins (And charging for them), here’s a guide / reference for the lifecycle of EditorWindow. Extra info, explanations, and gotchas welcome!

Docs-UnityEditorWindow

I’m working on my own Entity System for Unity; want to follow it?

…Sign up here to be kept up-to-date on the project’s upcoming Kickstarter / Patreon / whatever-it-ends-up-being (if you’re already signed up, it won’t add you again)

Use shift-N to create new scripts in Unity Project Window, fast

1 Reply

In Unity, you create new scripts many times per day, and folders but there’s no keyboard shortcuts. I fixed this, and made the popup rather more intelligent than Unity’s built-in one. I’ve decided to make the basic version available for free here:

UPDATE: there’s a bug in the 1.0 version – it WILL NOT WORK if you set your Project window to 2-column layout. This is due to BUGS IN UNITY (not my code!). I have a workaround that’s in the Asset Store version, but is missing from the free version. I’ll patch it later

FreeIntelligentNew.dll – I’m not supporting this; it’s free: use at your own risk.

Or, for $2, you can get the latest version with full source code from Asset Store – I’m supporting + updating this.

Installation

Drag/drop the DLL into any folder named “Editor” in your project.

(required by Unity; this is how they make sure that Editor scripts aren’t accidentally included in your final game)

Usage

  1. Select the Project panel
  2. Hit shift-N
  3. By default, it intelligently guesses if you wanted a new Folder or a new Script. If it guessed wrong, hit “tab” to cycle through the options
  4. Choose a name and hit Enter (like normal in Unity). Done!

How…?

This works by peeking into some of Unity’s internals and detecting which EditorWindow has focus. If it’s the Project window, it uses some hardcoded constants (which differ between Unity versions, due to bugs they gradually fix, I think) to get the positions right, and offer you the popup.

I did it this way because Unity currently provides NO PUBLIC API for reproducing some of their core Editor features (e.g. where they temporarily change the render-style of the “newly-created item” in a Unity windowpane, so that you can edit the name in-line. Not possible for you or I!)

With a bit more hacking, I might be able to hook Unity’s own code and enable / trigger / alter the hidden features from keyboard, but … that’s on the wrong side of “Fragile; would probably break unexpectedly in a future version”.

How I’ve done it so far it sits independently of Unity’s code, and is very unlikely to stop working, or to cause bugs later on. YMMV…

(if you want to know more, get the Asset Store version, read the source. I’m happy to answer quetsions via the support links or in the Unity Forums page for this)