Getting more organized

This week we’ve restructured almost the entirety of our project, and cleaned up a lot of code and assets that were not needed/badly organized.

After a while, assets start piling up, creating redundancy. This can lead to wasted time (while searching for the right assets from perhaps five similarly named yet different assets) and space (obviously). While it takes time to do the cleanup, it eventually gets to the point where it is more efficient to do the cleanup than to leave them be.

How to do the cleanup? It’s simple. Find and delete all un-used assets! Since I’m the programmer, I focused on code cleanup. Any code that wouldn’t be used at all was deleted. Anything with inefficient code was re-coded, keeping the useful parts, deleting the parts that weren’t used, and changing the parts that can be better coded.

To do most of the cleanup, we decided to create a new unity project and move everything over bit by bit, making sure that everything works properly at every step, and then cleaning it up afterwards.

While doing this, we noticed a number of small inconsistencies that were fixed, and we got a good overview of our game design as well. This made us realize that we needed to change some things around to make sure that the game was actually engaging, which was great.

Something we noticed while reimplementing the movement and shooting mechanics of the moth, is that we really needed to redesign it. We started with thinking about what we really wanted out of the mechanic of shooting. We realized that we probably needed mouse aiming for the shooting.

I implemented the mouse aiming by first getting a direction vector by using vector subtraction of the mouse-position with the players position:

Vector Subtraction (for real this time, thank you, Sill)

You get the direction and distance between two points (defined as vectors) by subtracting one from the other.


I then normalize that vector, which sets it’s length to 1. I do this so that when I multiply it with the bullets speed later, it will have a consistent speed.

I then spawn an instance of the projectile object with that direction vector as the velocity for it.

Improving the light conditions (Light Plant, part 2)

As I talked about in my latest post, the Light plant is one of the Enemies/Puzzle mechanics in our game. It’s projectiles provide light, but are also dangerous to the player on touch, so they have to be avoided.
This week, I’ve added two new behaviours to the plant, “angry” and “activation”. These two are the main mechanics that this plant will have to create interesting puzzles.

The angry behaviour

When the player hits the plant with a projectile, the plant will mark the players current position as of being hit, and will then shoot towards that spot with a higher fire rate for a short amount of time.

This was done by having the player variable as public in the script, so that a reference to the player GameObject can be added through the editor. When an object tagged with “projectile” enters the plants hitbox, it will destroy that object and set the plant in “angry” mode. I use the WaitForSeconds coroutine method described in my earlier post to stay in this mode for a set amount of time. When the coroutine ends, it resets the angry flag, making the flower return to it’s normal passive mode.

The activation behaviour

An inactive Light Plant will currently just wait to have an object tagged “LightProjectile” enter it’s trigger-collider, and will then set itself to be active, behaving as any other plant.


Using this mechanic of “aggroing” the plant, together with the “activation” mechanic will be one of the core dynamics in our game where the player uses light in different kinds of puzzles.
An example of such a puzzle is what we are working towards in our current prototype, where the player first needs to navigate past a Light Plants default shot pattern. After they’ve done this, they will proceed into the next area only to notice that it’s too dark to proceed. Using the taunt mechanic to make the plant shoot into that dark area will reveal another plant in that area which will react by activating itself, providing further light.

A dark corridor, not yet lit
After aggroing the plant, there is now a lot more light, but also more danger.

Next steps

After this, there is not too much to do on the actual plant. Moving further we will focus more on interactions with the projectiles, and also with other enemies. There is also some work needed in making sure the level design is correct. We need to have good pacing, while making sure that the player understands a mechanic on a basic level before building more complex puzzles involving several different mechanics.

Making a Light Plant

This week I started work on a new enemy, and a new mechanic for the game. This enemy is a flower that will sit on a wall and shoot projectiles that provide light, but are also dangerous to the player. The projectiles will also be used later in different puzzles that will interact with them in different ways, opening pathways or providing more light.

The plants themselves will also interact in different ways with other projectiles and the player, but these mechanics still needs design work.

Making the plant, I started out with drawing a quick sketch of how the code layout should look, and then proceeded to implement it in steps. I first created a prefab for the projectile, testing different lights and collisionboxes to see which would work best. Then I created the actual plant, which really is not much more than a sprite with a trigger collider and a script. The plants script was interesting to implement, to begin with I just instantiated a projetile, adding some force to it, which worked nicely. But then, I had to make it shoot on a timer, which took a good while to figure out. I used the inbuilt function WaitForSeconds(), which works using coroutines, which I did not know how they worked in Unity (well, technically, in C#). I learned a lot about how to use Coroutines with timers, and while I think the final solution I came up with is a bit brittle, I think it will hold well through the development of the game.

This plant will be a part of our main core mechanic, so making sure that it works well is imperative.

Node Based movement of Enemies


I have been working on a system for node based movement for enemies. This makes it so that an enemies path is decided by putting out Game Objects in the scene called nodes. When an enemy has two or more nodes it will then move between the nodes in sequence at a set speed.



The script first makes sure that enough nodes are in the array for movement to work, otherwise it logs an error. If there are 2 or more nodes in the Nodes array, it first sets the position of the enemy to the first node in the list, and then sets the second one as the current target. Then I use the Vector3.moveTowards() function to move towards that node. When a node is reached, I increment the current target index, using modulo over the array length to wrap around if at the end, and then set that as the next target.


Before this, we had to make each enemy individually, with different scripts attached for different kinds of movement. I wanted to generalize the code for the enemies more, and after a bit of thought and some testing, I designed this node based system.

This way, making complex patterns for an enemy to move in is as simple as putting all the points of that path out into the editor window, and then dragging them all into the scripts ‘Nodes’ array. This makes testing of different paths a lot easier and faster, which makes testing different patterns faster and more approachable. Having this system removes the task of coding from the task of game design, so that they can be improved in parallell instead of being dependent on each other.

Moving forward, I have looked at how to make the movement and curvature of the path smoother withouth having to “spam” nodes. Another related thing I would like to do is to add properties to the nodes which affect how the enemies move to the next node, such as acceleration, subpatterns like moving to the next node in a wave patterns and so on. For the alpha however, this is enough to start testing which patterns are interesting, and which additions to the nodes that would be most interesting to implement next.