Intelligent “new (thing)” control for #unity3d

In Unity, hundreds of times a day you do “new (folder)” or “new (C# script)” etc. But Unity makes this ridiculously hard: you have to hunt and peck a tiny button and then hunt-peck a tiny item in a huge dropdown that is very easy to miss.

And you can’t do any of this from the keyboard. Even though you’re fully in keyboard mode and about to write the name of the New Thing (required!) and if it’s a script: type in the source code.

Screw that.

UPDATE: Now available in Asset Store – get the source

For a mere $2, I will Intelligent New you long time:

Source is included. If you want to see how I did it, knock yourselves out…

My context-sensitive New for Unity

So, what I’ve made today:


  • Select any folder or object in the Project window
  • Hit “shift-N” (because Unity sucks and steals Ctrl-N and refuses to let you choose a better one. Stupid stupid stupid.)
  • A popup appears pre-filled with a sensible new file name OR folder name
    1. If you were on a folder, it prepares to auto-create a new folder
    2. If you were on a script file, it prepares to auto-create a new script
    3. The name is pre-selected and editable, exactly as with Unity built-in
  • Sometimes that intelligent guess above will be wrong, so … hit Tab, and it switches type, while keeping the text selected and editable

Net result: super-fast workflow for creating new scripts and organizing your project.

(This required an ungodly amount of hacking and trial and error to work around bugs, bad documentation, and obvious missing core features from Unity APIs. But it works, and seems to be pretty seamless now)

Implementation Notes

A subset of the things I discovered / re-discovered on the journey to this one small fix / improvement:

  1. AssetDatabase.CreateAsset is basically broken: can’t create C# scripts at all. Don’t try.
  2. ScriptableWizard is unusable in Unity less than 5.0, because they made a core method private / non-overridable. Don’t bother.
  3. You can find the Project window and others by doing a reflection on the Assembly to find the magic C# Type of known Unity private classes (that SHOULD BE public!) and comparing at runtime. Hoops? Jumping through? Because an API has something private that should have always been public? Welcome to Unity customization! :)
  4. You can find the exact position of the selected row by adding yourself as a callback on Unity’s own row-by-row rendering of their built-in windows, and saving the data every frame. Sounds scary; works great (one of the few bits here that is a perfect hack with no downsides)
  5. Popups need you to create a new class, and that class MUST BE in file of its own or you will break Unity (internal bugs in Unity window management that trigger when you reload/restart Unity)
  6. …if you trigger that bug (or in any way end up with floating, non-closeable windows), go to the Layout menu and re-select the layout you’re already using. It will kill any unexpected windows. Phew!
  7. Unity still hasn’t made the Indent width (in pixels) public. The documentation insults you by saying that when you hardcode the number 20 this will break your code in future. YES, WE KNOW. SO MAKE THE DAMN NUMBER PUBLIC, YOU BASTARDS.
  8. There is a 2 pixel top and bottom padding needed to surround textfields in 1-line popups. I hardcoded this, it may have a number somewhere in the API. Good frickin’ luck trying to find it. Given the taunt about indents above, I very much doubt it is public.
  9. If you have a button or non-editable textfield with a changeable title, or anything that can be changed by a keypress during rendering, it is critical that in OnGUI you read Event.current.type and switch() on it. As far as I can tell, this has never been documented except in forum threads and blog posts by Unity staff. Once you know about it, you can sort of guess it from reading the undocumented bits of the API, but it’s damn hard to find references to it online. (I found it years ago by trial and error and blind luck). Until you do this you get race conditions when changing GUI based on keypresses. Ugh.


    Critically, this (should) work no matter how much I customized Unity elsewhere. It’s peeking into the actual window and render areas to decide what to popup and where on screen.

    The only conflict I expect is one that – thanks to some brainfart design at Unity corp – we can’t workaround: I had to hardcode “shift N” as the keyboard shortcut :(.

    Want it yourself?

    I thought it would take me about 10-20 minutes to do. HAHAHAHAHAHAAHAH! If I’d done this as a client project, I worked out it cost almost $1500 in billable hours. Ugh.

    I’m going to use this in production for a while. If it continues not to break or corrupt anything, I’ll put it on the Asset Store.

    Next up…

    …I’m going to do some context-sensitive New for the Hierarchy window, I think. Now that I have these hacks working, that’ll be quite a lot easier.

Rogue2015 April update

Added a level-select screen:

Screen Shot 2015-03-30 at 02.59.45

I say “level-select”, but … that background is a full 3D terrain, and the cities are procedurally generated/unlocked, so … it’ll hopefully become something a lot more, eventually.

#Unity3d’s missing core: No runtime objects

Here’s a game:

  • Player
    • Inventory
      • Gun 1
        • AmmoHolder
      • Gun 2
        • AmmoHolder

Some of those are 3D visual objects: Player, Gun 1, Gun 2.

Some of those are abstract concepts, or data: Inventory, AmmoHolder.

(in a Diablo clone, the Inventory might be a visual object, but only when you bring up the popup-window to display it. By contrast, in a simple FPS, your inventory may not be displayed at all – no need for it!)

Unity cannot handle this situation.

What you need


  • PlayerClass
  • InventoryClass
  • GunClass
  • AmmoHolderClass

In Unity, you have to make “everything” extend MonoBehaviour. That’s fine for PlayerClass and GunClass: you make a dummy GameObject for each, place it into the scene, and attach the class as a Component.

But that’s impossible for InventoryClass and AmmoHolderClass: if you make them into MonoBehaviours, Unity prevents you from using them as standard classes any more:

  1. Cannot instantiate them
  2. Cannot use Garbage Collection

…because they have no GameObject to be attached to – they don’t exist! They are abstractions only.

This is core to programming: we use abstractions all the time. Without them, coding would be horrendously inefficient both for the programmer and (to a lesser extent) for the computer.

What Unity offers

You have three alternatives here:

  1. Create fake GameObjects anyway. Put them “somewhere”. Work really hard to make sure they never accidentally appear in front of the camera (!), or interact with the scene due to physics (!), etc
  2. Use plain C# classes. This is an extremely bad idea: Unity has never supported C# classes for anything; Unity has a custom memory-management solution (called, slightly confusingly, “Serialization”) which is incompatible with plain C#. It requires every object to extend Unity.Object. You can workaround this; it requires major work and is very hard to get right.
  3. Use ScriptableObject, which appears to have been invented for this. According to many Unity developers: “this is what ScriptableObject is for”. However, that’s wrong. Very wrong.

ScriptableObject to the rescue?

So … ScriptableObject is something that extends UnityObject (fixing the problem of “plain C# classes aren’t compatible with Unity”), and you can use in a Scene, and can be referenced by MonoBehaviours, and just work, right?


ScriptableObject is all those things, except: it doesn’t exist in the Scene. It’s an Asset.

This is where Unity docs really screw the pooch. We know for a fact that an SO is an Asset; when we try to use it like a MonoBehaviour, several things break and stop working.

…but it also “kind of” works in-Scene. The docs have no explanation for this. What are the limits? Well, basically: no-one knows, except through trial and error. This is so core to your code that it sometimes instead means:

trial and oh-crap-that-didn’t-work-time-to-rewrite-every-damn-class

Why is Asset-hood so bad?

You already have all that – it’s called the Class – and to have an Asset too simply creates problems:

  • An Asset is a special thing in Unity. It interacts with Unity’s core systems in very different ways to a C# object. Building, runtime Loading, editing in the Editor – all are “different”.
  • You can’t create them in the Editor. (you can write your own hack/script to fix this. It’s only 10 lines of code. But … yeah. It’s a hint that this isn’t what Assets are intended for)

But .. what’s ScriptableObject for?

Unity’s official docs are rather … incoherent … on the subject. My guess is that they were written by someone who didn’t really understand ScriptableObject, and was looking at the source code thinking:

WTF is this? Um. Err. Well … it kind-of seems to sort-of do … this? Maybe?

…and worked it out from observation.

What the docs are TRYING to say is:

(gross over-simplification here to make things easy to understand): Unity’s memory-management COPIES every instance many times, and doesn’t support pointers/references.

This is a HUGE problem in game-development.

ScriptableObject is a workaround that uses diskspace to make templates out of objects, and then simulates pointers by using one shared-file on disk to hold the data for thousands of in-game objects.

This works very well, because the way we built Unity’s core architecture (3D Meshes, Textures etc) already supports that workflow: File-on-disk generates optimized in-memory-object, which is shared/batched wherever possible.

Going off on a tangent, it waffles about “ShopStore” and “Multiple Scenes” and stuff that the author clearly didn’t really understand. The obvious way of implementing what’s described in the docs is many times simpler, and works much better – you would never do it using ScriptableObject.

What the docs perhaps should have instead said was:

You can also abuse this system to make hardcoded fake in-scene objects that don’t have to be attached to a GameObject.

This will fail if you have any Procedural Content – but Unity was specifically designed never to be used in games that have procedural generation, and no-one should be doing procedural work in Unity, so that’s fine.

Wait … what? What do you mean “we all do procedural generation”? Wh … why? Why would you do such a thing? do you have any idea how slow that will be in Unity? Most of our code assumes everything is done at compile time! We can’t handle dynamic code!!!

(NB: Unity used to be really, really bad at procedural work. Way too slow. There’s really no reason not to be doing tonnes of procedural code in Unity games today – except that Unity itself still has a load of political blocks on it. It doesn’t support procedural properly in places where it could)

ScriptableObject is great, but most game-development works with procedural content. I’m not talking about complex cool stuff like Sir, you are being hunted. I’m talking about stuff like:

The set of objects in your inventory changes from moment to moment while you play the game. Because otherwise it would be a pretty boring game

When you try to use ScriptableOject here, you are abusing it. It’s not intended for that, it doesn’t work correctly with that, and it’ll make your life hard. IT’s not ScriptableObject’s fault; it’s your fault.

What does Unity need?

At a conceptual level, Unity has:

  • “Physical Runtime objects”: things that have 3D physical presence in the editro (not Physics as in “Physics Engine”, but rather: everything has a Transform)
  • “Runtime OOP Objects, dependent upon GameObject”: generated from OOP Classes (but MUST be attached to a Physical Runtime object)
  • “Compile time OOP Objects”: these are Unity Assets, and can be used for some performance and coding tricks. They are they poorly-documented ScriptableObject, and should probably have been named ScriptableAsset in the first place since they are absolutely not Objects!

What’s missing?

  • “Runtime OOP Objects, independent of GameObject: the classic “Object” from OOP.

I think … not sure, this seems obvious, but if so: why is not already the case? … I think: Unity should be saying “make your classes extend ‘Unity.Object’, and then use them. All will be fine. We’ve made it work under-the-hood; trust us, guys, it’s cool. Everything’s cool.”.

My guess is that’s some internal bug with Unity Serialization that makes this untractable. Maybe something like:

GUESS: Unity Seriailization is internally hardcoded with a fixed number of recognized classes, somewhere, that can only be added to by hardcoding new ones. Because we don’t have access to Unity’s source code, we cannot re-generate those, and the Unity Editor (for same reason) can’t do it for us.

So: our legitimate C# classes can never be fully treated as a Unity Class.

Instead, Unity has to support a fixed number of hardcoded classes (O hai! ScriptableObject, MonoBehaviour), and those have to use reflection tricks at runtime to provide (limited) support for the infinitely many user-authored clases from C#.

OK, so this is slightly more than a “guess”. They have form here: When trying to figure out some obscure Unity Serialization bugs, I found some places where Unity would load extra, hidden, information for particular Unity classes. There was nothing in memory on this, suggesting that they had hardcoded a lookup for their set of “known” Unity classes, and were getting the data that way.

…but that’s the kind of thing that’s going to be a genuine mind-f*ck to try and unravel. This makes me inclined towards it: even with the money and resource Unity has, it would be non-trivial to fix. And I’m pretty sure no-one likes the status quo.


We’ll just keep writing source code like it’s 1999:

  • Use C# as if it’s C
  • F*ck Garbage Collection (we can’t have it :( Sob.)
  • Manually memory-manage the scene and objects; make everything a GameObject, and manually Destroy() everything each time you replace it or it goes out of scope
  • As a bonus: the Unity Editor has much better support for Developing and Debugging games which use GameObjects than it does for any alternatives (C# Classes; ScriptableObjects)

I’m crossing my fingers that Unity version 6 will dump Serialization, and this problem will go away. Like magic, Unity will fully support C# (Dictionary’s! Objects! Garbage Collection! YAY!)

…of course, by then, I might have finally switched to Unreal. Because frankly I’ve got better things to do with my life than work in low-level programming languages!

Giving OpenOffice a “not disgusting” New Word Document

OpenOffice is great. It has flaws. One of the most insidious is that the “new document” settings for Word/Letter documents is vile. It has truly awful formatting – ARGH! MY EYES!

Today I was writing a doc to put down some thoughts for colleagues, and I realised that the formating is so unbearable it was actively blocking me from thinking or expressing myself clearly. Every glance at the words in front of me was corrupted.

So, I’m going to do some experiments in replacing it with something … “not s**t”.

Download a template

Not possible. The website has never worked – I’ve been using it for 10 years, and the Template Search is still 100% broken. “Sort by rating, Descending” and the top-rating is often … 0/5 stars. Um. No. Guys – can you please learn how to count to 1?

Screencap from today:

Screen Shot 2015-03-25 at 14.11.44

Make a template

Here’s the steps, if you want to do one yourself: How can I change the defaults for a new Writer document?

Attempt 1: Verdana, indents

Arial – especially using Arial Bold for every-other-heading – is painful on the eyes when a document has more than about ten words. Let’s dump that and – sticking with a common font everyone has installed, but is similar in look – go with Verdana.

I do not enjoy using Arial, Verdana, Helvetica etc in docs; but I have no idea how funky you can get today and still get 100% coverage of “this font is installed on everyone else’s computer, no download/import/conversion needed”

Looks like this:

Screen Shot 2015-03-25 at 14.07.59

DOWNLOAD LINK: Default Text (Verdana)


There’s a circle of hell set aside for the muppet working at WordPress who decided to block all files that he/she couldn’t be bothered to type into a pointless – BUT NOT UPDATEABLE – whitelist of filetypes.

That’s not what a filename extension is. It’s not what a filetype is for. Great example of “a little knowledge” (or in this case: no knowledge at all, just foolish assumptions) being a dangerous thing…

Some thoughts on loading Scenes in #unity3d

How do you program a “level”?

This is not usually a problem in a game engine, but Unity requires you to isolate each “level” as a Scene. And Unity’s Scenes have some strange design choices (bugs?) – IMHO they were designed for toy projects, not for production games.

Here’s a stream-of-consciousness on what works, what doesn’t, and how I can workaround / do it better within Unity… it’s not carefully researched, mostly it’s from memory / off the top of my head. So … it might not all be true :).

When I switch to Unreal4, I’ll be using posts like this as a baseline to compare where Unity failed, and how badly – or vice versa.

UPDATE: added some more approaches and ideas/commentary

Continue reading “Some thoughts on loading Scenes in #unity3d”

Fix #Unity3d’s broken OnMouseDown

This one has annoyed me for years: Unity’s OnMouseDown has never really worked. (NB: it works perfectly if you make a scene with a single cube; but that is not a game. It breaks completely as soon as you add multiple objects, colliders, etc to a scene)

The main reason to use a 3rd party engine is to avoid re-inventing the wheel; it’s tragic that Unity can’t even do mouse-input out of the box. Let’s fix it!

Continue reading “Fix #Unity3d’s broken OnMouseDown”

Blender tips: set your 3D lights for edit mode

When you first install Blender, DO THIS!

Menu: File > User Preferences… > System

Screen Shot 2015-03-04 at 10.02.37

When you look at objects in edit mode, they’ll look something like this:

Screen Shot 2015-03-04 at 10.02.49


Blender makes it very easy to get a face back-to-front.

Or to have two faces overlapping.

Or … any number of other topology bugs. At best, these kill performance in any game that uses them. At worst, they cause nightmares for your programmers and level architects when Weird Stuff Keeps Happening. They can even cause crashes (e.g. a surface that has strange holes, or inside-out faces … and then gets processed by collision detection).

This lighting setup tells you at a glance if your normals are correct. Which in turn tells you if you have pieces out of place, or if you have an angle between faces that’s smaller/bigger than you expected (quite common to spot a pair of faces that have a sharper angle than expected/intended).

Bonus: 3D printing

If you’re 3d printing, the mistakes that slow down or crash a Game engine … will cause 100% failure of prints (Wasted time, wasted plastic – and in some cases I’ve seen: damaged printers!).

So, yeah. Getting this wrong can cost thousands of dollars. Don’t do it; replace Blender’s defaults with something sane that works :).

Blender UX for the lose

This should be the default. But then … Blender’s team seems philosophically opposed to doing anything the easy way :).

Unity3D: display a variable instantly on screen

You need this ALL THE TIME when developing, and Unity lacks it as a core feature:

  1. Create a Text label on your GUI
  2. Drag/drop a variable onto the label, and it will automatically display the value

Completely impossible, due to short-sighted design decisions in the Unity Editor from 10 years ago that never got changed. So, let’s fix it. It’s hugely annoying not being able to do this!

Continue reading “Unity3D: display a variable instantly on screen”

Promoting an Indie game: what should you link to?


Every Saturday, thousands of indie / hobbyist game developers publish screenshots of their in-progress games. Unlike most forms of marketing, this is:

  • honest / genuinely representative (it’s actual content)
  • interesting (show’s the dev’s intentions)
  • exciting (pictures of games are usually more fun than words)

i.e. … it’s an amazing marketing tool.

But many game developers are screwing this up. A year ago, I posted a long list of advice, tips, and explanations – worth reading. But some devs are still misunderstanding / screwing this up. So, what should you do?

Continue reading “Promoting an Indie game: what should you link to?”

#Unity3D plugin review: Advanced Inspector

The author of Advanced Inspector gave me a free copy over Christmas. I’d considered it many times, and always ended up choosing not to buy, and write my own fixes/workarounds instead. So I was keen to try this out on a hobby project and see how well it works in practice.

What is it?

A replacement for Unity’s built-in Inspector. This (optionally) changes the editing interface for every single Component in your Unity projects.

Why do we need it?

When you run Unity, you get the standard multi-pane IDE that is the Unity Editor. Whether you’re a programmer, a designer, or an artist, this is your main portal into Unity, and the starting point for all your work.

Anything you select in the 3D/2D scene causes an Inspector panel to appear, with all the editable data about that thing. Unity’s built-in Inspector is very basic; by modern standards of GUI/UX, it sucks. Fixing GUI is very expensive, so instead … Unity has gradually been making the Inspectors more and more customisable.

Traditionally this was very hard to do; in the last 12 months it has become much easier, and Unity has unlocked more features. To date, I’ve not been sure if the 3rd party plugins are fully using the new features.
Continue reading “#Unity3D plugin review: Advanced Inspector”

Easy parametric animations in #Unity3d with code and curves

iOS forces you to use pretty animations: if you don’t tell it otherwise, it will use “ease-in/ease-out” curves to make things feel … smoother, less jerky.

Unity is made for programmers; changes you make to position, size, rotation, etc all happen instantaneously. By default, they won’t even animate, will teleport instead.

So … moving from “prototype with no animation” to “prototype that won’t hurt people’s eyes, and I can share”, what are some tips and gotchas?

Continue reading “Easy parametric animations in #Unity3d with code and curves”

A Whiteboard Xmas Card for everyone

What can you draw with a whiteboard, if you’re not an artist? Let’s see..

Many of my friends live on different continents. It was too late to post cards, and I was staring blindly at my whiteboard when I had an idea: A picture for everyone, photographed, emailed … Then wiped clean. A transitory, ephemeral, virtual gift made out of something physical and real.

(there’s a background to this, see below the images)

PS: apologies for variable quality – I was doing these as fast as possible, trying to get them out same day (Xmas Day).

IMG_20141225_224459 IMG_20141225_225137 IMG_20141225_230807 IMG_20141225_231300
IMG_20141225_232047 IMG_20141225_233613 IMG_20141225_234827 IMG_20141225_235750
IMG_20141226_000710 IMG_20141226_012840 IMG_20141226_013834 IMG_20141226_014528
IMG_20141226_020551 IMG_20141226_021514 IMG_20141226_022811 IMG_20141226_030250
IMG_20141226_031039 IMG_20141226_032140 IMG_20141226_033113 IMG_20141226_122938
IMG_20141226_123945 IMG_20141226_125359 IMG_20141226_133850 IMG_20141226_134557
IMG_20141226_135051 IMG_20141226_155430 IMG_20141226_160437 IMG_20141226_220730
IMG_20141226_222932 IMG_20141227_172428 IMG_20141227_174607 IMG_20141228_171110

If you didn’t get one, well … Maybe you should keep in touch more, my friend!

But seriously: I’m not finished yet. Watch your inbox.


This Christmas, I did my first serious drawing/painting in 15 years, as a gift for someone. I was surprised (actually: stunned) how well it came out. Unfortunately, it wasn’t appreciated.

I wanted to make something positive out of it, anything. I’d poured too much time into that, and too much care, to write it off and move on.

Here’s the results. I took the theme of my original hand-made card: an image specific to the recipient, something that they (and their close friends) would recognize and understand immediately.

There’s a few that tie obviously to well-known people in Web, Education, Games industries.

Unity’s failure as an Entity System, example 1: Selecting things

Entity Systems in Unity… some examples of the problems

This is a new series of blog posts, where I’m going to document specific ways + concrete examples in which Unity fails (sometimes spectacularly) as an “ECS” game engine.

I like Unity; but the core architecture (which is very old) is a half-assed ECS, and if we’re to upgrade it into a really good, modern, architecture … we first need to understand exactly where it’s failing, and why.

So, let’s start with Selecting Things…



A 2-player card game where each player normally draws a card each turn, and then plays one or more cards. Sometimes (e.g. when discarding because “too many cards in hand”) they have to select more than one card at once.

Initial version of game will be 1-player versus computer. Very soon: want to upgrade to OPTIONAL 2-players on-screen, with one using the mouse, other using gamepad. Ultimately, want to also add over-the-internet multiplayer (which ends up interfacing with the codebase in a very similar way to the original 1-player-vs-computer, so we can ignore for now).

Code Situation

Player taps card. Now … we must inform many other scripts and independent systems, so they can choose to eg.

  • ignore (if invalid for current state of game)
  • react (e.g. zoom to display the card more clearly)
  • “select” internally (side-effects include: deselect other things)
  • advance the game (if it was waiting-for-input)
  • ..etc


What/where do you send the “player clicked on a card; can some piece(s) of code PLEASE deal with this??!!?” ?


In Unity, only the low-level “card” object can sensibly detect it has been clicked on.

Both Unity’s Physics (old) and EventSystem (new) effectively force this via their core design. Both require you to attach scripts to the physical objects that will be clicked.

In practice, this is bad for OOP (and bad for ECS too). When there’s e.g. 100 cards all of which must be separately clickable, your code is really in the wrong place. You don’t want cards (which sometimes are in a deck, sometimes on the table, sometimes “virtual” (perhaps in a virtual, unopened booster pack etc)) … to be containing all the GAME logic required to know what to do when they’re touched!

Classic Entity System / ECS solution

  1. Create a SelectedByPlayer component
  2. Add it to the card
  3. Sit back, and relax. Code that cares about input will scan “get me all SelectedByPlayer components” on each frame, and react accordingly

Everything works automatically; any System/Processor that’s “waiting for a selection”, or “making render changes when selections add/remove”, etc … will pick up what it needs, with no work.

You can add new input-handling routines simply by adding them. That’s all. No other changes needed.

Attempting to solve this in Unity

UNITY 4.6/5.0

Maybe … NB: I’ve only just started using the new GUI/EventSystem in Unity 4.6+ .. create a custom Input event, and a custom InputModule that can understand that, and then put all the code for ALL affected systems/processors into one monolithic ugly, hard-to-maintain script from Hell.

I suspect that this code will be quite maintainable w.r.t. adding new Input hardware in future – e.g. allowing mouse vs gamepad. But it’s going to suck at the rest, all the business-logic and handling. Which is going to be > 95% of the maintenance cost.

You get one small benefit: you can separate-out different inputs (click versus drag). Sadly, in reality: 95% of game actions will be simple clicks. This is one of those “the code architecture sounded great in academic situation, but reality is so unbalanced, it works out less well in practice” situations.

This is a classic OOP solution, and has the downsides. The only significant benefit I can think of is that it’s a “known” Hell: if you’ve done a lot of OOP game coding, you’ll be familiar with the pain you’re going to run into.


Make a new class “CardClickManager” whose sole purpose is to reference all the possible bits of OOP code that “might” need to react, and which has to be updated by hand EVERY TIME you modify, add, or remove some input-handling code ANYWHERE else in the codebase.

Pretty much the same as above, except it:

  • … is even more simplistic (no event-dispatch systems)
  • … making it even harder to maintain + debug
  • … is slightly more proprietary

Conclusions / Improving Unity

So far, I cannot think of any sane, maintainable solution here other than “suck it down and use OOP, and suffer forever”, or “throw away Unity GameObject/Component, and implement a proper ECS”.

That’s fine, though. That’s the point of these posts – to hilight situations where there’s no good middle-ground, where we must create the data-centric, cleanly-separated architecture of a modern ECS.

Counter-ideas very welcome! Comment away, guys…

Makerbot Replicator2 Upgrade: new fan duct

I reviewed a whole bunch of these on Thingiverse, and the best combination of simplicity and effectiveness appeared to be this one:

…but you want to print these at 0.1mm layer height, or less, and that’s difficult with the model above. So I tweaked it a bit:

NOTE: The WordPress authors can’t be bothered to implement safe/secure uploads; instead, they block ALL uploads (which is very stupid and doesn’t solve ANY security problems). This file has to be renamed when you download it. Stupid, stupid, stupid programmers.

WordPress Is CRAP.stl


The original model has two small circular screw-holes. Makerbot printers can’t print these very well – Both the official slicer, and the main commercial / open-source slicers get it wrong and print the holes in a bad way (untethered; it’s an obvious heuristic to fix, but no-one has implemented this yet). Net effect: the holes slide about during layer 2, and usually detach, and ruin the print.

To fix this, I cut a slice out of each hole, making them into hooks. This follows the design of Makerbot’s original fan duct, and makes the print easy to do even at high speed and low layer-height.

3DPrinting tips: cooling, fans, and PLA temperatures

This is hugely important to 3D printing, and generally: no-one talks about it online (at least, not with any authority: more “blind leading the blind”). Which is silly: the engineering behind this is obvious (and it’s often obvious from looking at a 3D printer that it’s been under-engineered in this critical area).

NB: I don’t know which parts of “correct, obvious” cooling are blocked by stupid patents that should never have been granted. That might excuse the poor design of most printers today. Might.

My experience so far is that “more cooling of printed object is better”. But that’s an over-simplification…
Continue reading “3DPrinting tips: cooling, fans, and PLA temperatures”

Towards a Unity3D ECS: what GUI? What features?

This year, one of my goals was to build a sane, powerful, viable Entity System / Entity-Component System within Unity3D. Something I could build current and future games on, and save a lot of dev-time (both in ease-of-use and in easily adding missing features that I wish Unity had).

So, progress?
Continue reading “Towards a Unity3D ECS: what GUI? What features?”