ENGINE FIIIIGHT: Unity vs Unreal vs CryEngine

First off, it’s been a long while since I posted. I’ve been, as I suspect the youths might say, hella busy. Including of course lots of new game stuff, which I’ll blog about soon. But in the wake of some huge engine announcements at GDC ’14, I thought I’d sit down and have a good old reckon.


If it wasn’t clear, my game currently uses Unity and I’m already very fond of it. I like the component paradigm, I like the editor-centric development, and I’ve surprised myself by really liking C#[1].

Perhaps more importantly – I’m a big fan of Unity the company, and I want them to succeed. I have numerous bones to pick with them[2] but I love what Unity has done to indie games. It’s been a driving force in the democratisation of game development, and that is in every way a good thing[3]. I like their business model – having a solid free version which allows commercial usage is fantastic both for devs and Unity, and I think the Pro version is pretty reasonably priced. So – this post is born of love.



Right now Unity could be in serious trouble. On Tuesday 18th, Unity announced Unity 5. It answers a few outstanding issues[4] and introduces a raft of new shiny. Release date TBC, but optimistically, this summer. Pre-orders are live, and you get 4.x Pro included in the meantime. Nice.

On the 19th, Epic Games shat all over the Unity announcement[5]. Arguably the biggest engine in the world, Unreal Engine, got an upgrade to version 4, and came down in price from ~$500K… to $19 per month plus a 5% gross revenue cut. Nineteen dollars per month. Then I read on. That $19 includes the entire source code. I genuinely thought it was a hoax.

Then, on the 20th, Crytek[6] joined the brawl and tried their best to out-ridiculous Epic by announcing CryEngine3 was now $10 per month per seat with no revenue share. Honestly, I was still too stunned by Epic’s move for this to have the intended effect.


So, I titled this post Engine Fight[7]. But I’m not actually too interested in all the new features. Here’s where I take a long hard look at what I like about Unity, and in contrast, what it makes me put up with. Those little niggles that aren’t so little when you suddenly have cheaper, arguably more professional options shoved in your face, threateningly grunting and gesticulating at you with imaginary pistols[8].

I also put CryEngine in the title, but honestly I don’t really care about CryEngine. It’s challenging to work with (so I hear) and I suspect the vast majority of indies will  go with UE4 almost by default. The price difference for small indie teams is minor[9], and lots of people might think source code access will mean they can solve any problem that comes up[10]. It’s an interesting piece in the HOLY SHIT WHAT JUST HAPPENED puzzle, and indicative of the way the industry is shifting, but if UE4 hadn’t done its thing I still wouldn’t be considering using CE.

The major, major issue for me is what I would call solidity. Unity is a nice engine. It’s got nice things. It’s easy to learn. But christ on a bike does it have some bizarre holes and oversights. Let me count the ways.

  • Networking is half-baked.
  • PhysX and physics in general is half-baked.
  • The prefab system is half-baked.
  • Sound is half-baked.
  • Input management is half-baked.
  • Level management is half-baked[11].
  • The GUI is half-baked, and then half-baked again, in a laws-of-cooking breaking multiplicative baking process, leaving it quarter-baked[12].

All of these things and many more look great on the surface and then… just trail off once you dig a bit deeper. In so many cases, it feels like Unity threw in a cool new feature and got bored before actually finishing it. An oft-levelled criticism in the community.

And for me that’s their fundamental problem. They’ve been after the big boys, trying to get new users by chasing feature-parity. But it can’t rival UE or CE for bells and whistles. Unity may be about to start haemorrhaging their core users, because UE4 and CE3 offer professionalism and attention to detail. And, suddenly, a lower price than the engine which revolutionised indie development.

In so many cases, it feels like Unity threw in a cool new feature and got bored before actually finishing it


Here’s what I hope will happen. This move will push Unity as a company to get more focused and less scatty. They’ll realise their strength is in accessibility, and that if they double down on completing all their half-baked features, update Mono and so on, they will hopefully have a significant and loyal niche amongst those who know that the best tools for the job are the ones you can actually use, not the ones that promise AAA quality – if only you had a AAA-sized dev team. If Unity was more solid and dependable, with no major gotchas[13], I honestly wouldn’t be looking at UE4 twice.

