Categories
programming Unity3D Unity3D-tips

#unity3d missing docs: EditorWindow lifecycle

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

Categories
games design usability

#UX conveying critical info to public via number rating: Food Hygiene Stickers

How do you make good UX / GUI to present information to a mass-market audience with widely varying levels of education and attention-span?

This is a problem faced all the time by game designers and developers. It’s one of the most under-appreciated skills of the profession: good game developers know more about “presenting information and choices” than almost anyone else, anywhere. Because games are generally overloaded with info, and the dev teams have to filter that down and present it clearly – but if they get it wrong, the player’s in-game character dies, the game is lost, and the game itself tanks commercially. The developers then – ultimately – lose their jobs when the studio goes bust.

I’m going to start looking at non-tech examples of design and UX through the lens of game-design, and see where it goes…

Categories
Unity3D Unity3D-tips

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

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)

Categories
entity systems programming

Entity ID’s: how big, using UUIDs or not, why, etc?

This has come up a few times, and I ended up replying on Twitter:

But that’s a crappy way to find things later, so I made a quick-and-dirty infographic with a few key points:

Docs-entityID

Categories
advocacy games industry games publishing marketing and PR Unity3D usability

6 ways to massively improve the #unity3d AssetStore (for #gamedev’s)

Six months ago I tweeted a handful of obvious ways that you could make the Unity Asset Store greatly more profitable.

One of the Unity folk reached out to me, claimed that Unity was highly invested in improving this and asked for specific suggestions. So I wrote longer, detailed versions of each tweet and emailed them.

It’s been six months. No response. So … for Unity’s competitors, maybe looking to make/improve their own Asset Stores (or newcomers hoping to unseat the incumbents), here’s six obvious commercial improvements.

I’ve cut a few paragraphs I wrote to Unity about who I think their 3 main audiences are on the Asset Store; I included them as a “here are the assumptions I’m making” – I have no idea what their real audiences are. So I omitted that here.

NB: I’ve made the formatting webpage friendly, added some details, but this is essentially an info dump. I was too busy at the time to sugar-coat it – I figured that if Unity wanted to talk, I’d talk to them, and in person I’m really quite friendly and gentle. But at the time we were working 24/7 getting ready for a major exhibition, so this is a bit … terse.

Categories
Uncategorized

Journalling for #entitySystems: #unity3d corrupted my scene; I’ve built a debugger for Unity!

Experimenting with shorter Entity Systems articles

This post is an experiment: rather than write massive, heavily-edited articles, I’m writing “shallow” versions first, which takes me only an hour or so. Then I’m saving the in-depth, detailed versions of each topic for future subscribers to my own Unity3D Entity System. This way I can cover a lot more topics in the same amount of time, and I suspect most people will get all they need without the deep dives I used to do.

Let me know what you think – @t_machine_org

The Unity bug that deleted my game prototype

A few days ago, I fired up my Unity3d test project for the new Entity System. All the data was serialized into Unity’s scene, everything was fine. I was expecting to see all my “registered” components (that are saved directly into the scene) exactly as they were last time:

Screen Shot 2015-05-26 at 11.23.54

Instead … I got this. Why, Unity – WHY?

Screen Shot 2015-06-07 at 21.29.31

On further inspection, Unity’s serialization system had stabbed me in the back: it combined data from two different situations (which is blatantly wrong and should be impossible – although since Unity has failed to document it … who knows what contracts it promises to uphold internally?). I’d like to know why…but the Unity Editor won’t tell me (they don’t let us see this data).

But I don’t really know what happened. Even with extensive logging, Unity lacks a solid debugger – and most of Unity’s code here runs BEFORE your debugger starts or AFTER your debugger stops. Any Unity bugs here are happening inside the invisible, opaque, known-to-be-buggy, Unity startup/shutdown routines. ARGH!

Software … has BUGS! OMGWTFBBQ!

Unity has bugs. Lots of bugs. So does all software. So what?!

Some (many?) of Unity’s many bugs sit in mission-critical parts of the engine. Rumour suggests that’s not because the devs are unaware of them – quite the opposite! – but because they’re too hard to fix. Any mistake in the fix, and it might cause more harm than the original bug (because these systems are so core).

This in itself suggests Unity’s internal dev teams maybe lacked a culture of TDD in the early days. My impression was that they do significant TDD now (yes? no?) but if it only arrived recently, then much of their code might be weakly tested or even untestable. i.e.: I try not to be too hard on them here, even when I’m suffering and there’s no help to be had.

In particular with Serialization: Unity doesn’t allow anyone to see what the bugs are. The Serialization system (along with some other super-critical-data-corrupting-bastard-evil-features of Unity – like the Undo system) has no API to let people outside of Unity corp see WTF it’s doing.

And we know it has bugs. But we can only guess at them, and how to workaround them. Unless you have a million dollars spare and can afford to purchase source-code access…?

Incidentally, this is why it is standard in the games industry to demand source-code access to your game-engine. This is non-negotiable. It has always been a black mark against Unity in professional / experienced gamedev teams that they are so secretive about their source code. It would be fine if they had a high-quality, Automatically Tested, well-documented accurate API, etc – but they don’t.

I have an idea … a new feature for my Entity System

At this point, I’ve already accidentally built quite a lot of the pieces of a debugger for fixing Unity itself. I’m recording the exact data, I’m storing it in memory in raw bytes (which sidesteps all the bugs in Unity’s undocumented serialization layers), and I’m displaying live data-visualizations in human-readable pretty colours, etc.

Enter: the Entity Systems Journal.

What’s a Journal?

If you don’t know, and you care about programming that involves data or storage, read this:
http://en.wikipedia.org/wiki/Journaling_file_system.

In the event of a system crash or power failure, such file systems can be brought back online quicker with lower likelihood of becoming corrupted.

What’s an Entity System Journal?

As many people have noticed, while experimenting with Entity Systems for their games, an ES is very easy to integrate with Event-driven programming.

You’re changing raw data which has no side-effects; that makes it very easy to write generic code that automatically converts every “change” into an “Event object” that the rest of your app / game can programmatically inspect.

With an ES, we’re going to use a Journal to record exactly what happened to your entire game-state, at all times, and in all places.

Journals in AAA Gamedev

To be clear: in an abstract sense this is nothing new, games have been doing “journalling” (But not calling it that!) since the 1990’s, when it was discovered to be a very effective way of making multiplayer / internet games run reliably while sending minimal data over slow network connections. Read about the early RTS implementations (Anything from Patt Wyatt’s blog, or the old Ensemble Studios gamasutra piece about 10,000 archers IIRC).

What makes this a little different is that we’re going to be a lot more … explicit … about it. Our Entity Journal will come with its own cross-platform API that’s easy to write tools for.

Considerations

a.k.a. “lessons learned in software design and architecture over many years and from standing on the shoulders of giants”

  1. The API itself might be best expressed using one of the API’s we’re already using to access and/or manage data elsewhere
    • aka: the “don’t screw-up like XML version 1 screwed up” rule; XML (a data langage) invented a second language to describe its data. Until they woke up one day and said WAIT A MINUTE … WE ALREADY HAVE A DATA LANGUAGE!
  2. Whatever first-class objects exist in the API need to be few, simple, and generic
    • Journals are a bit like Entity Systems: the simpler the API, the more robust and easier to optimize performance – and re-use with all the world’s generic data
  3. The Journal is a lot like Quake3’s networking compression; however we build it, it OUGHT to be compatible with that when finished
    • i.e. once this is implemented, it ought to be re-usable “in server mode” with almost no code changes to provide a multi-host non-uniform distributed event log and playback system. “ought to”.
  4. From a tools perspective, we want to click on any Journal event and see the exact state of the entire Game at that point in time
    • Game Debugging … on steroids. BECAUSE WE CAN, THAT’S WHY
  5. …which’ll destroy C#’s crappy Garbage Collector.
    • So we’d better be aggressive about using weak references and/or converting “old” data into “summary” data, and dumping the data itself
  6. Just like an FS Journal, the ES Journal should allow us to reconstruct our entire game data at any point in time, so that we never, ever lose data, no matter how many bugs in Unity we encounter
    • Unity: your refusal to debug and TEST your own frickin’ “undo” implementation? Yeah. I’m looking at YOU!
    • Make a stupid mistake in your game-code and accidentally delete critical stuff while in Editor? Not done a git-commit recently? NO WORRIES! GO BACK IN TIME AND RELOAD IT! YEAH!
    • Find a bug in the Entity System itself? (shock! Horror! But also: guaranteed to happen) … well, we’ve got you covered ;)
    • …(which leads to the next point)
  7. This absolutely unfailingly guaranteeably … must not have any bugs in it.
    • Unit Tests FTW
    • This is our equivalent to Unity’s Serialization: everything will rely upon the assumption that “the Journal will take care of it”, making the Journal our weakest link / most critical code
    • KISS: the simpler we keep the implementation AND the API, the more confident we can be that it works at all times in all situations

Building it

Yeah, well … that’s going to be a much longer article (or three!)

Want more? Want to support this ES in future?

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

[smlsubform emailtxt=”” showname=” mailinglist=”ecs-kickstarter”]