Self Reflection on my creative goals


Creative goals

My creative goals over the last 3 months have been the following 4 projects:

Killbot tournament

This was the killbot tournament that was laid out to our class at the beginning of the trimester. There were two sections, one focussed on target prediction & accuracy, and one focussed on pathfinding. I came 4th and then 1st, and I am very proud of having done so well.


This was a side project I pitched near the beginning of the trimester, as a project that was designed to show off an animator’s ability to create models, textures, and animations for use in a game engine. The project would also be set up to allow for as many animators to build for it as were interested, so it became an endless runner, that randomly spawned in sections of road and obstacles, and the animators would only have to create about 7 separate models, one being a skinned character. These would swap all swap out, to show off another animators work. Their goal was to make a model look as good as they could without causing drops in framerate, so a model with a low to medium poly count, but with high quality and detail textures, including maps for the PBR standard shader in unity.

I Remember

In this project, I was 1/2 of the programming team that were ‘contracted’ out to build this game for a team of designers. This was our first experience in having tasks given to us without really understanding how it was meant to all come together, and this project went through many iterations, so we ended up doing our best to make our scripts as modular as possible.


This was the CIU project I worked on. Its design was to be an interactive experience describing a possible future incorporating transhumanism and corporate control. I worked on it with and animation student and a film student, we worked out the design as a group and I did the programming for it.

The things I did well


I did have plans or desires to work on more things, however, the projects I did work on were completed on my end because they were scoped fairly well, and were easily reduced in size when necessary. I completed my final killbot about a day before it was due, and was able to switch my focus on to my side project, which was scoped with a scalable amount of animators in mind, and very much treated as a side project (read: the first thing to be thrown under the bus). It was still a huge project, being almost half a gig in size from the audio files and models, and there were only a few people who ended up providing work.



The three projects that I took a design lead in went very well. The killbots were pretty simple, but there were three things I implemented that helped me win. The first was the importance and use of capturing data on the stats given to the bot, to identify the most useful stat build for my bot in particular (this was even useful for the bots of others, increasing their win rate by about 50%). I also chose to cover up my lack of perfect accuracy with a burst fire strategy, to increase the chance of hitting my targets, which increased my win rate immensely. I also chose, in the maze, to have my bot only scan in its cardinal directions, greatly increasing my chance to spot a target, these three things combined brought me victory.
I was able to design a decent game out of the need to display many people’s work in Supersprint, with the ability to have a scaleable amount of animators working on the project (including accounting for any that would drop out half way through).
I worked very hard on the design for overclocked, in helping polish up the main ideas we had for the game, helping figure out how to best use every team members abilities effectively and getting the team to get the work done on time, including rescoping the project and redesigning it to fit the theme still, or create an even more meaningful experience out of it.



The most major things I did right in programming was learning how much I already knew about it, like how to reference and dereference in c++, something i was struggling with when we were first learning about it. I was also doing really well with planning out a project and its programming requirements. While not under stress, I was able to plan out a project with Rohan, and we coded together, making our scripts very accessible to each other, full of notes and easy for each other to use.

The ways I have improved

Seeking help when needed:

This was very important during this tri, as there were a few times when my efforts would have failed had I not sought help. Both Greg and Iain helped me out with some very complex scripting, something that only took them around an hour, would have taken me days to work through, something I didn’t quite have the time for. I was also able to receive help from my peers, like Harry for help with design questions, and Rohan and Chris for audio implementation when I started the endless runner project. Chris and Rohan ended up working on the endless runner with me, which was extremely helpful, I would not have had a hope of getting the project done if I had have had to do the audio system for it as well, not to mention I wouldn’t have been able to implement a solution as elegant as his.

Running a project:

I did run the project, though, and it is complete. I would have liked to have been able to get more work time out of more people, and had more model sets completed for it, but that can’t be helped, the animators especially had a lot on their plates this trimester. To have had so much work done by everyone is impressive all the same. While I have successfully worked on projects together with teams before, this was the first project I completely headed myself, I am certain I have grown better at it.

Working with others in code:

Previously, my code has been difficult to decipher or use by others, it has been very ‘thrown together’. While I’m still not very good at avoiding that, especially while stressed, I am getting much better. I have identified the extreme usefulness of planning out a project, like with the use of a TDD to identify how certain processes and functions will interact with each other.

The things I did poorly


I was lacking in motivation for the entirety of this trimester. There were times where I needed to start work but wouldn’t for the entire day, and this would stretch on for a couple of days. I still worked hard enough to get my work done, the essentials, but I wasted time that could have been used to practice, research or create even better things. If I had of had the endless runner completed earlier, it may have convinced some more of the animators to complete their work.
I often feel very tired for little reason, or get distracted by games or facebook easily, and I need to work on finding my focus quicker.


I barely did any research for anything that wasn’t immediately essential this trimester. I know I can find any information I need as it arises but I have a problem with just looking up things for fun, in my spare time. This means I’m usually not learning much more than what is presented to me in class, and don’t just rock up with brand new information. I am trying to fix this by getting into projects that would require me to do things I don’t already know about, like displaying video streams in unity, and setting up dynamic audio tools or text display systems (in overclocked and I Remember). I will continue this trend over the next trimesters.

I barely touched shaders:

One of the main topics this trimester was to play with shadertoy and create our own shaders, getting used to using the language, and working around there being no switch statements, or it not being able to hold up and wait on other sections of code to complete. I get the idea of how that works, but I didn’t make any shaders and need to spend some of my own time working on them, especially if I ever plan to be a tech artist.

Identification of a failure in project management:

Once again, this trimester I decided to step back and let the designers design and run the project, and this meant that even though I could see that the project was a rolling dumpster fire from the beginning when it came to project management, I failed to do anything about it to ensure the project got back on track, until it was almost too late to do anything about it. The project suffered heavily for it, and although it was completed, it is a shadow of what it was meant to be.

How to avoid those in the future

Be the project manager:

From here on out, I’m going to try to be the project manager whenever I can be, so I can get as much practice in being one, and to force myself into learning how to best manage people while also taking a lead role in programming for projects. The only time I tend to get anything done is when I’m sure I am out of time to, and when I know that people are relying on me to do it, even to help keep them motivated to do their work. Leading by example is a great way to light the fire under your ass.



DED RECKONING, research and implementation

I previously spoke about ded reckoning in an earlier blog while I was working on the killbot for our tournament. Well, I won the tournament for the pathfinding section and came fourth for the target prediction section, but i would like to talk about the research and implementation of the ded reckoning system itself.


What is ded reckoning?

ded reckoning (or deduced reckoning) is used in navigation systems and is the process of calculating one’s current position by using a previously determined position, or fix, and advancing that position based upon known or estimated speeds over elapsed time and course.

Dead reckoning can give the best available information on position, but is subject to significant errors due to many factors as both speed and direction must be accurately known at all instants for position to be determined accurately.

This sort of system isnt often used for target prediction, because of the cumulative effect that errors will cause over time, however, if you only need to know where a target will be in a second or less, it can be very cost effective.

This is why it is used for dogfighting games, to display to players where they need to aim to accurately hit a target. Here is what they are displayed as in war thunder.


The reason it is needed for this situation, is the bullets have travel time, they will not immediately complete their flight path the second the trigger is pulled, so we must lead the target. However, this can be pretty hard to do, as judging distances from a screen isnt quite what our eyes are designed for. Displaying a simple, predicted flight path target for players to fire at makes the game much more accessable for every player.

What its doing, instead of using hard information to determine current position, it uses assumed information as well. It takes the current speed and direction and acceleration, the distance from the gun, and the bullet speed, and uses that info to decide, based on how long it would take a bullet to get there, how far ahead the player should lead the target to accurately hit them, and displays that position.


How did I use it for my killbot?


As we saw in the last post about my killbots targetting plans, this is what is happening behind the scenes. The killbot gets 2 scans of an enemy in the previous two turns. from this it can assume a speed and direction. (using three scans would have ensured complete accuracy though, which proved to be more useful as that is what won the tournament focussing on prediction). The simplest solution is to then determine how far the target is from my killbot, and how many turns it would take the projectile to travel that distance, and then shoot that many turns of the bots current predicted path ahead of it, however, the bullet’s travel time itself was not being taken into account for the new target. I has assumed that this would be ‘close enough’, but it was throwing my accuracy completely off. I could also not hit anyone who was always moving along a curve, but did not acocunt for this.
The problem with the bullets own travel time was that it kept adding more distance to travel for each turn it needed to travel. This looks a lot like Zeno’s paradox, Achelies and the tortoise:

So to account for this, what we need to do is, using the target prediction that we have, test to see how close the bullet will be to the enemies predicted path, for up to 60 turns, and once we find the closest that the bullet can get, use that angle. This means that the bullets travel time is now taken into acocunt. it still isnt perfect, but by including burst fire into the build, it made my bot a strong contender, coming 4th for the target prediction section.

Below is the block of code i used to converge the bullets path and target path as close as possible.

 for (int i = 1; i < 60; i++)
   tempMagnitude = ((currentPos - input.position) / i) + tempVelocity;

   if (GetDistVec2(tempMagnitude, checkVelocity) < GetDistVec2(bestMagnitude, 
     bestMagnitude = currentPos + (tempMagnitude*(i - 1)*0.1); 
 tempMagnitude = bestMagnitude;