I’d be lying if I said cost wasn’t a concern. It’s not the big one, personally – the point is UE4 is available at all, not that it’s cheaper. But the Unity subscription model can’t survive this. $75 per month per seat without all the iOS, android addons etc is a farce compared to the new competition[14].

Unity will hopefully have a loyal niche amongst those who know that the best tools for the job are the ones you can actually use, not the ones that promise AAA quality – if only you had a AAA-sized dev team

Here’s what I fear might happen. Unity could go completely the opposite way, panic, and scramble harder for feature parity. I fear that for two reasons. Firstly, it means the engine I use and like doesn’t get the care it deserves and needs. Secondly, I think it would mean that Unity won’t exist within about 5 years, and that would be a sad end for such an important company.

In conclusion – will I be switching my game to UE4? No. I like Unity, I’ve got enough work invested that it doesn’t make sense, and I think I’ve got the experience and skill to work around the holes.

But if Unity don’t take this seriously, I might well use UE4 for my next game, and I think a lot of people are pondering the same thing.


Having looked at a lot of ideas and participated in some discussions, I may as well give my thoughts on a possible solution. I have no illusions that I know what I’m talking about or that this suggestion is worth anything. Anyway.

Firstly, a lot of the ideas I’ve seen people throw around are very complex. At a time when Unity needs to really focus on who its audience is, that’s going to cause confusion and turn people off.

Secondly, the problem is that UE4 is offering loads for very little. Compare the full feature set of UE4 for effectively $19 one off (and another $19 any time you want to update to the latest version), to the limited feature set of Unity Free. $19 is pretty attractive, no?[15]

So I’d lean towards removing the distinction between Unity Free and Pro. Just have one version with all functionality, and all platforms. Make it free for users with less than, say, $10k revenue. After that, they need a subscription or flat payment similar to the existing Pro license.

  • No up-front cost means no risk for small devs and hobbyists.
  • No revenue share means no risk for large devs, or small devs who might hit it big.
  • Subscription option means small devs who manage to make $10k aren’t suddenly hit with a $4500 bill.
  • Full feature set plus Unity’s ease of use makes it very attractive compared to UE4.
  • Simplicity means people don’t have to worry about what they get, what they don’t, hidden costs etc.[16]

Additionally it would be hugely beneficial to both Unity and devs to open source code to Pro licensees. Middleware licenses may hamper this, but that’s nothing Unity can’t negotiate with their partners.


[1] You win this round, Microsoft.
[2] and these announcements have brought a lot of those bones to the foreground
[3] People who think lowering barriers to entry is bad because it lets in a flood of no-effort morons can fuck off. It does, but in reality the universe doesn’t hand out cash and opportunity to people just because they’ll be good at doing something. I’d rather give those people the opportunity, and[i] work out a good system of sifting through the resulting crap.
[4] They also announced that 4.6 will be released soonish, and will include the new GUI they’ve been promising for a while (a major issue for a long time). Plus, the Pro addon for BlackBerry is now free, which is huge[ii].
[5] In a PR sense, at least. I’m not arguing that UE4 shits all over Unity5.
[6] Off-topic, but they’ve been around for 15 years and I still can’t believe how awful the name “Crytek” is.
[8] You know what I’m talking about. No? Just me?
[9] It’s worth noting that at least with UE4, you can pay one month’s subscription and use that version of the engine in perpetuity for free (albeit still with the revenue cut). You could just pay now and then to get periodic updates if you wanted. Don’t know if the same is true of CE3. I think Epic is being incredibly smart (and bold) here – the $20 per month is a nominal fee. They’ll make shitloads on a 5% revenue share from games that do well, and games that don’t won’t lose out.
[10] It doesn’t. But it’s still a huge plus.
[11] Might be doing a post about that soon.
[12] Of these, Unity5 will hopefully sort out physics and sound, and may fix other stuff.
[13] And that’s not to mention the smorgasbord of other practically-necessary stuff which Unity relegates to third party plugins via the Asset Store. I’ve said before that one of Unity’s great strengths is the community and the Asset Store, but the flip side is that the engine relies upon that too much.
[14] Honestly, I always thought it was. $75 is a lot, and coupled with a minimum 12 month contract I never really saw many cases where it makes sense.
[15] Plus 5% revenue share, of course, but for someone looking to just jump in that’s not an issue, financially or psychologically.
[16] Again, I don’t know what I’m talking about so there’s every chance there’s stuff I’ve not accounted for here.


[i] People who don’t like the oxford comma can fuck off.
[ii] Hahahaa ha haa ha ha… ha…… Blackberry. Ahhh.

HUD Design

Heads Up Displays (HUDs) are a classic example, in games, of UI design. They have to inform the player, get out of their way, and (if you want to make a good impression) look good too. Games often have a lot of info to smush into the player’s brain[1] so it can be difficult to satisfy all these constraints.

First draft of the HUD, with added swoosh, and in the distance some DEADLY SPACE TESTING CUBES. See video below for more.

First draft of the HUD, with added swoosh, and in the distance some DEADLY SPACE TESTING CUBES. See video below for more.

Personally, I’m strongly turned off by two things when it comes to HUDs (and GUIs in general) in games. The first, I must admit, is aesthetics. But that’s not purely graphics snobbery[2] – GUIs need a “look and feel”, a set of underlying rules which tie it all together[3]. They need to look coherent, or the info they present is much harder to parse.

The second though is overly-dense information. I think a lot of players can be overwhelmed by complex GUIs which give them far more info than they need. An oft-used UI design principle is that elements should be thought of in a hierarchy, from most-frequently-used to least-frequently-used. Advanced options should not be carelessly interspersed between common ones, or people will get confused and swamped[4]. This ties into the aesthetics as well though; you can present 5 bits of info in one font with intuitive placement and have it work nicely, or you can shove them all together in one place with 5 different fonts and have it be confusing as shit.

Then, as I say, you need to present this data in a way that doesn’t obstruct the player. Filling most of the screen with an opaque health bar is clear, but you can’t play the game it’s linked to.


So here’s what I done thought. The info that the player needs during the heat of combat should be instantly accessible, so I’ve put most of it around the centre[5]. This data should also be easily absorbed – if the player can have a general awareness of their status without having to directly look at and decode numbers they can spend more attention on the fight.

Around the central reticle the player has gauges for ammo and fuel. These are important, but won’t necessarily change hugely second-to-second. What does change quickly is the primary weapon and afterburner overheat gauges, which I’ve made bigger. The idea is that the player knows roughly how their heat management is going without moving their eyes off the target.

Currently health is just a number to keep things uncluttered. I’m considering whether that should take priority over, say, fuel; but at the same time, health is clearly a very important factor and shouldn’t really be positioned with other, unrelated gauges.

A concept ripped largely from modern FPSs, the crosshair also flashes a hit indicator when you damage another ship. This gives players feedback on their accuracy and judgement of lead, hopefully without requiring a dedicated lead indicator (which I’d rather avoid). Finally, more details on your current weapons are shown on the right of screen, with a numerical ammo display for greater precision (should you need it). There’s more info to go in the HUD, but the critical stuff is in there for now.


I’ve gone for a vaguely military, holographic look. It’s minimalistic and, I think, feels functional, but it still looks nice. It was looking a bit boring before I hit upon the idea of holographic-style interlacing, but I think that gave it a necessary stylistic kick in the pants.

The HUD before the holographic style

The HUD before the holographic style

I’m sure that’s not the last change I’ll make though (apart, of course, from adding the data that isn’t there yet). I’d really like feedback on this – do people think the HUD works? Does it look good? What would you change? Leave a comment or tweet @six_ways if you have opinions and the inclination to shout them at me[6].

notes, near the ground
[1] technical terms.
[2] it is partly though. If something looks like an idiot or a 5-year-old or an idiot 5-year-old designed it, I no like. E.g. Windows XP.
[3] also, those rules must not be arse. “All my buttons should flash constantly at an epilepsy-inducing rate” would be a rule which keeps things consistent, sure, but… well, you get the point.
[4] and do stupid things and (rightfully) blame the UI for them and send you an angry tweet and find out your address and break your housemates’ legs because you’re out and they came all the way here so they’re not leaving without an aggravated assault damnit
[5] You may notice similarities of Freespace, with good reason. Given that military fighter jets are essentially where HUDs started out, lots of space sims have borrowed principles from them since forever. Other games like Half Life 2 have also used this, putting things like ammo gauges around the crosshair.
[6] Or you could tell me on youtube comments. But don’t. Because youtube comments. Gah.

Fun with Turrets

Turrets on big ships are an essential part of any self-respecting futuristic space admiral’s futuristic space navy. Fighters are great [1] for defending your capships, but they can’t be everywhere at once. So automatic turrets are a must for keeping your futuristic space paintwork free of scratches and bullet holes.

Predictably, I’m telling you this because I’ve made some.



So, you may have noticed these turrets aren’t very smart. They shoot straight at you, rather than trying to lead you. That’s intentional – they’re meant as an area-denial method rather than aiming at killing you. Well, except… ok, scratch that, they’re a stupidity-denial weapon. If you’re stupid, they’ll kill you. It’s a fast-feedback, short-generation Darwinian loop for the elimination of dumb tactics.

And if they don’t kill you, they limit your options to give your enemy a concrete home-team advantage. While you’re worrying about whether you can turn without a turret filling you with futuristic space lead, your opponent is free to fly normally and fill you with futuristic space lead. This also means you can’t just go and obliterate the enemy’s fleet in the first few seconds; it takes a while before you’ve done enough damage to slip through and hit them with the good stuff. Oh, and no spawn camping.

The turrets are also designed for the “trench run” effect[2] – it feels pretty badass to fly along a capital ship bristling with weapons, dodging streams of tracer fire. Looks good too.


Obviously, this is pretty simple for now. The turrets are maybe a bit too stupid; going near an enemy capship should probably be a bit more hazardous. The first thing I plan to add are more types of turret. There will be various classes of turret, designed for different roles. The basic minigun turret here is point defense and fighter defense. Freespace/BSG style flak guns (firing shells which explode at a set distance into a cloud of shrapnel) would provide shorter range but larger coverage defense, while missile turrets and more exotic weapons would be used against heavier ships.

[1] fictionally, at least. I can’t really see any realistic scenario in the far-flung future where fighters could serve any purpose whatsoever. But they’re fun, aren’t they.
[2] not, to my knowledge, a recognised phrase. But it should be.
[3] yes, I’ve given up on that gag really quickly.



For me, explosions are really important in games[1]. But many games don’t seem to get them right. Sometimes, instead of an earth-shattering plume of smoke and fire, you get a limp, wet flash of some vaguely flame-ish orange stuff. So I’ve been putting some serious thought and effort into designing explosion effects I’m happy with.

Elements of an Explosion


The four central parts of a good explosion in my opinion are fire, smoke, streamers and timing[2]. For a punchy, satisfying effect, I want fire that burns hot, fast, and then turns into dense dark smoke rather than disappearing without a trace. Streamers convey the feeling of something physically coming apart at high speed. Timing is what ties it all together – an explosion has to accelerate hard, then slow down and linger. That’s true of both the central effect and the streamers.

In general, I’m going for stylised rather than realistic. That doesn’t give me free reign – the specific textures and shaders need not be photorealistic, but the critical factors stay the same if I want something that feels right. An important inspiration for me is in fact the kind of explosions often seen in anime[3]; they appear out of nowhere then let you gaze at the aftermath[4].



Unfortunately, Unity doesn’t really have a shader built in which does what I need, so the first step is to write one. But that’s technical, so its at the end.

With that shader in hand, the central flame and smoke elements are covered by one particle system in Unity. Each particle starts off as flame, and quickly turns into smoke. The particles are emitted at high speed which is quickly damped. Each particle gets bigger very fast as well, then quickly levels out. The emitter acts in two bursts – a small one immediately, then a far larger one 0.15 seconds later. Another anime-inspired choice.

The streamers use the same texture and shader, again with each particle starting as flame and turning into smoke. The emitter is launched from the centre of the explosion in a random direction at high speed and decelerates sharply.

The high speed and rapid deceleration of the explosion and streamers make the effect appear very quickly, then quickly level out and linger for a fast punch and a feeling of solidity afterwards. These are accompanied by a brief flash of light and lens flare at the beginning, lasting less than half a second, to add weight.

After some experimentation, textures with bold, simple colours[5] and fairly homogenous shapes ended up working best (again bearing in mind the stylised look I’m going for). So how does it look?

Not bad. Sound, screen shake and bloom will really help sell it, and I’ll keep tweaking, but I think I’m on the right track.


To create the effect, I needed either a) two emitters combined to have flame first and smoke second, or b) just one with some kind of animation on the particles to have them transform between the two. I also knew I didn’t want additive or multiplicative blending; I needed alpha blending to give the particles opacity and implied density, and emission/self-illumination for the flame. Finally, I wanted the colours of the flame to be set programmatically according to the team colour.

Option a) would give the greatest control, but unfortunately Shuriken, Unity’s particle system, only seems to allow one material per particle system. Creating two separate emitters would be fine with additive or multiplicative blending; but alpha blending needs depth sorting to not look arse, and Unity doesn’t sort particles between separate emitters. All particles from one emitter are either behind or in front of all particles of the other.

Option b), then. The obvious answer is to use a diffuse+alpha+emissive material with an animated texture. Unity supports splitting textures up in a grid and having each particle step through the “frames” over time. However this is a lot of work for my artist[6], and needs a lot of frames to look smooth. It’s also fairly rigid and means each particle will look fairly similar.

The other problem is that Shuriken is a little limited in how it can manipulate texture colours. It has a single colour parameter, which it can change through a user-specified gradient (in RGB and alpha) over time. It passes this information as vertex colour to the shader. Strangely enough, many of Unity’s built-in shaders, including the diffuse+alpha shader, just throw away vertex colour information without doing anything with it. So straight away I have to write a new shader. And actually, Unity doesn’t have a diffuse+alpha+emissive shader at all!

Fortunately Unity’s “Surface Shader” Cg/HLSL pre-compiler directives make shaders pretty easy for simple shaders. You just specify the pre-existing bits you want to use (alpha transparency, Lambert lighting etc) then write a simple Cg function to specify how the inputs (vertex colour, pre-set colours, textures) are used.

Specifically, I use diffuse for the smoke texture, emissive for flame, and alpha for overall transparency. I want to “animate” from flame to smoke using a single vertex colour time gradient in Shuriken, so I use the RGB component to multiplicatively control the intensity (and optionally colour) of the emissive texture (with the smoke staying constant “underneath”), and the alpha is used separately to fade the entire texture out at the end of its life. I also define a regular input colour which can be set to the team colour in the code. The emissive component is therefore just texture * team colour * vertex colour[7]. This gives me exactly the control I need.

Writing my own shader also has the benefit of letting me define how I want to use texture information. Since the diffuse (smoke), emission intensity (flame) and transparency map textures are all monochrome (with the flame’s actual colour set in code), it makes sense to pack them into a single texture. The diffuse is in red, emission intensity in green and transparency in alpha. I plan to use blue as a hue-shift for the emission[8], allowing a little more variation rather than a single colour. I haven’t implemented this yet though.

As well as animating through frames, Shuriken can also just give each particle a random grid square as its texture, so I can also have a wide variety of particles with just the one material Shuriken allows.

Top left: Smoke (red channel). Top right: Flame (green channel). Bottom left: Transparency (alpha channel). Bottom right: combined weirdness.

Top left: Smoke (red channel). Top right: Flame (green channel). Bottom left: Transparency (alpha channel). Bottom right: combined weirdness.

Toes and letters
[1] Those that involve blowing things up, anyway. Explosions are significantly less important in FIFA.
[2] Other important aspects include camera shake and of course sound. I’ll cover these, particularly sound, in other posts.
[3] Even though I’ve never really got into any anime. I keep meaning to watch Ghost In The Shell though.
[4] This is common to much of the animation style in anime; punches, kicks and even people’s legs while running alternate between very fast and very slow motion.
[5] or rather, areas defined for colours, since the colours themselves are modified programmatically depending on the team colours.
[6] and since my artist is me, I bend over backwards to accommodate his wishes.
[7] in actual fact, I then multiply the whole thing by 8 to increase the intensity.
[8] so black would shift hue -180 degrees, white +180 degrees, 50% grey 0 degrees.

Gravity Assist – My Ludum Dare 28 game

Gravity Assist is a game I made for the Ludum Dare 28 competition, my first game jam. If you’re not familiar with LD48 or game jams in general, the idea is to create something in 48 hours[1]. You can play (and vote on!) the game here, in-browser or as a standalone[2].

Gravity Assist

Gravity Assist

Inspired partly by my day job (accelerator physics), you launch a “particle” angry birds style, choosing your power and trajectory to navigate between various force fields and objects. Primarily these fields are gravitational, causing the particle to curve and loop. Getting close to them scores you more points, but instant death on contact. You can instantly retry though with space, and all your previous tracks are shown to help you and make things pretty.

LD48 is a global event; in Manchester an event was hosted at the excellent MadLab in the Northern Quarter. It’s a great hackerspace, with community-organised activities ranging from game development to film-making to taxidermy[3]. It was nice to be in a space around a bunch of other people developing at the same break-neck (some might say reckless) speed. Comparing ideas, testing each others’ games and offering general advice is pretty rewarding in both directions, and it’s a great way to meet more people, and get together with those I already knew. Shout-outs to @phi6@sudorossy, @autotwitch, @clawhammermark@alexvscoding, @chrismcr@MCRGameJam, @MadLabUK and probably others I’ve forgotten…


For something made in 48 hours, I think it’s pretty good. Especially for my first attempt – I wasn’t even particularly expecting to finish anything and would have been happy just to go along and have fun. I’ve written a postmortem on the LD blog.

The concept is surprisingly fertile – I implemented a bunch of powerups/obstacles/etc and have ideas for many more. The basic elements are the attractors and the endzone. While players do not have to hit the endzone, it gives a significant points boost so gives a goal without constraining exploration. The attractors are simple but give reasonably deep gameplay just on their own[4] by allowing players to plot many courses through each level. Another core concept is fast resetting, a la Hotline Miami or Super Meat Boy (two of my favourite games in recent memory). This allows players to try loads of things out without penalty, emphasising experimentation and iteration over trying to get it perfect first time. This is also encouraged by the trails left by each try (again, somewhat like Super Meat Boy, although during play itself rather than an immensely cool replay feature) both in guiding your next attempt and looking nice. In fact, you can even shift your goal to making something pretty rather than scoring.

Other elements include repulsors (which are attractors with a minus sign and a pallette swap), speed boosters and fixed-score plates. Among the additional ideas for elements are moving/rotating objects, decelerators, things you could bounce off, switches which activate/deactivate things… it’s limitless, really. UPDATE: I’ve had some nice ideas from commenters on my LD page, including having an attractor which splits into more attractors when hit! Thanks to hate-marina for that!

Unity made it relatively easy (or indeed possible at all) to do all of this. My familiarity with the physics code helped enormously, but it was also interesting to essentially hack something together without thinking about optimisation, modularity, reusability, hierarchies and framework… just smashing code together until it worked! The graphics were a snap, again thanks to Unity (and Blender, which makes simple procedural generation stupid easy if you know anything about it).

This is the first time I’ve really concentrated on level design. The first day was largely spent on the code and graphics, and the second day largely on level design along with sound[5]. Being able to focus on content as well as code for once was nice, and gives a different perspective on things. I actually didn’t expect to be able to do so, but the code came together pretty well in the time I set for it.

