It was going to be complicated, and I knew that once it was done, I didn't want to ever have to deal with its intricate inner workings again. So it needed to be able to handle any particle type I could feasibly throw at it between now and Spryke's completion: dust, rain, leaves, snow, Matrix-like cyberdelic effects...

Particles had to be able to float gracefully, flutter unpredictably, or vibrate frenetically. Some must twirl in circles while others must create splashes on platforms. They had to be able to dynamically move if caught by the wind, Spryke whooshing past them, or a nearby explosion.

What's more, they must figure out a lot of stuff on their own. If they are twirling objects, they should twirl more often if there's a brisk wind. If they get knocked about by Spryke, they should seamlessly resume their original motion after a while. They must contribute visual depth to the game by spawning at various distances to the player, with those in the background being smaller, blurrier, fainter and more numerous. They need randomised variety in their movements - those which spin or move quickly must be redrawn more frequently, while those that are small, slow and/or distant should be recalculated only rarely, to optimise CPU performance.

I need to be able to control how and if their colors get randomised, so I can create just green leaves in Photoshop but still get brown, yellow, orange, and red ones for an autumn effect in-game. And if a level has a dark cave on one side and a bright light source on the other, I want a way for the particles' color and opacity to adjust accordingly. Finally, with so many parameters available to me, I needed to be able to tweak them rapidly and without confusion. 

​So the list of features I wanted was substantial, and I decided on an approach I hadn't fully utilised before: planning out the entire engine on paper first. For the most part, this worked excellently. While I filled up close to an entire notebook of diagrams and equations, I discovered and fixed many issues while still at the paper stage, and some 80% of the features I planned worked immediately as intended when I coded them into Fusion.  I still see myself as essentially a non-programmer, so that was a delight to experience. 

​The final result is probably even better than I'd hoped. It does all the above-mentioned features and more, and the particles look really nice, to my eye. It won't be long before the engine's 200+ variables and numerous equations become totally opaque to me, but that shouldn't matter because the 'front end' that I'll be using is very straightforward. I just need to enter some simple parameters in an INI file, hit a single key on my macro keyboard, and see the changes reflected immediately in-game. I configured most of the effects in the GIF at the top in a matter of minutes.

When I dived into the deep end of game development almost 5 years ago, many people expressed admiration, and even sometimes good-natured envy, for the courage it took to follow my dream. Though as each year passes, they're probably more and more glad that it was me who took the plunge and not them! 

There's an insanity to Vincent's approach, but also an incredible freedom. The reason Vincent succeeds despite the odds being stacked against him is not because of anything that he does, but because of all the things that he doesn't do. Unlike Anton, he doesn't look over his shoulder; he doesn't continually update a mental map of his distance traveled in the back of his mind; he doesn't keep freaking himself out by wondering whether he's going to make it or not. He's free to focus on just one thing - going forward - and doesn't have to waste resources on anything else. Vincent's approach is brave, and reckless, but it's also incredibly efficient. 

Had I not dived in the deep end with this game, I would have quit ten times already: when the going got tough; when I got tired; when other opportunities caught my eye. Or, I would have seen the game through, but to a mediocre standard, chalking it up as a mere learning experience or relegating it to a weekend hobbyist project while I worked a day job. Thousands of other indie games have ended up exactly like that - unfinished, shelved, simplified or downgraded. At the very least, my advantage is that I'm still here, and still plugging away, albeit sometimes slower than I'd wish. 

So yes, here I am. Spryke's still alive, and she's doing great. The game's going to be finished - eventually - and it's going to have an insane amount of love and care put into it, so that it can leave lifelong memories for as many players as possible. But you won't see it at PAX this year, and you probably won't hear from me much at all, until it's closer to completion, because until then I need to focus. Hopefully you'll thank me when you get to play the finished product. But know that Spryke and I are still here, still swimming....

You can get volPROFILER on the Clickstore here ($2.99). For more info and/or discussion about volPROFILER, see its forum thread here. To get just the Microtimer object on its own, go here (free).

​If you're not familiar with the word "scope" in the context of Clickteam Fusion, don't worry - you're almost certainly familiar with the concept. One of the great things about Fusion is that it frequently scopes things automatically, in a way that is intuitive to the user....most of the time. 

The basics of scoping in Fusion are very simple and easy to grasp. But as will soon become apparent, it becomes pretty byzantine the deeper you dig, with all sorts of unintuitive rules and weird exceptions that will sooner or later generate frustrating bugs in your projects, unless you familiarise yourself with their hidden idiosyncracies. But fear not. At the end of this post, I summarise it all into some simple guidelines. 

OK, let's dive in. In this first example, the simple action set angle of pear to 45 results in all pears being tilted. Naturally.

However, in the next example, the exact same action has only managed to rotate two pears. That's because the preceding condition (Y position of pear > 100) has scoped those two pears. ​In other words, Fusion has singled out those pears which have a Y value greater than 100px (ie. are visually lower down, and closer to the bottom of the screen, than y100). Thus, the subsequent action, because it takes place in the same event, now only concerns itself with those pears. I'm probably not telling you anything new here.

​In the next example, notice that this scoping is cumulative. Both conditions have combined to scope just one pear (the only pear that happens to be both lower than 100px on the Y axis and further right than 100px on the X axis). And both actions have honoured that scope (only the scoped pear was tilted, and only the scoped pear was alpha-faded).

S​o far so good, right? In most situations, scoping is as straight-forward as this. However, there are certain situations where Fusion's idiosyncrasies can make scoping less intuitive. One case is when two objects are compared. Look at the following two examples:

Mathematically, both above events appear to be identical. In each case we're talking about pears which are lower than apples. Yet only the pears in the first example were successfully scoped (the second example applied the tilting indiscriminately to all pears).

​This is because when you compare two objects in a condition, Fusion generally only scopes the leftmost object. If this seems weird, then it may help to remember that a condition in Fusion is essentially an IF statement.

​Let's replace the apple with the number 100 again, and look at these two events again:

The first statement, essentially, reads as follows: 
If the Y position of a pear is greater than 100, then rotate the pear. 

The second statement reads: 
If 100 is less than the Y position of a pear, then rotate the pear. 

While that second statement isn't exactly broken, it's kind of....odd, right? The focus of the sentence seems now to be the number 100, so it doesn't feel entirely right to assume that we're talking about any specific pears. It's a bit like, instead of saying.....

Fred went to the the third drawer, and got himself a spoon

.....I instead said.....
 
The drawer was the third from the top, and Fred got himself a spoon

There's something a bit off about the second statement, right? You can still infer that Fred's spoon came from the same drawer that was the third from the top, but it's not 100% clear. And since computers have a much lower tolerance for ambiguity than humans do, you can imagine that a computer would struggle to make that inference.

Hopefully this will help you get an intuitive sense of why Fusion only scopes objects from the left. Regardless, as long as you remain aware of this idiosyncrasy, it's not likely to cause you many problems.

There are some exceptions to the 'scope on the left' rule. One such exception occurs, thankfully, when we test for overlap.

As the following example shows, when you test for overlapping between two objects, both objects are scoped, regardless whether they're on the left or right. Just as well - testing for overlaps would be near-pointless if it didn't result in both specific objects being scoped! The same is true when testing for collision, by the way. 

​Creating new objects also affects scoping. When a new object is created, all subsequent actions in that event will be scoped to the newly created object(s).

Notice in the next example how only the 2 newly created pears are tilted and faded, while the original 5 pears are untouched.

Now notice below how the same event - but with the actions reordered - achieves a very different result. Because the fading and tilting actions appear at the beginning, before anything is scoped, they apply to all pears. So all 5 original pears are modified. The 2 new ones are not modified because they only get created after the fading and tilting actions have taken place:

Hmmm. Shouldn't one of those new pears (the one that was created earlier, at x50 y100) now be faded? Perhaps the second newly created pear is stuffing things up somehow? Let's remove it:

 
​Nope. We get essentially the same result. Both the fading and the tilting get applied to all previously existing pears, and not to the new pear (even though the fading is supposedly applied after it's created).

Perhaps newly created objects only affect scope when they are the topmost action? Let's try something:

Nope. In the above example (exactly the same as the preceding one, except that the tilting action is applied to apples instead of pears) the create new pear action does indeed affect scope. Only the newly created pear is faded. This all seems pretty inconsistent and weird. Who knows how exactly it works under the hood? But I can start to cobble together a hypothesis:

Perhaps, the first time an object is encountered in an action, its scoping is cemented for the rest of the event (including any scoping inherited from conditions, naturally). 

The above hypothesis appears to agree with everything we've seen so far. It explains that when a pear is first encountered in Example newlyCreated #5 it cements the scope to that 1 pear (only that pear is faded).

​And it explains that since the first pear action encountered in Example newlyCreated #4  applies to all 5 pre-existing pears, the scoping is cemented to those 5 pears (which is why fading is applied later to those 5, but not to the 6th that was created a moment after the scoping took place).

It also explains the next example. Because the first action applies to the 5 pre-existing pears, the third action does too. Thus, the newly created pear is neither destroyed nor faded. So far this hypothesis is looking good.

However, before I get too excited, I need to come clean and admit that, if you hadn't noticed already, the hypothesis doesn't actually fit with #1 newlycreated, where not 1 but 2 actions affect scope (both created pears are successfully faded and tilted).

My hypothesis also doesn't explain this:

​The above example is identical to the previous one, but for the extra condition (Y position of pear >100). Yet while the newly created pear was spared in the previous example, it's destroyed in this one. Why? The first action here is clearly honouring the scope from the condition, since it destroys those pears which are lower than y=100 while leaving the top 3 intact.

So why does it also destroy the newly created pear? The newly created pear was neither part of the original scope (it didn't even yet exist when the scope was determined), nor does it qualify for that scope once it's created (since its Y position is less than 100).

Sadly, the best conclusion that I'm able to muster is that Clickteam Fusion is kind of like the English language: dazzling in its overall utilitarian simplicity, yet knotted with arcane rules below the surface that present seemingly even more exceptions than there are rules. People might think they know exactly how it works, but no fully does. Yet somehow we all get by anyway.

To try and summarise this section then: Creating objects at the beginning of an event automatically scopes those objects. This is highly useful. There may also be times when you want to create an object lower down in the action list - but do so at your peril, as it may produce unforseen consequences. 

Scoping can also be unintuitive when fastloops are involved. In the next example, the insertion of the fastloop has broken the scoping of the pears, resulting in all the pears being rotated, rather than just the ones that are Y>100. 

​In a way, this makes sense, since the fastloop is wedged between the pear condition and the pear action. It shoots us out of event #1 and into event #2, thereby disrupting the hermetic nature of the event. We can perhaps forgive it for forgetting event #1's initial scoping once it eventually returns from the fastloop in #2.

So what happens when we move the Start loop "fade apple" 1 times to the end of the action list? 

​Well, nothing. It's no longer wedged in between the pear condition and the pear action, and there doesn't seem to be any intuitive reason why the fastloop should continue to break the pear's scope. Yet it does. It would seem that the mere presence of a fastloop call anywhere in event #1 breaks the scoping of the pears. They are all tilted, rather than just the Y>100 ones. ​

It gets weirder though.

This time, look what happens if we modify the  fastloop to include a pear in it:

​The fastloop successfully fades all the pears, but when it comes back to event #1, not only does it still not honour the Y>100 condition, but now it brings with it its own seemingly senseless scoping that no one asked for (the lower-right pear). In my view, this behaviour is no longer just a quirk but a definite flaw.

You might wonder what, if anything, was so special about that lower-right pear that gave it priveleged scoped status. The answer is that it happened to be the last pear that I created (in the frame editor). So at least it's a predictable flaw. But it does hint at some potentially useful functionality. Observe the next example:​

​As before, the fastloop causes Fusion to dishonour the Y>100 scoping. And as before, the fastloop imprints its own scoping on the event. But this time, that scoping has a somewhat satisfying logic to it: we specially created two pears in our fastloop, and upon returning to event #1, it is precisely those two pears that are scoped. I can imagine some good uses for that.

But don't get too excited...

​​This time, all we've done is add some extra actions to the fastloop, and suddenly our two newly created pears are no longer scoped. We are back to just the most recently created pear being scoped. I don't know about you, but this sort of behaviour seems far too flaky and unpredictable for me to ever rely on it. My advice is to exercise caution and avoid mixing fastloops and scoping. If in doubt, call the fastloop in a separate event.

ForEach loops have their own scoping idiosyncrasies that are often different from those of fastloops. For one thing, a forEach loop's mere presence doesn't break scope (or at least, not in the same way that a fastloop's does).

​Below is a recreation of Example fastloops #1 from above, but using a forEach loop instead of a fastloop. Notice how the apple forEach loop doesn't interfere with the successful pear scoping. 

​​Furthermore, watch what happens when we call a forEach loop on pears instead of apples, below. The scoping from event #1 is actually remembered in event #2 (only the Y>100 pears are faded)! This gives you the ability to call a forEach loop on only a specific subset of objects, which is useful in various situations (eg. run a forEach loop that makes enemies shoot at the player...but only those which are close to the player).

​Just to be clear, this is an ability that is unique to forEach loops. The exact same scenario using a fastloop causes scoping to be broken (all pears are faded, plus only the most recently created one is tilted):

​So far, forEach loops seem like the good guys. Their mere presence doesn't seem to break scoping, and they obediently inherit scoping from their parent conditions. And of course, scoping is one of the main purposes of a forEach loop in the first place, as the very name "for each" implies: the forEach loop iterates through each instance of an object, one at a time, scoping each in turn as it progresses. Each time, all actions inside the forEach loop will be performed in the context of one specific, scoped object.

But alas, forEach loops also carry their own set of weird scoping problems.

In the next example, we create two new pears next to the apples. Then, we ask for the pears to be tilted. Intuitively, we might expect one of two scenarios: (a) that scoping will carry over from the forEach loop and only the 2 new pears will be tilted, or (b) that it won't, and all 7 pears will be tilted. We probably wouldn't expect the actual outcome, where all but the new pears were tilted. Strangely, event #1 behaves as if the order of its actions were reversed.

​Incidentally, replacing the forEach loops with a fastloop, in an otherwise identical scenario, produces the exact opposite result. Now, only the new pears are tilted. 

​While a fastloop that returns to its parent event can bring with it new scoping, a forEach loop seems to arrive late for the party; it's as if any new objects it created don't quite make it back to the parent event. This can be seen explicitly in the next example:

In the above example, we start off with 5 pears (created in the Frame Editor). We then shoot off via a forEach loop to create 5 more. When that's done, we come back, and ask Fusion to tell us how many pears there are in total. Fusion declares confidently that there are 5, when we can see with our own eyes that there are 10. 

We already know by now that creating new objects can do some wacky things to scoping. So let's see what happens if we try a similar scenario to the one above, but without the create new object bit:

​Even now we have the same problem. The number 1 was added to Global Value A 5 times (since there are 5 pears, our forEach loop looped 5 times). Yet somehow, when we display this value afterwards, it is as if time has rewinded, and it's still 0.

Could it be that forEach loops are simply executed last, after all other actions? Even though the forEach loop appears to be the topmost action, is it secretly being bumped down in the queue? Upon further scrutiny, it appears that this may be what is happening. Have a look at this:

The fact that the pears in the example above end up tilted proves that the forEach loop did indeed run. Yet it was only allowed to run if at least one of the pears was ripe (ie. we changed its alterable value "ripe" from 0 to 1). But the pears only became ripe after the forEach loop had finished! 

There are only two possible explanations for this that I can see. Either forEach loops have discovered the secret of time travel, or they are always executed last, no matter where they appear in the action list. The former explanation is the more compelling one. But we must keep an open mind and at least consider the possibility that Fusion routinely delays forEach loops until all other actions are completed. 

Here's another example. Notice that we create a pear at the precise location of the apple. Yet when all is said and done, the pear ends up nowhere near the apple. That's because we moved the apple (but before the pear was supposed to have been created). Again, it seems as if Fusion has, without telling us, shuffled the forEach loop to the bottom of the action queue. 

However, things are not this clear-cut (which by now probably shouldn't be surprising). This next example proves that although forEach loops often seem to be executed last, they aren't always executed last:

Had the forEach loop run in the above example, the application would have immediately ended. But as you can see, the application is alive and well. We can deduce from this that the order of events played out exactly as we would expect from looking at the events (for once).

First, Fusion ran a loop for each pear - but since there were no pears yet, it ran the forEach loop zero times, so it never had to see the end the application action. We can assume that only afterwards was a pear created (since the existence of a pear should have caused the forEach loop to execute). In this case at least, the forEach loop seems to have executed at the start of the action list, not at the end. 

These last few examples weren't technically about scoping, but I think these idiosyncrasies are useful to know about, since they can, and do, affect scoping in certain circumstances (as we saw in Example forEach #4, for instance).

OK, so we've investigated the different ways in which Fusion automatically scopes objects (or doesn't). If you pay attention to the basic principles and steer away from the problem areas we identified, you'll find Fusion's automatic scoping to be both useful and easy to work with.

But there will still be times when Fusion won't automatically do the scoping that you need, and will require a helping hand from you. This will be the case when you need scoping to persist over multiple events (Fusion's autoscoping  is predominantly limited to singular events).

Below, we have 4 pears. On top of each pear, we've also placed a worm:

Now, let's say that we want to rotate those pears whenever we press spacebar; we'll do it via a forEach loop. When we rotate the pears, the worms are left behind:

​We can tell Fusion to rotate the worms the same amount as the pears, but that won't work properly. Each time we tell Fusion to rotate a pear, it does them one by one, because of the forEach loop. But when we tell it to rotate a worm, we haven't specified which worm we're talking about (ie. we haven't scoped the worms), so it rotates all of them. As a result, the worms are all rotated together, 4 times, and they end up facing the same way:

​
So we need a way to tell Fusion which worm we're talking about. In particular, we need some way to 'marry' each pear/worm pair. There are a number of ways to do this, though they all work on the same principle. Some people use spread values, for instance. My preferred method is to used fixed values, like so: 

​A fixed value is a unique number that Fusion automatically assigns to every object in the scene. It typically looks something like this: 374928. But the beauty of this method is that you don't need to actually know , or care, what the fixed value is. The point is that every object in your game already has its own unique little identification number, without you needing to do anything, which makes these fixed values perfect for manual scoping. OK, let's break down this example step by step:

EVENT 1: We launch a forEach loop for the pears. This will only run once (at start of frame). 

EVENT 2: This is the forEach loop. In the first action, we create a worm at the pear. Fusion knows exactly which pear we're talking about, because the forEach loop is carefully going through each pear one by one, scoping an individual pear each time. At this point, we are in a unique position: Fusion has scoped a single instance of a pear (because of the forEach loop) and also a single instance of a worm (the one that was just created). But not just any pear and worm, of course: this pear and worm are located at the same physical X+Y location.

So while Fusion has both these objects scoped, we must take advantage of the situation and quickly find a way to slap some sort of permanent label on our duo, forever 'marrying' this particular worm with this particular pear. We do this in the second action, by assigning an alterable value (that I've chosen to call "ID") to the worm, and giving it the same value as the fixed value of the pear.

​As discussed earlier, each object has a totally unique fixed value that can be used to tell it apart from all other objects. So by copying the pear's fixed value to the worm's "ID" (alterable value), we've effectively formed a link between them that we'll be able to use at any time in the future to locate the happy couple. 

EVENT 4: Whenever spacebar is pressed, launch another forEach loop that will rotate the pears.

EVENT 5: The first condition (the forEach loop one) scopes the pear. Fusion now has one single pear in mind. The second condition scopes the worm, because it forces Fusion to find only the worm that has an "ID" (alterable value) that exactly matches the fixed value of a pear (which pear? the pear that was scoped in the preceding condition, of course!)

By the time we get to the actions, Fusion has successfully scoped one pear/worm couple. So when we ask Fusion to rotate the pear, it rotates just one. Then when we ask it to rotate a worm by the same amount, it knows to only rotate the worm that's 'married' to the pear. 

This technique doesn't just apply to pairs (nor just to pears, har har). It can be used to combine and scope any number of items. Here, we add a cowboy hat to the mix:

Well, if you got through all of the above, then you know that Fusion's autoscoping can become one crazy rabbit hole. But that doesn't mean scoping needs to be intimidating or confusing. By simply remembering a few basic points, you'll be able to steer clear of 99% of Fusion autoscoping's weirdness, and reap the benefits of its intuitive, pleasant side. Here are the key points to be mindful of (as I see them, at least):

1. Scoping is usually done for the leftmost object in a condition
2. Testing for overlaps/collisions scopes both objects
3. Compare two general values never scopes anything
4. Fastloops will usually break an event's scoping. If in doubt, place fastloops in a separate event.
5. ForEach loops inherit scoping from their parent conditions. Make use of this to call more narrowly defined forEach loops.
6. Try to create new objects at the top of your action list (otherwise you may get scoping oddities)
7. Try to place forEach loops at the bottom of your action list to prevent weird surprises (since Fusion usually appears to shift them there at runtime)

This is the first such Clickteam Fusion article that I've posted, and I've no idea how many people will read it, and whether they'll find it useful. So please let me know what you thought. Tell me what you liked, and what you didn't like, either in the comments below, or at the Clickteam Fusion forums.

Stay tuned for the larger article that this post was originally meant to belong to. To be notified when new posts arrive, sign up to my newsletter. 

Spryke launched on kickstarter earlier this week. It's going well, though there's a long way to go,  so please support us!

To get you up to speed, Spryke is a quirky, colorful, and deeply crafted platformer that I've been developing for almost 3 years, along with a team of highly talented and dedicated people. 

We're aiming to make Spryke nothing short of one of the remarkable platformers of this generation. It's a lofty ambition, but we're serious about it. Here's a peek at some of the love that's going into this game:

​If you'd like to help us make our vision for this game become a reality, please back our kickstarter campaign. We have some pretty cool rewards on offer! Oh, and please tell your friends about Spryke! :)

​VACCiNE is a handy bit of Fusion code that makes pretty much every gamepad under the sun work out-of-the-box and flawlessly with your Fusion PC game. It greatly simplifies the work required for your game to have robust gamepad and keyboard controls. It also provides a sophisticated in-game debugging panel that you can fill with useful info, to help you monitor the nuts and bolts of your game. VACCiNE does all this with regular, well-commented Fusion code, and regular Fusion Active Objects, meaning that you can easily enable/disable/customise/expand any part of it to suit your own project. It's designed to be as simple as possible, though an intermediate level of familiarity with Fusion is recommended.

For a more in-depth overview of what VACCiNE does and how it works, please visit the forum page, read the comments inside the MFA file itself, and/or watch the video below.

You can download VACCiNE towards the bottom of the Downloads page

Clickteam Fusion is the engine I use to make Spryke. It's a syntax-free yet very powerful engine, which makes it perfect for someone like me who's more artist than programmer. Its interface contains some unnecessary friction points though. So I did my best to improve the user experience by making a skin that's designed to maximise productivity (as much as is possible in a skin)

I've called the skin Productiva, and it's designed to minimise clutter, keep the eye focused on important areas, and add a better sense of clarity and hierarchy to your workflow. 

I've actually been using a version of this skin for almost a year, occasionally iterating and improving it throughout that period. I felt it was time to finish it up and put the final adjustments on it. It's now as good as I can make it, so I feel it's ready to publish. If you're a Clickteam Fusion user, you can buy it for 2 bucks at the Clickstore.

Below is a comparison between Productiva and the default skin, outlining some of the areas I addressed (click it to enlarge)

So we spent the weekend exhibiting Spryke at Avcon (a large gaming and Anime conference in Adelaide). It was great!

​It was the first time Spryke was shown to the public, and the reaction was overwhelmingly positive. Comments like "it's so polished!", "the controls are just perfect" and "I thought the difficulty would frustrate me but I just kept going back for more!" kept coming.

​We got some critical feedback and suggestions for improvements too, which is obviously very important. But the majority of feedback we got was positive, which felt wonderful. Seeing people who played the demo earlier drag their friends to our stall saying "you HAVE to play Spryke!" is a great feeling, and makes you know that your game is on the right track.

​Anyway, now that Avcon is over, it's time to officially announce the Spryke demo! Go and grab it!

2015 was a big year for Spryke. 2016 will be even bigger. 

2015 saw Spryke go from a blocky prototype full of placeholders to something starting to resemble a game. I began giving the world a look and feel, with some detailed graphics, an in-world alphabet, and procedural background animation systems.

Spryke herself took shape, after countless iterations. Several test levels were designed and built, and the game got an official logo. The backstory and narrative got some love and care too, though that part is still marinating. 

Perhaps most importantly, Spryke received a substantial funding grant from Film Victoria, a government Arts agency in Australia. Emotionally, this was great validation for me. It's one thing to passionately believe in your own project, but it's another to see that others believe in it too. The grant will give Volnaiskra extra stability in the coming year, and will ensure that I can enlist the help of extra developers and/or whoever else I might need to help make the game as good as it can be. 

That was just the beginning though, and 2016 is where everything really will come together. Right now, I'm concentrating on character animation and gamefeel. Spryke had only the most rudimentary of animation until now, but she'll get a total overhaul now. You can expect something approaching the level of the Rayman games.

Over the coming months, you can also expect to see some interesting and unique new locales take shape too, alongside the futuristic city that you see in the current screenshots. Plus new enemies, mechanics, effects, and plenty of new levels. Maybe even another alien alphabet or two.

I have a top-notch composer lined up, and Spryke will get a full outfit of original music this year too. 

In general, I hope you'll be able to learn much more about Spryke over the coming months than you've been able to so far. The last post on the Volblog was over half a year ago, and it wasn't even about Spryke. That's just not good enough. 

There's actually a lot of stuff that's already in the game but that I haven't yet shared with the public because I've been so busy developing. But I'll endeavour to keep you guys more informed this year, so look for some posts revealing some of Spryke's mechanics, story, as well as some behind-the-scenes stuff that you might find interesting. 

I'll also need to expand my pool of user testers soon, so look out for a playable demo early(ish) this year too!

To access Layer Styles, double-click a layer in photoshop. From there, you can tweak various settings to alter the appearance of the layer. Layers that contain Layer Styles have an "fx" icon on them. If you make a Layer Style that you think you'll reuse, you can save it in the "Styles" palette. 

Below is one of the above layers shown with all of its Layer Style attributes. Not every Layer Style needs to be this complex of course, but by stacking multiple attributes like this, you can achieve a great deal of variety and visual subtlety.

This particular Layer Style is used for lights and other illuminated objects. It has a round inner glow (from Gradient Overlay), intense coloring (Color Overlay and Satin, both using Overlay Blend Mode),  noise (Inner Glow),  and a somewhat intense reddish glow (Stroke, Outer Glow, Drop Shadow).

This next Layer Style provides a worn diamond metal plate look. The foundation of the Layer Style is the Pattern Overlay, which provides the diamond plate texture. The colour is first neutralised somewhat (Color Overlay), then intensified (Satin with Overlay Blend Mode). Finally, a subtle degraded appearance is added by a rust-coloured Inner Shadow.

There are three main benefits, all of which intertwine:

Non-destructiveness

I'm a firm believer in keeping your workflow as non-destructive as possible. The secret of great design is iteration, and keeping everything editable rather than locked down makes iteration much easier. Thanks to Layer Styles, I can tweak, overhaul, swap or remove the appearance of just about any visual element at any stage.


Quickness

Certain things are just way quicker using Layer Styles than with most other methods. Some examples include: filling with a solid color, creating an outline, adding some noise, creating a glow effect, or filling an effect with a pre-existing texture or image (using Pattern Overlay). 


Re-usability

Layer Styles can be copied and pasted from one layer to another, and saved in the Styles palette. This is of particular use to game artists, since we tend to make a large amount of assets, many of which share similar stylistic traits. 

When you combine all of these benefits, you get a workflow that is efficient, highly organic, and can grow and evolve with your project. As you work, you can build up a library of Layer Styles that you apply to subsequent assets, tweaking and experimenting when necessary. As your project's aesthetic evolves, you can retrofit earlier assets with updated stylings.

 

A few. For one, they aren't a silver bullet (but then, with the possible exception of actual silver bullets, what is?). As you'll see below they can do a lot, but they can't do everything. Sometimes you'll still need to use other techniques (painting, photography, filters, etc.) in conjunction with Layer Styles.

They also have a few rigid idiosyncracies. For example, the number, type, and order of attributes are fixed (eg. you can only have one Pattern Overlay, and it always must be below any Color Overlay). And certain behaviours (eg. Stroke combined with translucency) are just plain weird. 

But with a little ingenuity these problems can, for the most part, be solved or worked around. More on that later.

Probably the most serious drawback of Layer Styles is performance. If you're using just a handful of Layer Styles then no problem, but if you use hundreds like I do, Photoshop can start to get laggy, no matter how good your computer is (mine's a beast) - especially if you're using lots of different blending modes inside them. This isn't really the fault of Layer Styles per se; the performance hit comes from using loads of layers and blending modes in general. 

The solution here is to be smart about how you work. Group separate elements in your composition into folders (Layer Groups) and turn them off when necessary. Or, better yet, turn them into Smart Objects. This removes their resource footprint from the current document by displaying a flattened, rasterized version (which you can double-click to access the original editable layers). In the image at the top of this post, every ship and every building is a separate smart object (some of them duplicated).

As your project grows, it's a good idea to start saving your Layer Styles in one place, to make re-use easier. You can use the Styles palette for this (that's exactly what it's for) but I prefer to lay them all out in a separate PSD, as you can see below. This lets me lay them out in more organised way, with labels and compartmentalised groups. 

Also, the Styles palette is comprised of squares, while the PSD method allows me to use custom shapes that will better represent the potential of each Layer Style. As you can see below, I use two shapes per Layer Style; together, they show me what a layer style looks like on a large layer, a tiny layer, a round edge, straight edge, corner, and hole. 

Here you can see a step-by-step process of how I applied layer styles to one of Spryke's elements - a "Weasel" ship. The majority of layers are Vector Shapes (shown initially as wireframe). I add a few small raster elements in the last step.

As you add Layer Styles to differently shaped objects, you may need to tweak them a little. For example, the angle of the red gradient on the wing needed to be rotated when applied to the tail. Similarly, the size of the glow of a large light might need to be taken down a notch when applied to a small one. Thankfully, the non-destructiveness of Layer Styles make this kind of fine-tuning pretty easy.

Also, take note that in some cases, I couldn't achieve everything I wanted in one Layer Style, so I had to duplicate a layer and use more than one set of Layer Styles. This mainly occurred in the context of Pattern Overlays, the only way to import a raster image into Layer Styles. Photoshop only permits one Pattern Overlay per layer style, but I wanted three - a dirty texture, black scratches, and white scratches - so I had to use three identical layers, each with its own Layer Style. (I could have combined all three textures into one pattern, but that would have given me less flexibility.)

And here's one of Spryke's buildings. Again, practically every element is a Vector Shape with Layer Styles applied to it. (A few more Layer Styles were used than what is shown, but this is the bulk of them).

Because they're so tweakable and non-destructive, Layer Styles are excellent for creating variations of your assets, and even for early experimentation and brainstorming.

So far, I've concentrated on Layer Styles used on their own (ie. setting Fill Opacity to 0% so that none of the original layer contents can be seen). But Layer Styles can also be used as a quick and easy way of adjusting a layer's existing contents, as you would with an Adjustment Layer.

Let's say you want to desaturate a layer. You could do Image>Adjustments>Desaturate (Ctrl-Shift-U), which is very quick but also destructive (you can't change your mind and revert to color later). 

You could also use a Hue/Saturation or Black&White adjustment layer. This is non-destructive (and in the case of Black&White, very nuanced), but it's also a little clunky: it creates a separate layer, and by default it'll desaturate all layers underneath it, not just your target layer. 

A third option is to use a simple Layer Style: Color Overlay, black (or white, or grey), 100% Opacity, Saturation Blend Mode. This is relatively quick, non-destructive, and has a light footprint in your Layers palette. And of course, you can save the Layer Style so you can copy/paste it to other layers later. 

Below are a few examples of possible adjustment types, including desaturation, contrast, colorize, noise, and brightness. Note that in the centremost version, I've used Satin to change the color of the circular metal area without affecting the rest of the creature (more or less).

One of the benefits of this approach is that you can stack multiple effects using Pseudo Color Overlays (see next section) all within just one Layer Style, which helps keep your document compact.

In the next section,  I'll go through each of the attributes with tips and tricks for each. But first I want to bring attention to what I've dubbed Pseudo Color Overlays. 

Color Overlay allows us to apply a colour to the entire layer, which makes it highly useful. Ostensibly, it's the only Layer Style attribute that does so. However, with the correct settings, a number of the other attributes can be made to function in essentially the same way. Here is a list of Pseudo Color Overlays, in order of quickest to most convoluted:

• Inner Shadow: 30000px Distance, 0% Choke
• Satin: 1px Distance, 250px Size
• Inner Glow: 100% Choke, 0px Size, Source: Center
• Gradient Overlay: Set up a gradient with identical colour on both ends of spectrum
• Pattern Overlay: Create custom pattern that is just a single colour, and use that
  
  

Why is this useful? Because it allows you to apply several entire-layer adjustments to a layer in one go. I'll illustrate this with an example.  

Let's imagine that we have a shiny blue spaceship that we'd like to make look a bit more aggressive: red, more starkly contrasted, and a little rougher-looking. Also, we want to do this non-destructively. 

We'll need to change the ship's color, add texture, and fine tune the brightness/contrast. With the Adjustment Layer method, this would require several new layers. But with Pseudo Color Overlays we can do it all on the original layer, a more compact and more portable solution. 

OK, here's our initial blue ship:

First, we use a Pseudo Color Overlay (Gradient Overlay in this case) to change the hue of the entire layer from red to blue:

That's a good start, but it feels too monochrome and maybe a bit too plasticky. Let's add a second color into the mix for nuance, using the 'real' Color Overlay this time. 

That's more interesting, though the addition of cyan tinges has messed up our reds (and whites) a bit. Let's counteract that by applying another reddish colour over the whole layer with another Pseudo Color Overlay (Satin, using the settings listed earlier). We'll use an Overlay blend mode again to boost the contrast:

OK, the colour looks good. Finally, let's add a little bit of noise to the whole thing for a bit of a rougher texture, using Inner Glow.

OK, there we have it. The method was perhaps a little quick and dirty, but the results are satisfactory. Our ship is redder, rougher, and has a sharper contrast. And, thanks to Pseudo Color Overlays, the whole thing was achieved with just one Layer Style which can easily be disabled, modified, or copied/pasted at any time.

OK, I'll now provide a few tips, tricks, and potential pitfalls of each Layer Style attribute. I won't explain the basics about each attribute, because you can find those out yourself with a few minutes of experimentation, if you don't know them already.

Bevel & Emboss

• Can be useful as a cheap method to create some depth, but proceed with caution. Along with filters such as Filter>Stylize>Find Edges, nothing says "it's my first time using Photoshop!" like heavy handed use of the Bevel & Emboss Layer Style. 
  
• Using Outer Bevel and Smooth, it can be used as a substitute for Drop Shadow
• Using Inner Bevel, Chisel Soft, Depth 1000%, Soften 0, Angle 0, Altitude 0, Shadow Mode Normal, it approximates an inside Stroke, but without the translucency bug (see below)
• The Texture section allows you to import a monochrome version of any raster image as a highly configurable sort of bump map
• The Link with Layer checkbox in the Texture section refers to whether or not the texture will change when you move the layer around the canvas

Stroke

• Stay away from blend modes other than Normal 100%, because of the translucency bug (I don't know if this is a bug or a feature, but it's damn annoying so I'm calling it a bug): Applying a Stroke negates all other Layer Style attributes for the affected pixels. For example, if you apply a red Color Overlay and then a blue 6px Inside Stroke, and turn down the stroke's opacity to 50%, instead of seeing a 6px band of purple surrounding the shape, you'll just see a faint blue band, because the red Color Overlay in that 6px band has vanished. See Bevel & Emboss, Inner Shadow and Drop Shadow for workarounds to this problem.
• Whenever a stroke looks jaggy or weird, try the other two position settings, as they can sometimes have surprisingly different results.

Inner Shadow

• Draggable: while the Inner Shadow section is selected in an open Layer Style dialog, you can drag the canvas to adjust the positioning of the effect
• Don't let its name limit you - it can be used for much more than shadows; try it with various Blend Modes
• It's one of three effects that includes a Noise slider. This makes it great for quickly adding a bit of texture to an object (try it with Overlay, Screen, or Multiply)
• With a 30000px distance and 0% Choke, Inner Shadow becomes a Pseudo Color Overlay (see previous section). Use this in conjunction with Noise to apply noise over the entire layer.
• With a 0 Distance and 100 Choke, it effectively becomes an Inside Stroke without the translucency bug. Use it in conjunction with an Outside Stroke if you want a two-coloured border on an object

Inner Glow

• Like Inner Shadow and Drop Shadow, it contains a Noise setting
• With 100 Choke and Source: Edge, it effectively becomes another Inside Stroke without the translucency bug. Use it in conjunction with an Outside Stroke if you want a two-coloured border on an object, and add a smaller 0 Distance, 100 Choke Inner Stroke for a three-color border
• With 100 Choke, Source: Center, and 0 Size, it becomes a Pseudo Color Overlay
• Despite Inner Glow appearing above Satin, Satin's effects will be displayed over the top of Inner Glow's. I assume this is a bug.

Satin

• Usually only affects a portion of the inside of a layer, so use this to add nuance to an other-wise flat layer.
• Draggable: while the Satin section is selected in an open Layer Style dialog, you can drag the canvas to adjust the positioning of the effect
  
• Can sometimes be used to affect only certain elements of an image by carefully adjusting angle,  distance, and size, though this potential is constrained by the limited control of the settings. 
• With 1px Distance, 250px Size, it becomes a Pseudo Color Overlay

Color Overlay

• The simplest of the Layer Style attributes
• Affects entire layer, which is very useful
• Depending on which Blend Mode you use, you can use it for different purposes including, but not limited to: desaturate (Saturation), intensify (Overlay, Color Dodge), tint (Color, Hue), de-tint (Subtract), adjust brightness/contrast (Darken, Multiply, Lighten, Screen, Luminosity)
  
• Can be simulated by Pseudo Color Overlays, which allows several whole-layer effects at once

Gradient Overlay

• Useful for helping to simulate lighting or depth
• Try using a gradient with a combination of opaque and transparent areas to add a glass-like glare or sheen
• Draggable: while the Gradient Overlay section is selected in an open Layer Style dialog, you can drag the canvas to adjust the positioning of the effect
• A Gradient Overlay that looks good on one shape will frequently need to be adjusted before it looks good on another shape.  Before adjusting the gradient itself, try fiddling with Reverse, Angle, and Scale, as well as mouse dragging the canvas

Pattern Overlay

• Basically allows you to import any raster image into your Layer Styles, which adds a whole new dimension of possibilities. As well as actual patterns, this can be used to add texture, photographs, or even text to your Layer Styles.
• Consider creating custom patterns specifically for use with Layer Styles (Edit>Define Pattern)
• By using a custom pattern that is a single solid color, this becomes a Pseudo Color Overlay. Because of Pattern Overlay's position in the attribute hierarchy, this is also the only Color Overlay (pseudo or otherwise) that lets you use a Gradient Overlay over the top of it.
• Draggable: while the Pattern Overlay section is selected in an open Layer Style dialog, you can drag the canvas to adjust the positioning of the effect
• Remember to play with the Scale slider, as it can make a powerful contribution to the effect
• The Link with Layer checkbox refers to whether or not the texture will change when you move the layer around the canvas
  

Outer Glow

• Don't let the name limit you. With the right blending modes and colors, it can be used to simulate shadows too. 
• Use it in conjunction with Drop shadow to simulate lighting from two simultaneous sources.
• Match the Color, Blend Mode, and Opacity with those of Color Overlay for a seamless continuity between the two effects (great for making fire or lights)
• With a 100% Spread, it effectively becomes an Outside Stroke without the translucency bug. Use it in conjunction with an Inside Stroke if you want a two-coloured border on an object.

Drop Shadow

• Don't let the name limit you. With the right Blend Mode, it can be used to simulate glows too. Try combining it with Outer Glow for a two-part glow (eg. a large soft blue glow with noise combined with a short, intense white glow without noise)
• Draggable: while the Drop Shadow section is selected in an open Layer Style dialog, you can drag the canvas to adjust the positioning of the effect
• If the rest of your Layer Style is translucent or transparent, uncheck Layer Knocks Out Drop Shadow to avoid a sharp, unnatural cutoff between the layer shape and the shadow.
• With a 0px Distance and 100% Spread, it effectively becomes an Outside Stroke without the translucency bug. Use it in conjunction with an Inside Stroke if you want a two-coloured border on an object.

In Photoshop, any pixel that isn't 100% opaque won't have its Blend Mode honoured when flattened or exported. Note that this issue isn't unique to Layer Styles.

Take the following [somewhat ugly...sorry] example:

The shape on the left has a blue Color Overlay and a white Inner Glow and white Outer Glow. Because of the Exclusion and Difference Blend Modes, these glows appear magenta and yellow. 

The shape on the right is exactly the same shape, but flattened*. Notice how the Blend Mode of the Inner Glow was honoured, while the Blend Mode of the Outer Glow was not. 

The Inner Glow was honoured correctly because it occurred on a 100% opaque portion of the shape, due to the Color Overlay underneath the Inner Glow. 

Had the Color Overlay been 50%, the yellowness of the Inner Glow would have persisted, but only partially. Had the Color Overlay not been there at all, the Inner Glow would have suffered the same fate as the Outer Glow. Namely, it would have reverted to Normal, and become white.

* in this case, the shape was flattened by being converted into a Smart Object. You'd get the same result with Layer>Flatten Image, Rasterize Layer, or if you saved it as a PNG.



That's it for the guide. I hope it's been useful, and happy creating!

I just made a HUUUUUUUGE change to my logo. Do you like it?

If you haven't got your magnifying glass handy, I'll help you out: it's the little symbol at the end. It was ™, and now it's ®.

But I wasn't joking about it being a huge change. Anyone can use ™, as it has no legal weight. But you're only allowed to use ® if you've been legally recognised as the holder of a registered trademark.

As of recently, I'm finally the legal owner of the trademark "Volnaiskra". It's a surprisingly convoluted process that required lots of paperwork, hundreds of dollars, and some 8 months!

It's a pretty small (albeit expensive) thing, but it feels like a bit of a milestone to me :)

UPDATE: Spryke is now on kickstarter! If you want to see this rich universe (and its alphabet) come to life, please support us by becoming a backer!

A great way to enhance a gameworld's believability and atmosphere is to make a custom alphabet for it. The written word is all around us, and plays a major role in making our world look and feel the way it does. A unique alphabet helps make a unique gameworld. 

Anyone who's ever tried designing a font knows how difficult it is. Our brain is very sensitive to disturbances in the flow of readability, and each tiny alteration to curvature or line thickness can mean the difference between elegance and awkwardness.

The good news is that the rules are much looser when designing a fictional alphabet, and it can be very fun. But there's more to it than just throwing down some random squiggles. I've recently designed a complete alphabet for Spryke, and I'll take you through my whole process. 

First off, let's take a look at some reasons you might want to design a custom alphabet for your game.

• Written language is a key component of culture (even its absence in oral cultures is a key component of those). If you want your world to feel like it has its own living, breathing culture, then you need to think about its written language.
• If your game is set in a fantasy or sci-fi world, your characters probably don't speak/write English. Which begs the question: what do they speak/write?
• If your game is in a fictional present-day country, a bespoke alphabet shows that you've put some effort into making your country feel unique, rather than just lazily assembled a bunch of general racial stereotypes, à la the Just Cause and Far Cry series.
• You could use your alphabet as a sort of code and encourage players to try and decipher it. You could even base puzzles around it.
• A fictional alphabet means you can populate your world with billboards, signs, and slogans, without having to actually write catchy and convincing content for those billboards, signs and slogans.
• If you have a number of different cultures/races/species in your game, using multiple alphabets would be a good way to differentiate between them, even when the characters themselves aren't present. For instance, inscriptions in an ancient rune could indicate the presence of a long-gone foreign race, while text on an empty space ship could emphasise that it belongs to an enemy.
• Designing a bespoke alphabet is fun!

An alphabet's aesthetic and functional aspects reveal a lot about its creators, its forms naturally springing from the traits of the home culture.

Take this ancient alphabet, for example:

Comprised mainly of sturdy, masculine shapes, these glyphs have a uniformity of size and economy of form that makes them seem almost engineered, rather than merely written. They are solid, upright, efficient. 


Judging by this alphabet, one could imagine that it was created by a pragmatic, rigid culture that prized order, strength, and structure. And actually, that's not a half-bad description of the ancient Romans. 

Now look at these characters from another ancient alphabet:

These lack the frugality and symmetry of the Latin characters, and are much more complex, intricate, and floaty. One could suppose that the culture that created them was one that cherished sophistication, artisanship, and nuance. 

Now examine a third ancient alphabet:

These jagged, spiky shapes have neither the balance and structure of the Latin letters nor the grace and complexity of the Chinese ones. Instead, they evoke an aggressive, almost savage vibe. And so they should; they are the Dovahzul alphabet: the ancient language of Skyrim's dragons. 

Your game's alphabet can and will inform your audience about your gameworld. If your alphabet looks interesting, boring, complex, or frivolous, your game's inhabitants will seem interesting, boring, complex, or frivolous. Use this to your advantage, and make sure that it's communicating the message you want it to convey. 

Apart from looking cool and a little bit hostile, there's another reason the dragon alphabet above is comprised mainly of long heavy slashes: It was carved by dragons. Dragons didn't have pens, brushes or chisels, but claws, and the clever designers at Bethesda took this into account. 

You may not have consciously thought about these logistics when looting Skyrim's tombs, but you probably noticed it unconsciously on some level. By considering not just the alphabet's personality, but also its logistics, the Bethesda crew designed an alphabet that feels right.

There are various technological factors that can influence a successful alphabet. These Anglo-Saxon runes were usually carved into wood, so they avoid curves and horizontal lines (straight lines were easier to carve, and horizontal lines could have caught in the wood grain and split the wood):

Conversely, this gorgeous Sinhala alphabet from Sri Lanka avoids straight lines and corners. Sinhala was written on fragile palm leaf paper, and sharp corners would have caused tearing. 

As you can see, technological considerations can have a profound impact on the look of your glyphs. Paying attention to technological logistics won't just make your alphabet more believable, but may take it in an exciting aesthetic direction. 

Some things to think about:

• What tools would the people/creatures in your game use to write with? 
• What surfaces would they use? 
• Do they have an abundant culture that would foster artisanship?
• Do they live in a dangerous world and use a minimalist alphabet that is easy to write in a hurry?
  

Spryke is set in a distant planet sci-fi setting, so my alphabet needed to look somewhat modern (as it would most often be rendered by precise machines, just like in our present-day world). It would also need to be alien and unfamiliar, while maintaining an element of fun to suit the cartoony vibe of the game.

There are loads of writing systems on Earth - possibly more than you think. Look through a few of them to get ideas about what your own will look like. 

So, do some research and get ideas. Don't forget to check out different fonts where possible, as they may employ different design solutions. After all, a traditional Japanese scroll will have a dramatically different aesthetic to downtown Tokyo neons. 

But if you're like me, inspiration is just a few centimetres away!

Both of my arms are tattooed with a prayer written in Glagolitic, an ancient Slavic alphabet. Convenient! Clearly, I have an affinity for this alphabet, and so this is the one I chose as my starting point. 

Most writing systems are constructed using just a few building blocks, in various combinations. It's a good idea to pick your building blocks before you start designing any characters. This will help you create a cohesive design while guarding you from relying too heavily on the shapes of your native alphabet.

Pick a few appropriate shapes that will form the backbone of your alphabet's aesthetic. Remember to peruse existing alphabets for inspiration if need be. 

Spryke's alphabet needs to look a bit cartoony, and like it belongs to an alien race. My starting point of Glagolitic is actually a pretty good choice, because it's unique looking and looks quite alien to modern eyes, having gone out of usage long ago. In addition, its hollow circle and equilateral triangle motifs lend it a certain geometric look that fits well with my desired cartoony vibe. To make my alphabet a bit more hi-tech looking, I focused on straight lines and precise angles. 

Next, I used those elements to doodle several pages' worth of characters, referring to my Glagolitic alphabet (ie. looking down at my arms) as I went. Some characters looked good, others sucked, and most took several iterations to find their sweet spot. 

Once I had loads of characters on paper, I went back through them and circled the 40 or so that had the most promise. I ported these into Photoshop using the vector shape tools (You could of course use Illustrator or some other software). After plenty of fine tuning and iteration, my alphabet finally took shape. I'd created 52 finished characters in all:

Some things to consider while working on your characters:

• Keep line thickness as consistent as you can
• If a particular character calls for it, you can of course deviate from your core shapes, angles, and line thicknesses. Just don't deviate from them thoughtlessly or by accident.
• As with all design, the secret is in iteration, iteration, iteration.
• Try all of your designs flipped or rotated - they might look better that way
• Decide how the weight of your alphabet will feel. Will your characters be grounded downwards like Latin, pull toward the heavens like Hebrew, or float weightlessly like Chinese? I chose to centre mine weightlessly, as I felt that this made them feel more digital, spacey, and self-contained.
• Only do uppercase/lowercase if you have a really good reason for it, as it'll double your workload. Many real-world alphabets only have one case.

Forgot about punctuation, didn't ya? For our purposes, there are two types of punctuation, which I'll call structural and emphatic. 

• Structural punctuation - things like commas, dashes, and semicolons - helps readability by organising sentences correctly; we don't really need it here, since our fictional text won't be readable anyway. Though feel free to include it in your alphabet, as it may add: visual interest, authenticity, diversity.

• Emphatic punctuation emphasises the context of a phrase by indicating that the words "came from somewhere else" or that they are important!! Could emphatic punctuation even be used to emphasise uncertainty? Or perhaps even.............................................silence? 
  

Whether or not you need punctuation at all is up to you, and the specifics of your game. I decided that Spryke won't need structural punctuation, but could benefit from some emphatic punctuation.

If you choose to use emphatic punctuation, you must make it somehow decipherable by your audience, even though the rest of your alphabet isn't. There's no point inventing a question mark symbol to replace "?" if people will think it's just another letter.

There are several ways to tackle this:

• If your game's inhabitants are modern day humans, it may be appropriate to just use English punctuation marks, since some modern-day non-Latin languages also use them.
  
• You could use creative variations of English punctuation marks that look somewhat original, yet still understandable.
• You could ditch punctuation marks altogether and rely on other methods to emphasise certain words, like colour, spacing, italics, bold, underlining, and size.
• You could make your punctuation marks look so different from your letters that there's no mistaking the two.

I went with the last option, and made three different punctuation marks. My players won't know what exactly they mean, but the marks should stand out enough to make it clear that they imply emphasis of some sort. Their unique design, raised position, and parenthesis-like clumping of other characters should all help with that.

As with emphatic punctuation, numerals need to be visually different from your letters. I achieved this in two ways. First, I made them smaller and more uniform in size. Second, I constructed them from different shapes. I exclusively used arcs (incomplete portions of circles), to give them a different appearance from the letters, which were made from complete circles, triangles, and straight lines. 

I'm writing this in a small home office, yet I can see more than 20 different fonts without even getting off my chair: several across my computer screens, a different one on the logo of almost every appliance and piece of computer hardware in the room, and a few on an old bill on my desk. No matter where you are, I'll bet you'd find plenty of fonts around you too. 

Our world is loaded with different fonts, and things would look weird if everything was suddenly written in just one. So your gameworld should probably have a few fonts too. Making new fonts won't be quite as time-consuming as inventing your characters was, but it will still take work. I suggest making a few fonts, with specific use-cases in mind. 

I made four:

1. My original font, which works well at small sizes due to its thin, uniform line weight.
   
2. A bolder one suitable for larger uses like building signs or machinery. I added slight curvature to various triangles and lines to give a softer, bolder look.
3. A rough, scrawled version for graffiti, cave paintings, etc. This was the only version in raster format.
4. A playful, stylised variant, for use on advertisements, neon signs, and the like. To give it a friendlier look, I all but eliminated sharp corners, and tweaked the configurations of various characters, ensuring that white space between the various elements was kept loose.

Done! I now have a unique, cohesive, and interesting alien alphabet comprised of 52 letters, 10 numerals, 3 punctuation marks, and 4 fonts (that's 260 characters in total). I can now pepper it throughout Spryke's gameworld as I continue to develop it, confident that I have glyphs to suit any context.

I hope this helps someone, and if you've designed your own alphabet, I'd love to see it! 

To watch Spryke as it evolves further, like my facebook page.