All posts


Game development








Hello! I'm Tom. I designed a game called Gunpoint, about rewiring things and punching people, and now I'm working on a new one called Heat Signature, about sneaking aboard randomly generated spaceships. Here's some more info on all the games I've worked on, here's the podcast I do, here are the videos I make on YouTube, here are some of the articles I wrote for PC Gamer, and here are two short stories I wrote for the Machine of Death collections.


By me. Uses Adaptive Images by Matt Wilcox.

Sectors Header

Teaching Heat Signature’s Ship Generator To Think In Sectors

DXHR Open area

What Works And Why: Multiple Routes In Deus Ex

Heat Signature Natural Numbers

Natural Numbers In Game Design

Pharma Header

Naming Drugs Honestly In Big Pharma

Writing vs Programming

Make A Game Tutorial Thumbnail Featured IMage

Let Me Show You How To Make A Game

New Heat Signature Video: Galaxies, Suction And Wrench-Throwing

Her Story banner

What Works And Why: Nonlinear Storytelling In Her Story

My Idea For An ‘Unconventional Weapon’ Game

From Gunpoint To Heat Signature: A Narrative Journey

The Cost Of Simplifying Conversations In Videogames

Invisible Header

What Works And Why: Invisible Inc

Super Game Jam Header

Our Super Game Jam Episode Is Out

Shadow of Mordor Header 2

What Works And Why: Sauron’s Army

Heat Signature Talk

Showing Heat Signature At Fantastic Arcade And EGX


What I’m Working On And What I’ve Done

Murder, She Wrote

The Formula For An Episode Of Murder, She Wrote

Heat Signature Wide 2

Heat Signature Needs An Artist And A Composer

Heat Signature Floorplans Header

Improving Heat Signature’s Randomly Generated Ships, Inside And Out

Gunpoint Steam Workshop

Gunpoint Patch: New Engine, Steam Workshop, And More

Distance Header

Distance: A Visual Short Story For The Space Cowboy Game Jam

The Magic Circle

Raising An Army Of Flying Dogs In The Magic Circle

Floating Point Blog Launch

Floating Point Is Out! And Free! On Steam! Watch A Trailer!

Floating Sine

Drawing With Gravity In Floating Point


What’s Your Fault?

Hoplite banner

The Randomised Tactical Elegance Of Hoplite

Gone Point

Here I Am Being Interviewed By Steve Gaynor For Tone Control

Heat Signature Thumbnail

Heat Signature: A Game About Sneaking Aboard Randomly Generated Spaceships

GRappling Hook Thumbnail

The Grappling Hook Game, Dev Log 6: The Accomplice

Alien Swarm Heroics

A Story Of Heroism In Alien Swarm

FTL Story

One Desperate Battle In FTL

Spelunky Banner

To Hell And Back In Spelunky

Game vs story graph

Games Vs Story 2

Gunpoint Breakdown

Gunpoint Development Breakdown

Max Payne 3

Five Things I Learned About Game Criticism In Nine Years At PC Gamer

This is how you die

My Short Story For The Second Machine Of Death Collection


Not Being An Asshole In An Argument

Skyrim Diary - Frostmere

Playing Skyrim With Nothing But Illusion

Mainstream Games

How Mainstream Games Butchered Themselves, And Why It’s My Fault


A Short Script For An Animated 60s Heist Movie

Dark Messiah

The Magical Logic Of Dark Messiah’s Boot


Arguing On The Internet

Stealth Games

Why Are Stealth Games Cool?


E3’s Violence Overload, Versus Gaming’s Usual Violence Overload

Suspicious Manifesto

The Suspicious Developments manifesto


GDC Talk: How To Explain Your Game To An Asshole


Listening To Your Sound Effects For Gunpoint


Understanding Your Brain

What Makes Games Good

What Makes Games Good

Seat Quest

A Story Of Plane Seats And Class

Beneath Suspicion

Avoiding Suspicion At The US Embassy

Open Worlds

An Idea For A Better Open World Game

Level Up

A Different Way To Level Up

BioShock Ending

How I Would Have Ended BioShock

Meet the Spy

My Script For A Team Fortress 2 Short About The Spy

Team Fortress 2

Team Fortress 2 Unlockable Weapon Ideas

Football Manager

Don’t Make Me Play Football Manager

EVE Assassins

EVE’s Assassins And The Kill That Shocked A Galaxy

GalCiv 2

My Galactic Civilizations 2 War Diary


I Played Through Episode Two Holding A Goddamn Gnome

Machine of Death

My Short Story For The Machine Of Death Collection


A Woman’s Life In Search Queries

Second Life

First Night, Second Life


SWAT 4: The Movie Script

GHGC Dev Log 3: Grappling With Hooks

Yep, it’s got a grappling hook!

I have something in particular I want to do with grappling hooks that I’m not ready to talk about yet. But grappling hooking around is also part of a set of interactions that I hope are going to just feel really nice – to some extent this game would be about the pleasure of execution.

This is just a quick demo of how it’s working right now – shoddily, but well enough to give me an idea of how to refine it. I’m pretty pleased to have got this far in three days, despite still really struggling with some Unity stuff.

A question for experienced Unity users:

I’m having trouble understanding how I’m meant to make different components talk to each other.

I have one component that handles the ‘fire a grappling hook’ code.

In that component, I use a boolean variable called grappleAttached to keep track of whether we’re currently grappling.

Other components regularly need to know this information too.

The component that handles walking left and right, for example, needs to make those controls behave differently if we’re grappled onto something.

This is going to come up a lot – almost everything you can do will depend on whether you’re grappled or not.

The only way I know of having any other components access this variable is with GetComponent.

This seems to require three different lines of code: one variable declaration, one in Start to store the component as a variable, and then another wherever I want to check grappleAttached.

Is that really the best way to do it? It seems like a lot of mess, and a lot to change if I ever move that piece of code or rename the component (which seems to be difficult, but commonly necessary as I experiment with what each component should do). I’ve also been warned that GetComponent is slow.

Similarly, I’ve written a function to get the position of the cursor. Do I have to do this whole process in every script on every object that ever needs that information?

Thanks for any advice.


Logan Blackburn: Yeah, it's best to cache off the component since GetComponent is an expensive operation. That's the best way I've seen to do it.

For the other question, you could make a utility class to store/update the cursor position on screen if you wanted. Nothing wrong with that. Use static functions for getting the position so you can call it wherever with MouseUtil.position() or something like that.

Causeless: Called it!

"Wow, I should try Unity! I'm making a simple 2d game engine (so far without collision, lighting, or much fancy), and it's much larger than your code? there.

Lemme guess the movement mechanic - grappling hook. I'm planning to use that in the game in my engine, though mines is set in space (and thus, weightlessness), so is a bit different.

Don't be afraid to voice the mechanics. Other people won't steal it, because they all make their dream games - not mines, or yours.

Congrats on your progress!"

Meathelix: Logan does it the way I would recommend. One other step is that you can tell a component that it requires another specific component on the same gameObject in order to work properly. That way you know that GetComponent will always return something of use.

Causeless: Oh also, I detailed how I'll do it:

