Creating the soundscape

In addition to being a programmer for the game, I was also designated Lead sound. While I’ve been mostly focused on the coding, I’ve also tried to think about what the soundscape of the game should be. I have some slight previous experience in making music and soundeffects in a program called sunvox, which is a tracker (modular synthesizer with pattern-based sequencer).

The Sunvox tracker

I wanted to make sure that all sounds in the game where consistent for everything in the game, so I tried to make a small set of instruments to use as a base. Then, I used this small set of tools together with some small effects to create some diversity in the sounds while keeping them consistent.

An example is that I’ve used a noise generator pretty heavily (to the point where I’m a bit worried that I’ve over-used it), and then adding slight reverb effects and such to make them different. That way, the sounds of the Vines dissapearing follow the same theme as the worms rumble, but they have a distinct difference.

When designing the background music, I experimented a lot to create a sound that sounded mysterious and wondrous to match our aesthetics goals of the game. Then, for the Win and Lose music, I used the same Instrument, but built a more happy/victorious sound for the Win-music, and a dissonant sound for the Death sound.

Especially for the Lose sound I feel I did well, the dissonant background music together with the sound of wings fluttering off into the distance (again made with the noise generator), felt really good. Since it uses the same instrument as the normal background music, it can be used as a fade in when the player dies.

All in all, I’ve not worked quite as much as I should have on the sound part of my duties, but in the end it turned out well. I’ve definitely learned a lot about sound design and also more specifically the program SunVox. I feel a lot more confident in being able to produce at least adequate sound effects and music from scratch.

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.

The Adamite engine, first groundwork and laying out future plans

the current vague plan looks a bit like this:

This blog is here to document my thoughts and my progress on projects I’m making. The first such project is creating an engine for the course “game programming in 2D”, which I’m currently doing at the GAME education on Uppsala University, campus Gotland.

In the course we’ll be using C++ and SDL2  to create a game engine. I’ve chosen to not follow our course director Jerry’s design, which uses raw-pointers and new-delete architecture. Instead I’ve decided to keep to what we’ve learned in earlier courses, and use proper encapsulation in classes with constructors and destructors.

To that end, I’ve started out by taking an earlier architecture that we created in the first programming course, and adapting it more to my style while also using precompiled headers, which we did not do in that course:

(commit 5204386)

Some changes I’ve done to what we did in the earlier course is that I’ve clumped the renderer together with the Window class, and made them into a RenderWindow class. This is mostly out of convenience since I can’t see that I’ll be needing several renders in one Window at this time, and if I need to change it, I can still keep the RenderWindow interface the same, and just factor out the Render functionality into it’s own class.
Another change is that I use precompiled headers, which Jerry is using in this course, but we didn’t use them in the earlier course.

Looking forward, there are a number of things that need to be thought out and implemented, but the current vague plan looks a bit like this:

  • Make a SpriteManager, Sprites, and later on animations of some sort, probably based off of code I’ve seen from one of my upperclassmen.
  • Make a Soundmanager.
  • Make some sort of Entity/GameObject hierarchy, my current thinking is that I’ll create a Component system where I have two abstract interfaces IComponent and IGameObject, where the IGameObject holds a list of updateable IComponents and iterates through that list each update.
    The main problems I’ve thought of with this is how to manage the communications between Components.
  • Some form of decoupling between each domain, my first thoughts were to copy the SDL/SFML Event structure of having a class that contains a type enum, and a union of data structs, which holds the data for whatever event has occurred. However, seeing the ServiceLocator Pattern used in the lectures, and later researching it more, made me interested in trying to use that instead. This requires some more experimenting and thought before deciding.
  • Since SDL doesn’t have it’s own time handling system like SFML does, I’m thinking of trying to use std::chrono for handling time in my engine, but I need to research how it works more first.
  • Loading of files, both for textures, sound, and for my own objects. As I’m thinking of making the game tilebased, a way of loading maps (made in TilEd, for example), would be great. Also being able to specify animations, enemy data, build specifications that can be used in ObjectFactories for example.

Looking at the game I want to make, it will be a Rouge-like, probably tilebased (using TilEd), and based in a post-apocalyptic future where rouge AI’s have killed off most/all humans. The player will play as an AI robot which at the start of the game has just gained concsioussness, and has no idea where they are, or what to do.
I’ll create some “main story” hook, but the ideal setting would be similar to the bethesda rpg’s, where the main story line can be almost entirely ignored in favor of just exploring the world and finding cool stuff and events.

This page probably needs some editing still, but I want to get started coding now, so if this message is here when you read this post, I never got around to editing it =P.

Edit1: I did edit it a bit, it’s a bit messy, but I think I’ll leave it as is, because I could be writing code instead of editing blogposts =).

(Why adamite? it looks cool, and it’s a mineral that begins with an A: