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.

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: