Visual scripting – The good, the bad, the ugly

Visual scripting – The good, the bad, the ugly

I was contacted by someone regarding Playmaker development and it inspired me to write a blog about visual scripting in general and how few programmers are actually using visual way to make games. It’s fast and easy to learn, but comes with its own set of caveats.

I never inteded to make games. I grew up playing video games on C64, Amiga and PC but that was it.  A while ago (like 7 years ago) i wanted to change my job due to dissatisfaction and coding seemed like a wise move – i had great knowledge of computers, the job was in demand and i like staring at the screen for hours on end. To avoid wasting time learning on my own, i took some (both shorter and longer) courses in Java. It was a nightmare, i didn’t understand any of those things, the constructors, the variables, nothing, it was hard for me to make a simple calculator. Few months passed (with those courses now behing me and little knowledge gained) until i tried coding in Unity as i thought that something less abstract and more hands on (as in you can see the result right away even with the smallest of scripts), would help me finally understand how all those things work together to create a functioning program. It didn’t really help, especially with Unity having its own programmming API which introduced even more things to confuse me like transforms, vectors, colliders and so on. As a last resort, i decided to try Playmaker since i actually liked the concept of making games and thought that it could finally help me learn to code. It was when i started using Playmaker and exploring actions’ code that i finally understood how it all works. I had one of those epiphany moments where everything finally clicks into place and starts to make sense. After that, i exponentially learned more and more and the moment where i was into arrays, hash tables, structs, execution orders, optimizations, materials and so on came in a flash.

More than 6 years passed and i’m an avid Playmaker user now with decent knowledge of C#. It’s an amazing tool that shines brightest when being used by one man or small teams. Sure, Hutong Games proudly states that Hearthstone is made with Playmaker, but the case study from Unity website mentions it as “something we’ve used in the game to create scripted events alongside our animation system. It was actually a big help in enabling our art team to independently make cool events in-game.“. To be honest, i believe it was only used in early prototype phases of the game for quick iterations on some parts of the game and i guess with it becoming a huge cash cow and having such a big team, they’re probably on full scripting now (last info i have is that they have 70+ team members as of September 2016.). It’s an educated guess on my behalf and perhaps i’m wrong, maybe they’re still working in Playmaker. So what gives me the right to question if they’re still using it or not? Why would they do that if Playmaker is that awesome?

I never worked in a team that counted more than a few coders and i believe it’s really hard to get people to follow standards regarding class, variable, event names and such without a good team lead, good cooperation and good documentation. That’s one of the parts where using Playmaker is very tricky, especially when it comes to global variables and global transitions. These are extremely handy to use since you can call upon the global variable from any FSM or script, so unexperienced game makers tend to overuse them. It’s not long when you’ll want to rename a global variable since you didn’t define the naming conventions properly due to inexperience or you just wanted to try something out in a jiffy. Unfortunately, former can’t be renamed at all and latter caused me a lot of troubles when being renamed, even unfixably screwing up the entire production ready project. When coding, it’s a piece of cake to refactor mostly anything, so this is a huge drawback for Playmaker, you really need to plan ahead since renaming globals is irreversible and renaming and often just deleting global transitions to clear up the clutter can make problems in the long run. Fortunately, i believe this is Playmaker only issue (which hasn’t been resolved for years) and that the other visual scripting solutions are more flexible. 

Problem is easily avoidable by NOT USING global variables at all (which is something you should know early on, but nobody will tell you that), but instead using a globals manager object that will hold variables you will be using game-wide and then getting them and setting them to an object’s local variable AND then setting them back when the change occurs. It’s a drag, it takes more actions and more time, but not as much as you will spend trying to fix the mess that occurs with global variables (inability to be renamed is only part of the problem, there’s many issues with them, run a search for “global variables” on Hutong Games forums). As for global transitions, try putting in a prefix Global before them as you may run into problems with local transitions being named the same as global ones.

As you all know, C# is written in scripts loaded with classes, methods and variables as opposed to FSMs. Finite State Machines are a powerful tool also used in scripting (mentioned to great extent in popular book Game Programming patterns written by Robert Nystrom), but Playmaker takes it to a whole new level. If you haven’t tried it before, it’s a lot different than your usual visual scripting solutions (which are scripting, but visually, duh). You basically use chunks of code which represent a function or a method (called Action in Playmaker) and stack them in desired order. While being the power that drives Playmaker, it is also what limits it. The best of the best of Playmaker actually comes when you learn to code properly and make your own custom actions or template FSMs that can be reused via RunFSM action. It can simplify and uniform your project quite nicely.

That said, we come to the code’s most powerful pro – reusability. It’s quite easy to reuse code and extend it whenever you need, but when working with state machines in Playmaker, proper planning is needed to avoid pitfalls. It took years of experience for me to strike a fine balance between making “one of” FSMs that will probably be used few times and which only need a variable change when being applied to another object and template FSMs that i will be reusing. Latter almost always tend to become too large to handle (and slow down the editor) if they’re too universal, so it’s better to break large state machines into smaller ones for better control and reusability, make templates out of them and make them data driven unless you want to to change hundreds of FSMs manually when you implement something new or play around with tweaking variable values.

There’s also some QOL features missing, like inability to group and/or hide the states inside the group which is a huge drawback and can easily lead you into making a spaghetti monster akin to Blueprints from Hell. It has been on a roadmap for a while, but i don’t think we’ll see it soon.

Experience with Playmaker made me want to check out other visual scripting solutions too and you really have a wide variety to choose from.

Flow Canvas (+ Node Canvas)

Pretty and battle tested visual scripting solution

A highly polished (in terms of interface and functionalities) visual scripting asset that has been on the market for 6 years comes with a great documentation. If you are coming from a Playmaker background it may seem confusing a bit, but it’s easy to get a hold of. There’s Blackboard for holding variables as well as Nodes which come in Constructor & Extractor (for creating or exposing struct components), Events, Functions and Flow Controller (if-then-else, while, for each) flavors. There’s Macros, which are a bunch of nodes nested into one node for reusability, and further more, you can connect everything with Node Canvas, enabling you to put your nested groups in a group.

Yo dawg

All in all, a battle-tested solution, regularly updated and with proper documentation and support that i can’t recommend enough. If you feel confident with Playmaker, this one is a logical next step towards more advanced solutions like Unode.

uNode

True visual scripting solution that comes with a C# parser/generator

This is a true visual scripting solution that you shouldn’t get your hands on if you don’t have prior experience with code, or you’re quite comfortable with Playmaker/FlowCanvas/Bolt and you know a thing or two about coding in general. It has a bit of a steep learning curve and it’s poorly documented, but, in my opinion, the best true visual scripting solution there is at the moment. I believe only one guy is working on it, and i can’t praise him enough for his work. The feature i like the most is the actually working C# generator/parser, something we all waited for in Bolt and never got. Excellent tool for getting deeper into coding once you master the essentials. Watching that code gets written by itself while you play with nodes is a joy to watch. It’s regularly updated so, for now, there’s no risk of it being abandoned any time soon.

One may argue “why are you using it when it’s faster to write code than to waste time connecting the nodes?” but even if you can write code, some people find it a lot easier to visually connect the dots to what is happening in the script then to read lines of text and it’s a great code learning tool since you can parse and dissect any script.

Bolt

Visual scripting solution back by the might Unity Technologies itself

Bolt is a tough one. Most though of it as a “Playmaker killer”, but the truth is it’s a completely different solution (Playmaker is actually quite unique in that regard), a regular visual scripting framework with flow and state graphs. It’s like uNode under the hood (tho a lot prettier i must admit), but without the ability to export or parse C#, which is a bummer. It was supposed to appear in Bolt 2, but then they got bought by Unity Technologies which has other plans for it and that was the end of it. Good thing about it is that it is the only visual scripting tool officially owned and backed by Unity Technologies, which means that it will usually be compatible with latest Unity version and there is little to no chance for it to be abandoned. But unfortunately, Unity Technologies seems to have a panchant to heat up for some things then move on to something else while leaving things behind unfinished. I hope that it won’t happen to Bolt and that it will become something like Text Mesh Pro (also bought by Unity Technologies in 2017.) which is now a must include in all projects, pretty stable and powerful.

It has features that i usually expect from any VS solution nowadays, live editing, node nesting (called flow states and super states in Bolt), reflection and so on, so i have no complaints in that regard.

Bolt might be something that will gain widespread popularity, but as of now, i don’t see an increased demand for Bolt users among platforms like Freelancer, Upwork and workwithindies.com.

If you are a hobbyist coder or a small team that is ok with using LTS versions of Unity, not releasing on last gen consoles and don’t need all the latest flashy things that they have been introducing, then most of the visual scripting solutions will be ok for you (probably even the ones last updated in 2019. will probably work in Unity 2018.). Of course, you will probably be limited to Steam and last gen consoles.

I believe that’s where most of the stigma aimed at visual scripting comes from. Unity is developed and maintained by thousands of people, C# is also used for other purposes and they’re a safe career bet. Any visual scripting solution? Its super niche, and it might be good, but it also might be abandoned tomorrow.

Like it or not, using Playmaker (and other visual scripting solutions) is quite niche (i had only a handful of freelance jobs using it) and it usually won’t land you a job in the industry if you don’t know how to code (if that’s what you’re after). It WILL help you to LEARN to code, which is a great deal and it WILL learn you about the game and data design and everything that goes into making a game. Few years in, i knew how to code well enough to get into a team that was making one of the Apple Arcades first releases, Starfetched by Crescent Moon Games. If it weren’t for the Playmaker, i’d probably miss the opportunity since i knew well enough how to handle the stuff that was already in the project, made by a programmer much more skilled than myself.

If you are a one man or a small team which has that crazy idea of making video games but doesn’t know where to start, i wholeheartedly recommend to begin with visual scripting, it’s a fun way to learn to code without being overwhelmed and in the long run you may actually stick to using some of those solutions for production projects as they will enable you to do so. My first game, Rick Henderson, is made almost completely in Playmaker and besides Steam it will be available on PS4, PS5, Nintendo Swich and Xbox X/S.

Rick Henderson goes to Early Access on 23.12.2020.!

Rick Henderson goes to Early Access on 23.12.2020.!

Current Early Access version contains:

■ Three player ships with different special abilities and stats
■ 40 different enemies
■ 5 levels
■ 5 bosses in three variations each (15 bosses total)
■ 25 weapons
■ 250 unique waves
■ 5 random events (Warp Malfunction, Asteroid Field, Minefield, Laser Barrage, Meteor Storm)
■ 20 perks to choose from at the end of each level

Making Waves in Rick Henderson

Making Waves in Rick Henderson

The most important thing, the flesh of the game, are enemy attack waves. In this short log i will show you how they are made.

The process is a bit tedious and probably can be automated to a certain amount (which i will probably be introducing to add some random variety) but it serves me well and gives a decent amount of control over what i do.

First step: Enemy placement

First, i choose what enemies will the wave contain (out of 40 enemies, yikes) and put them in the place i want them to be spawned. In this case, this is a simple one, enemies coming in from one direction.

I usually avoid putting them one behind another to avoid overlapping when they are on the screen if they are using a simple movement pattern (from right to left at a fixed speed).

After that, i put them in prefab and use a template i have for spawning and assigning positions. Spawning coordinates are manually copied from instances into a big table containing all the enemy waves, their elements and their positions.

A big spreadsheet i hate the most

Depending on the placement on the screen, enemies are applied a defined movement speed and direction. When placed right from the center, they will go left, when placed left of the screen, they will go right, when placed up – they go down, when placed down – they go up.

That’s simple, but it’s boring to have enemies always move in the same manner. All the enemies in the picture above i placed will use their own speed which can cause them to overlap and look messy when they appear on screen. So i have a couple of spawners with their tags. I use them to child the enemies to them and get additional info. For example, i can place them in singles squadron for all of them to use their base speed, or under squadron squadron (yeah, i know) for their speed to be overriden with whatever i type in the inspector. That way i can have that big asteroid cannon move slowly as well as the ships around it, like they are escorting it. I can also select the ships from the wave to keep their own speed, and others move like squadron, together. In this example, i’ve put the purple ones to move slowly with the big asteroid cannon, and the small greenish ones to move at their own accord.

That also gets repetitive so i’ve put another spawner type – waypoint enemies spawner! That way i can select any enemy from the wave and assign it a nice set of waypoints to follow (local or global), stop and continue during the movement and so on.

Another spawner type which is use exclusively on it’s own is the warp spawner, which spawns enemies on a (selectively) random place on the screen. Since it’s semi-random, i avoid using another spawner types to avoid overlapping. Nothing will happen to them since they can’t collide, but it looks ugly and unconvincing.

Of course, when combining waves, appropriate positioning and timing is also neccessary to avoid linear moving enemies with waypoint spawned ones.

Final look with couple of systems in action

In the end, it all looks something like this. Two round guys up and down move down and up, respectivelly. Thew won’t collide since they lock onto player and start following him. Small asteroid cannons follow the waypoints and come in front of the big asteroid cannon and two small ships that are escorting him at the same speed. Four small ships behing the big cannon move on their own accord, they are very fast and will overtake the big guy before they enter the screen.

That’s it, multiply that by several hundred and you’ve got yourself a game 🙂

Rick Henderson on GDWC2020

Rick Henderson on GDWC2020

I’m proud to announce that Rick Henderson has been selected as a participant in the Game Development World Championship 2020 in the commercial title category. GDWC has been (to my knowing) been held since 2012., and it’s a great way to help developers gain visibility.

In today’s video game market, which is overly saturated, it’s quite hard to get your game noticed unless you have a strong publisher, so every bit counts. That’s why, my dear subscribers, i need your help. The more visibility i can get, it will eventually translate to more wishlists and more copies sold and hopefully enable me to work on video games full time – my long time dream. I hope that i can make it with your help.

You can vote HERE

Optimization time! Part one – Pooling

Optimization time! Part one – Pooling

I’ve been postponing this for a long time, but some time near the end of the past year i realized another overhaul is due, this time for optimization purposes. It’s a long and tedious process and can get you into a rabbit hole that can be hard to get out of. My recommendation is not to overoptimize, but do take care of bottlenecks as soon as they appear since they can get you back to square one too late in the development to fix in a reasonable amount of time. Plan your design accordingly and optimize as soon as you finish an enemy design or feature, that way you lay a solid foundation for future content creation that will utilize the same, optimized framework so you don’t have to worry too much later on.

Avoiding Instantiate and Destroy by using Pooling

Pooling is a great tool to avoid those dreaded instantiate/destroy calls. You’d think that computers in 2020. can chew up pretty much anything you throw at them, but it’s not that simple. Whenever you create a new object (in our case, a prefab instance) it is stored into memory (with resources taken to do the operation itself and memory taken to actually store it) along with the pointers that, well, point to that part of the memory so that it can be found and used whenever needed. Of course, memory manager needs to find the unused part of memory to use and clear it up before use. That process is called Garbage Collection and it’s the usual suspect in most of the performance problems. It all happens quite fast, literally every frame, so if you ever used profiler in Unity you will see a GC Alloc column which tells us how much garbage is generated every frame. You might see a value of 2-3 kilobytes and think “oh, that’s not much”, but bear in mind that if you have 60 frames per second that’s 120-180 kilobytes of garbage per second. Per minute, that’s 7-10 megabytes, so without collecting the garbage your game would probably slow downs and crash quite soon.

Luckily for us, Garbage Collection in Unity is automated so you won’t have memory leaks which will lead to crashing. Automated means you don’t need to clear stuff out of the memory manually, but, unuckily, it uses garbage collector that stops the execution of the game code (though since Unity 2019 you can use the Incremental Garbage Collection which can alleviate these issues if your garbage footprint is small enough). You will see those exact moments in your profiler as a spike and your game will stutter, which is annoying for the player.

Mr. Spike

So, only reasonable solution to this problem is to avoid creating garbage. But how can you do it if you are creating new bullets, enemies, asteroids and pickups all the time? By reusing them, of course! It is called Pooling (since you use a “pool” of objects) and it is a old but gold method for boosting performance in video games.

It’s not too hard to grasp, you simply instantiate all the objects you will be using on the start of your game (a bit simplified, it takes some time to load everything so you should do it in segments in appropriate time, but more on that later) and then you simply activate them and deactivate them (colloquially called spawning and despawning). Such a simple solution, but with an expected caveat. When you deactivate an object, it keeps all its properties from the last frame of its active state. So, the despawned enemy will keep its position, rotation, hit points, animator states, you name it, and next time you activate an object it will be in the same state as when deactivated, rotated in unusal direction, with 0 HP and animator stuck on same frame in the middle of an animation. So what we need to do is reset everything to its original state before deactivating the object. Seems simple enough, though it can get complicated if you have object that have children and they have their own children and so on, which is usually the case.

A simple diagram of object with two children and their variables

In this simple diagram above we can see an enemy ship with two children – Jet and Gunpoint. They are all spawned and need to be despawned. But what is important here is the order of operation. When we first spawned them, we spawned the ship first, then the Jet and Gunpoint as children. So we need to do that in reverse order because if we deactivate the ship first, children will be deactivated too before they get the chance to reset their variables.

When the ship takes enough damage to be destroyed, it sends the event (don’t worry, sending events is quite cheap in Unity, hoorah) to both Jet and Gunpoint to reset their variables and despawn themselves. They can either send the event that they finished their reset process back to the parent (ship), or the ship can wait a few frames for them to finish and then reset its own variables and despawn. That way, we have a nice, clean object ready to be reused for the next ship that will be spawned.

Don’t think that pooling alone will help your game magically run at 300 FPS since it’s not the only part of the equation of successful performance management but it does eliminate the worst offenders – instantiate and destroy calls.

If you’d like to read more on the subject, i recommend a great article by Mark Placzek that i often like to read again. It also has some good technical tips on creating your own pool, but if you’re a one man army like me i really recommend using a plugin for pooling from the asset store, they work great out of the box, they are performant and they are easy to use. The one i use is Pool Boss but i can also recommend Pool Kit if you have 40+ cookies to spare.

For more stuff on memory management and garbage collection in Unity i recommend their own manual which you can find here, it’s a cool read to get into the innards of how things work under the hood.

Beta testers wanted!

Beta testers wanted!

As the early access draws near, i need some people for testing the game and giving me their opinions and bug reports.

All testers will get access to latest version in the dev branch and a steam key when it gets to early access.

You can apply by posting here: https://steamcommunity.com/app/1023790/discussions/0/2865909716042511185/

Designing enemies on a budget

Designing enemies on a budget

I posted a small video of an enemy from Rick Henderson on Twitter yesterday and it gained a lot of traction so i think it would be interesting to post some stuff on enemy design and how i do it.

Ready, aim, fire! Boshin dropping its load

When i started making Rick Henderson i wanted it to be something unique with easily recognizable enemies defined by their faction, design and modes of attack. With something so ambitious as a one man project that works on more than 50 different enemies, making each ship original can be strained in both design and financial aspects of game development.

Boshin was originally designed as an abomination of multiple Paragon Cult faction enemies, easily identified by their purple color and glowing orbs. I wanted some more ships for that faction and funds for pixel artist were already spent so i had to think of a way to utilize what i already had since my artistry level is quite low. I was lucky to work with an artist who knew what he was doing, had a concise palette and distinct shapes for each faction. So i made a pixel art collage that was made out of other ships’ parts in a way that makes it recognizable yet different from other ships. 

1 + 2 + 3 + 4 = Boshin!

Harder part was designing the pattern of attack for it. I try to avoid the usual move from right to left while firing pattern, and if i really have to use it i try to be creative with it. This was the case with Boshin. 


One of the most important aspects of enemy design in shoot ’em up games is “telegraphing”. It is a concept of showing the player that the enemy is about to fire bullets at him. Though not really important for so called “popcorn” enemies (easily destroyable, firing slow bullets rarely) it is a must for enemies like Boshin that fire five fast bullets in a burst. You need time to react, otherwise it wouldn’t be fair and you would feel frustrated by getting hit.

So, what could i do with limited time and no further financial resources? 

Cute guy, but what will he do?

Here is the image of the ship when it comes into screen, with the lower portion of wings with guns drawn into hull. We see it for the first time and we still don’t know what will it do. Upon entering the screen, after a random time in a defined range, the ship plays its opening animation. Best i could manage without artist was to simply obscure the lower portion (wing with gun and an engine) and animate it as going out of the ship. Now that we see the gun, we have a clear idea that it will shoot from it. By adding a bright red light we rise the tension by letting the player know that something is definitely going to happen. It goes out of the gun, widens, and the gun is fired with bullets coming out spreading no further then the red light angle implied. To keep things interesting, i put a new bullet type for Boshin and made the bullets rotate and move at random speeds.

Opening animation is another example of keeping it cheap while trying to look good. It’s not so big, only 22 frames that were just a few layers of parts moving pixel by pixel. Animation of the red “laser targeting device” is made out of two animations since it’s quite large and can’t fit in one texture (maximum is 8192×8192). I wanted to keep authentic pixel art feeling so i did it manually, it consists out of 93(!) 128×64 frames, which gives us a sprite sheet that is 11904×5952 pixels in size, hence the reason for cutting it into two parts. 

Yikes!

After finishing the basic visuals and a small problem with the sprite sheet size, there were some more technical challenges that needed to be taken care of.

It is not yet implemented for Boshin, but most of the ships have some kind of blinking lights on them. To have animated blinking light and the attack mode activation animation like Boshin playing at the same time, you require animation layers and a bit of tinkering with that too. 

Blink, bling

Also, you probably don’t notice stuff like this, but in the video, lower engine does not have engine jet animation playing. I might be a bit of a perfectionist, but i like things nice and tidy. I can either put a new animation, for example a thruster activating then going into regular loop (which requires yet another animation layer), or put an already looping thruster animation as a child prefab and animating its position to follow the animation, with setting the sorting layer to be behind the ship.

The final issue is the collider. As the ship changes its form, it needs to be able to detect hits on the new, extended part too. That can be either done by the most gruesome way known to man, by editing it in the animation window itself, frame by frame, or by using great free asset from the Unity Asset Store called Advanced Polygon Collider, a tool that automatically fits your polygon collider to sprite based on alpha tolerance and scale. It also does a great job in optimizing the collider by reducing vertices, so you don’t have to worry about the performance, at least on desktops.

So there you have it, from a visual idea, to implementation and overcoming slight technical difficulties, a fun and engaging new enemy ship is born.

Designing a Swarm Missile weapon in Playmaker

Designing a Swarm Missile weapon in Playmaker

Making the weapon itself

First thing we need to do will be making the weapon that will actually be launching those missiles, right? It’s a plain and simple contraption made of two FSM’s i called FiringSystem and FiringTimer. Firing system will handle the missile creation, and FiringTimer will take care of giving the weapon a rate of fire. It’s basically a countdown timer of cooldown between two missile salvos. It’s a really simple setup.

Firing System FSM

Here’s the graph of the system that controls missiles. Let’s get through the states one by one.

Firing System Controller

Idle and Stop firing states, triggered by Start and StopFiring global events (global event is an event that can be sent to this FSM from any other FSM) are empty. They are used to have the system in the state of waiting for the command from another FSM via global event, in this case, the FiringController (which there’s no need to cover here, it’s just an input system to detect the firing button has activated the FSM).

When the Fire global event has been received (dark gray rectangle, like Start and StopFiring), we will be getting the Countdown Timer Value from the FiringTimer every frame and compare that value via Float Compare action with 0 so we know when the weapon has cooled down. When the counter hits zero, we move to Get Fire Button state where the FSM will anxiously wait for you to mash that button to spawn missiles.

Get Timer Value

Ok, we’ve hit that button and moved to Missile Counter state. It is set to 0, and it will count the number of missiles we want to spawn. Once it gets to the predefined number, it will stop creating them and move on. Every time we enter the Missile Counter state, +1 is added to the counter variable and the missile is spawned in the connected SpawnMissile state. Immediately afterwards, we go back to Missile Counter state where we check the counter. In my case, when it hits 11 (so 10 missiles are created) we no longer move to SpawnMissile state but to Send Reset Firing Timer Event state. In that state, a global event is sent to the FiringTimer FSM to start counting down. Until the counter tells us it counted down to zero, we won’t be able to fire the weapon again.

Missile Counter
Resetting The Firing Timer

Of course, before we get back to the state of waiting for the countdown timer to do its job, we need to reset the Missile Counter to 0 so we can use it again. It is simply done by setting the value of the INT variable Counter to 0 in the mid state called Reset Counter.

Resetting The Missile Counter

Fun part – Missiles!

Now that we created our firing system that happily churns out 10 missiles in a matter of frames, we need to know what to do with them, right? I won’t be covering the topic of playing the sound of the missile or dealing the damage/destroying itself when leaving the screen or making the particle system for the trail as those are really not the point of this blog post and are part of some other intertwined systems. Instead, we will focus on the movement.

Our missiles are made of two components, the bullet itself that contains VerticalTranslate and HorizontalTranslate FSM’s and only the transform component, and the child element that holds the SpriteRenderer.

FSM’s dedicated to controlling horizontal and vertical movement of the missile

The reason why the missile is split into two GameObjects is because we will be using translate movement instead of physics for missile movement so we are unable to use the movement vectors for sprite rotation and instead have to rely on a different technique.

Horizontal Translate FSM is straightforward and designed with only one purpose in mind – to control the horizontal movement of the missile.

Horizontal movement of the missile

There’s really not much to it. We will apply a random amount of acceleration per missile so we get the effect of some missile being slower/faster than the others. Bear in mind that you also need to define the starting Speed of the missile if you don’t want it to start at 0 speed. I opted for 1.75.

VerticalTranslate FSM is where things get fun. Start state is a random event in which it is decided by pure randomness whether the missile will start moving up or down.

Oh, this one decided to go up! We’ll just make it move up a bit (you can also randomize that value, which i’ll probably do, but not too much) by adding the float value to the Y axis in the translation.

Moving Up

We will wait for a random amount of time before staring to move down.

Moving Down

The principle is the same, we are applying a negative float value to the Y axis and translating the missile so it slowly straightens itself and then starts nosediving.

If the missile chose to go down instead of up in the Start state, the rest of the states are exactly the same, we just apply negative value to Y axis in the Move Down state to make it go down and then the positive value in the Reverse Move Up state to make it go up.

Now that we have our missile moving all around we need to take care of the visual representation. As noted before, we are not using physics for movement but a simple translate movement (which is equal to clicking on the game object, holding down the button and moving it around the screen) so we need to relate on a simple technique to point the missile towards the movement direction.

Getting the missile position

First we need to get the current missile position, i’ll be saving it in the LastFramePosition vector2 variable since it will be the last frame position in the next state.

Looking at the direction of the last frame position

All we need to do now is to rotate the GameObject towards the last frame position and adjust the rotation. Bear in mind that i’m using 0 degrees of the Rotation Offset since my missile sprite is rotated towards left, but if your missile sprite is pointing right as things usually are, you should set the Rotation Offset to 180 so it’s actually looking in the opposite direction of the last frame position.

The reason we are doing the things this way, with the parent in charge of movement and the child in charge of holding the sprite and rotating it is because the rotation of the parent object would cause the missile to not move properly since rotation affects the translation of the objects.

Here is the final result with particle system added for trail as well as damage detection and all the things that make the missile a missile.

If the images are too small, you can find the FSM templates in my GitHub repository

What did i learn from a failed indieGoGo campaign

What did i learn from a failed indieGoGo campaign


Nobody likes to read about failing (or maybe they do since it’s a great opportunity to learn from others’ mistakes), but it’s a harsh reality in this line of work. The most important thing is to learn something new, and that can be only managed through trying. And when you try, you’ll fail. A lot.

A month ago i finally pushed the big, red START CAMPAIGN button on IndieGoGo and hoped for the best. After all, months of preparation were a guarantee that i will succeed, no matter what. I explored many successful crowdfunding campaigns, the pitch was good, teaser was cool, campaign was well designed with all the feature listed, expenditures broken down. I was completely transparent with what the funds will be used on and i hoped the material i provided (along with the demo available) will be enough for a few hundred people to pitch in a few bucks. With all those games gathering tens of thousand of dollars, why wouldn’t i have a crack at gathering only $3000?

I must admit that the only thing i was worried about was extremely small number of people that suscribed to the campaign (40+). Though IndieGoGo clearly states that it’s really important to make a huge mailing list so everyone can be notified of the campaign start (and it does show number of interestees in your product), i was sure that my twitter follower list (1000+) and profiles on various shmup and game development would do the trick.

After all, it’s 2019., who still subscribes to e-mails?

First few days were great, i managed to get $500 (20%) dollars quite quick and i could already see myself gathering enough funds to make the game a shiny pixel art gem i always wanted to make. Alas, upon further inspection, i realised that most of the backers were either my friends and few twitter followers. Only 23% of funding came from direct IndieGoGo traffic. Regardless of that, i was under (false) impression that the funds will keep on coming.


Then donations began to plummet, and 10 days into the campaign i started receiving $0 per day. It was too late to start contacting streamers (woovit page with hundreds of them is still open in my browser) since most of them have really busy schedules and i don’t think they’d find the time to include my game until the campaign ends. I could extend the campaign duration to 60 days, but it would be unfair to all the backers to withold their money for another month when i’m certain i wouldn’t manage to collect another 80% of the funds projected to finish the game. Flexible funding was not an option since i would tie a noose around my neck to follow strict deadlines i imposed and some stuff that really takes time (like Galaxy Database) and not gather enough funds to keep those promises.

Some further analysis showed that i had 238 visits from USA/UK/Germany combined and only $25 pledges combined from those countries, which probably means they had the interest in seeing what’s it all about, but they were either not attracted enough or they though that the game’s never going to reach $3000 so they never pledged. It’s easy to theoreticize now, but if the goal was $1000 and each of those visitors gave $5, the campaign would have been a success.

Mistakes i’ve made

My biggest mistake was setting the bar too high. As you know, backers are turned off when they see the goal is too high to reach. I should have opted for something like $1000 which was attainable and then keep gathering funds via InDemand program.

Not giving enough importance to mailing list.

Not making a good enough teaser (it is ok, but it can be a lot better).

Not contacting streamers before the campaign start.

Starting campaign too early, the demo i released obviously had too many bugs and i don’t have a big enough community.

Overestimating social media. Twitter likes don’t translate to pledges (and won’t translate to sales too i reckon). After all, most of the followers i have over there are gamedevs themselves and need money for development too.

Not including Facebook into the campaign (personal bias, shouldn’t let that affect business).

I didn’t make proper and regular updates to the campaign and i haven’t made a roadmap of campaign updates.

I didn’t make a break before finishing the campaign and pushing the start campaign button, i was EXHAUSTED and i didn’t have the strength to keep pushing through a month of active work on campaign to get more backers.

Things i learned

Making mistakes is good, and even an unsuccessful campaign is a good marketing,  i received quite a few publishing offers based on exposure campaign has made.

You can’t rush things. Game entered fourth year of development and i was getting impatient. Big mistake, the game is ready when it’s ready, not after being too long in development.

Managing my expectations. It’s quite easy to give yourself a false impression of things biased by what you think that will and should be.

Of course, the game will keep on developing, but i will have to find another source of funding, probably via publisher. Also, i would like to use this opportunity to send a big THANK YOU to everyone supporting me, see you in Early Access!