Sound was created with CFXR (the OSX port of SFXR), an 8-bit procedural sound effect generator which is super mega excellent. Much lo-fi, very wow[6]. Audio was critiqued by my mate Frank, so cheers for that.
Overall, I’m really pleased with it. It’s always great to finish something, and to do so in such a short time frame and produce something which is genuinely fun, looks pretty good and has a lot of potential is delicious cake-icing.

Other People’s Games

Play these, and again, if possible, rate.
Pilot’s Last Stand – by @phi6
Titan Souls – by @autotwitch
No Choice – by @sudorossy
Destroy the Core
Bounty Hunting
The One Shot
Abandon Your City
Trip to the Moon

[1] Ludum Dare actually has two branches – the 48 hour competition where competitors must complete their work solo, and a more relaxed 72 hour jam which is more focused on groups.
[2] The competition also requires entrants to upload their source, which is nice. So feel free to grab that too! Also also, I’m very impressed with Unity for compiling the web app to a mere 586 kB, especially when the browser plugin itself is all of about 300 kB. No idea how they’ve done that…
[3] Yes, really.
[4] although the physics is a bit hacky, making it more difficult than it should be to, for instance, loop round any significant angle without hitting the centre
[5] Obviously it’s not that clear-cut!
[6] Sorry.

Engine Effects

I’m a sucker for pretty effects, and I think it’s important to have a well-defined aesthetic. I also think it’s a good idea to try something out fast and dirty first to see if it works, then polish. So I recently threw together a quick effect for the main thrusters on the interceptor. I was aiming at impressive and informational; something which implies power, looks good and also helps out players.

The result is an effect built of three components, and it looks a little something like this.
Engine effects as seen by the player.

Not bad for a first pass. So, what are the elements? Each engine has a GameObject attached behind it, and they contain a lens flare component and a trail renderer component… sort of (I’ll get to that in a minute). Additionally there’s a single point light behind the ship.

This looks nice and provides info. The flare allows players to see when others are thrusting, and the trail gives the controlling player and other players a feel for movement. Importantly though, these effects only fire while the player is thrusting. So the player also has a choice – to maneuver and become more visible, or coast and try to stay hidden.


This one’s the simplest. When the ship begins thrusting it sends an event. There’s a script which references the light, and enables it. When the ship sends an event to say it’s stopped thrusting, the light is disabled.


The flares also listen to the ship’s thrust events, and are enabled or disabled accordingly. The advantage of using a lens flare is that whenever the gameObject is occluded the flare disappears. Otherwise it’d look like the flare was a physical stream of plasma, which wouldn’t make much sense. The disadvantage is that a flare is the same size regardless of distance, which would soon fill the screen with other players’ flares. So I scale the flare’s brightness value according to its distance from the camera. By scaling the brightness, the flare appears to scale like any other physical object in the world.

The engine effect as seen from a remote perspective.


This one’s a bit more tricky. If I just used the TrailRenderer component off-the-hook, it would be attached to the engine permanently. That doesn’t work well with my desire for the trail to only fire while thrusting, but remain hanging in space. The options would be having the player emit a trail all the time, or turn off the entire trail as soon as thrusting ends. Which would look terrible, obviously.

So in fact I have a prefab with a TrailRenderer component. This prefab is instantiated and parented to the engine object when thrusting starts, and then un-parented when thrusting ends. Thus the trail continues to exist but is no longer emitting new segments. TrailRenderers already have a “lifetime” property (rather than having a fixed length) so after an appropriate time the trail fades out smoothly along its length. When the trail is gone, I destroy the gameobject. Job done.


It’s not perfect. The flares are a little too big, and a little too diffuse, from a distance. I’d rather have something which literally scales, rather than decreasing in brightness. The engines on the interceptor model could do with more than just a featureless black hole; it’d be nice to have them burn brightly while thrusting, and smoulder dimly while not.

Tagged , , , ,

Get every new post delivered to your Inbox.