BTW, if you are interested in how I am going to do it (which you probably aren't :P), I plan to implement grappling hoops "wrapping" by detecting the point on a vector that intersects, and creating a new grappling hook at that point connected to the character (and keep the previous one/s, pointing towards their children)

To determine how they'd unwrap, I would raycast to that hook's parent hook until it is no longer occluded, then delete the child and attach the character to the parent.

Andrew Noon: I second Logan's suggestion above that if you find yourself having to hold references to a component in multiple scripts then it's a prime candidate for a static function in a singleton class. Unity themselves do this a lot in the API so it doesn't feel too out of place.

I'd also advise using the generic version of GetComponent (e.g. GetComponent) rather than the string equivalent. This means changes in component name and typos are picked up at compile time rather than runtime. It's also a bit faster too, but this is less important as you should only be getting the component once and then caching it for future usage.

Tim Temmerman: Hey man, somewhat new to Unity as of a few months ago, I was also struggling with this concept on a game we're working on. I learned a few methods of getting objects to talk to each other, and actually made me appreciate Unity even more.

The best way to do this is by defining your component class as "public", and any variables you want accessed by other scripts as "static". Don't worry, static vars can still be changed by the owning script.

So for example, you have a grappling script called GrappleManager, and it would have a variable called bGrappled or whatever. You'd initialize bGrappled as "internal static bool = bGrappled".

Then for your player class, you wouldn't have to find or do a GetComponent for GrappleManager. You could just reference it as "GrappleManager.bGrappled" , and it'll find it. I think the downside is, being static, your player class can't modify bGrappled. But that's ok -- you'd just have your player class run a static function inside GrappleManager that modifies bGrappled.

You could still do GetComponent(), but I wouldn't use it often. It would be better to initialize the GrappleManager as a saved variable on your player class, that way you're only using GetComponent() once. So in your player class you'd have a variable like "public GrappleManager GM", then in the Unity editor you could drag the GrappleManager script from the hierarchy into the PlayerClass field for "GM".

Email me if you have questions --

Laurens Mathot: I mainly use two methods for communication between components.

When the component is on another GameObject, I use public variables (or actually, serialized fields, but the difference isn't super important right now), that allow you to drag in GameObjects with the component of the given type on them, using the Inspector window and the Hierarchy window in the Unity Editor.

When the component is on the same GameObject, I usually use GetComponent (or one of the built in references, like 'collider' or 'transform').

Like Logan says, it is a good idea to store the result of 'GetComponent()' or 'myGameObject.transform' in a variable if you're going to be using it more often, because you might need quite a few of these, and together they will be quite expensive.

In some cases, where a method that is rarely called might not always need the reference right after loading the level, I don't retrieve the reference in the Start or OnEnable methods, but by checking if the reference is not yet set. (if (someTransform == null) someTransform = this.transform;)

I guess a static method might make sense for Mouse Input, because you rarely need more than one type of mouse input. But I usually prefer non-static methods.

For renaming variables I usually use MonoDevelop's built in renaming system (I have it bound to F2, which is similar to the key used in Windows). It will search the project for references to that specific method or variable, and change it (it takes longer for public stuff, because it needs to search outside the file where the method or variable is defined). Keep in mind that if the files are open, they still need to be saved manually after the change (it's easiest to have other files closed while you change a name, they will automatically be saved). And when you want to rename a component class, you should first rename it inside the Unity Editor, and after that in the code itself. If you were to only change it in the code, Unity would not know about the name change, and the scene might lose references to things with that name.

Ian Hetu: For components that there is only ever going to be one of I recommend using the singleton pattern:

-In the component create a static instance member for the component type
-Initialize it to 'this' somewhere (I recommend OnEnable)

class Foo : MonoBehaviour
public static Foo mInstance;

void OnEnable()
mInstance = this;

Once you have done this, you can quickly get access to any of the public variables on the class from anywhere else by referencing them through the static accessor:

Foo.mInstance.var1 = whatever.

This also saves you from having to make a ton of stuff in the class static, which can get confusing.

This is how I handle things like this in my unity game. However, there are lots of different ways to attack this problem, and mostly it comes down to what feels best for you and matches your coding style.

Let me know via twitter if you have any other questions: @Pigo

amiapro: You could use a "controller" : a component that is a singleton ( you can only have one object of that type in the game ) that you can access easily.

public class PlayerComponentsController : MonoBehaviour {

// List of all the component you want to access.
public ComponentType1 m_component1 = null;
public ComponentType2 m_component2 = null;
public ComponentType3 m_component3 = null;

// Singleton.
// Actually it's not a true singleton but the idea is there.
private static PlayerComponentsController m_instance = null;

void Awake( ) {
m_instance = this;

public static PlayerComponentsController getInstance( ) {
return m_instance;

// Initialize components.
void Start( ) {
// GetComponent( ) is a lot faster than GetComponent( string ).
m_component1 = GetComponent( );
m_component2 = GetComponent( );
m_component3 = GetComponent( );


This has to be attached to the player.
Now anywhere in your code you can access a component by typing :

PlayerComponentsController.getInstance( ).m_component1;

If you need the same thing for another object you need to create another class ( because of the singleton ).
Hope this helps.

Laurens Mathot: Singletons almost always seem like an extremely elaborate hack for just getting 'easy' access to a set of methods.

I don't like 'em.

Micael: There are also a good amount of arguments against singletons, one of those in the context of unity (or video games) can be found here http://blogs.unity3d... ...rgroup-11/ first video minute 10, which is very much applicable to this situation, since for example if one was to implement MP (which tom francis said the game might have), then having a single state of is hooked wouldn't work (I think), since one would require one for each player.

With all that being said, considering it's a prototype and that prototype code is in theory made to be disposable (as in being completely eliminated), one doesn't really need to worry about good coding practices (which are subjective).

amiapro: A "controller" as a singleton can hold other things such object states and serves as a communication layer between different objects ( some kind of model view controller ).
But you're right it might not be the right thing here.
I often directly use GetComponent( ).doSomething( ) directly without storing the component. The thing is that if you call GetComponent only a few times per frame, performance is not issue. But always profile to know the impact.

Andrew Osthoff: (a MOOC site) is currently doing a course on programming in C#. It looks like they use it with XNA, which is maybe less useful depending on your jam, but it could be helpful depending on where one is about in Unity scripting (at least that's what I'm hoping, God help me) :)

Trevor: Grappling Hook God Cube.

Bam. There's the title. You heard it here first, folks.

Gunpoint problem?

Don't post them here, I'm a useless idiot! E-mail tech support with as much detail about your system and the problem as possible, and they can actually do something.


There's a page about the games I've worked on, what I use to make them, and what platforms they're coming to.


URLs get turned into links automatically. You can use <i>HTML</i> but not [b]forum[/b] code.