Spatial Partition-ing

Recently, I was given the framework for a unity project that creates a white circle on a black background. It ran and printed out how long it took to print out a set amount of said circles. The goal was to use some form of spatial partitioning to improved the efficiency of the program.


Ultimately I decided to use the grid method, as it was a fairly simple problem and I didn’t want to over complicate the problem and use a quad-tree, although I am well aware that it would have made the program even more efficient than my end result.


I started by creating the grid itself, iterating over the grid to give the cells correct width and height and than adding each circle to its own spot within the grid. After doing this I lowered the run time from 10.4 to 6.0, so its not far from being 50% more efficient. As mention above, I am sure that if I used a quad tree it would have been even faster but since the goal was to reduce run-time and not to make run-time as fast as possible and how the grid method is generally easier to implement than quad tree, I decided grid would suit this particular task.

“Where the Heart is” Post Mortem

“Where the Heart is” is the final project of this trimester. It was a team project that I worked on with another programmer and two game design students, as well as a number of animation and graphics design students. Ultimately the game went well and the whole team was prepared to showcase the game at a gallery a few weeks ago, where it was well received by those who came to play it.


Where the Heart is tries to capture the feeling of being at home, a feeling that myself and my fellow game dev students decided was felt the most when first moving into your place. To begin with, the player moves into their own bedroom as a ten year old and as they move through the game, they move to various houses that represent various stages in a persons life, for example, the uni share house and the retirement home.


What went right

I can’t write a blog about this game without mentioning how amazing our collaborators performed. I would like to say that this is because of how early we established contact and sorted out exactly what they need from us as developers and they figured out exactly what we need from them as animators/graphics designers, but I can’t/wont take credit for the collaborates very solid work ethic, so I’ll say that the communication definitely helped, but ultimately we hit the jack pot when it came to having the right people.


To imitate this in the future, I will make sure to ask around as soon as possible for collaborators because the ones with the best work ethic are likely to try to start working on something as soon as they are asked, so I’ll try to get to them with a solid idea before another team does. I will also try to maintain the same level of communication that I did in this project. Slack definitely helped with that because no matter when someone had a question, they could post it to the slack where I would see it within a day and confirm a response with the other game devs and give the collaborator a response.


Another thing that went right was the amount of work each team made did. At the end of the project we had all agreed that it was our best experience with group work we have ever had. I would this is largely because of both communication and how quickly we planned out the project using the Hack n Plan website.


In the future I will certainly make sure planning and documentation is done asap to make sure everybody knows what they have to do throughout the project as early into the project as possible and make sure people are made aware of the work they are expected to do.


I would also like thank my team for staying on task when I had to take time off due to the loss of someone close to me.


What went wrong

As mentioned above, I had to take time off due to a loss. It was just something I had to do do or else the few things I did to would have been terrible. Unfortunately, this resulted in a few of the things I was working on getting cut, which was reasonable as when I got back there just wasn’t enough time to complete them.


Death is unavoidable and unexpected, so it cant really be planned around. The best I can do is in future projects, aim to get my work done earlier than its suppose to be done, so that if life does get in the way, it wouldn’t do as much damage to the team.


Finding a Path

This week in uni we talked a bit about path finding, mostly A*, and were given  the task to update our bots from the tournament to be able to navigate a maze while still performing the functionality necessary to defeat the other bots. Deciding to cut my losses with the bot and try something else, I decided to create a path finding script using C# in Unity.


To this, I would start by creating a small, maze like, map with invisible nodes all over it. Then using a cube as the “player character”, create a script with a public array of game objects for the invisible “nodes” that would be iterated over comparing the distance from each node to the player and then from those closest nodes check which one is the closest to the target position.


Before even starting, I’m pretty sure I’m over simplifying it. With this current method, the script doesn’t have any idea where the walls are, or how to react if a wall is in the way. More research will have to be done before I am able to complete this project, so that I am able to learn how to sever a connection between two nodes, so that the player will never be able to attempt to travel through walls.

The Bot Tournament – Post Mortem

As mentioned in my previous blog, my intention going in was to make a bot that focused heavily on bullet dodging, with stat allocation weighted into movement speed.

In theory the faster I moved, the harder it would be for people to hit me and the easier it would be to dodge bullets.

As is the case with most project work, my ideas changed as I went on. With the time frame I had and the other commitments I have made, I had to simplify what I wanted. I threw out the idea of bullet dodging in the hopes that my movement speed would be enough to avoid most hits. Unfortunately this was not the case.


Movement was done by having the bot select a random spot somewhere on the map, moving to that spot and selecting another spot. Aiming was done by searching around the bot until a target was seen, shooting and then checking the same spot. If the enemy bot was not in the same spot, it would go back to scanning around the bot. Unfortunately, as the bot was shooting dead ahead every time, the accuracy was poor.


My bot, Russell Crowe, came 8th out of 12, which is okay but definitely not as high as I would have liked.


The biggest issue I had was with time management, I had committed to too much before uni had started and unfortunately somethings overlapped so that when uni came around I didnt have enough time to do as much uni work as I would have liked.

Studio One Post Mortem

Yet another Trimester down, and what a better time to reflect on my work.

I enjoyed Studio One. I learned a lot of things about the process of creating games that are really going to help me be the best game developer I possibly could be. That being said, I don’t think I was the best I could be. The following will be things I think I did well, and where I failed.

The Good

I’m very proud of the last two projects I did. I found both Darkest Depths and Transmutation to be games I thoroughly enjoyed both making and playing. I definitely felt like I improved as a developer over the course of these creating these games. During the creation of Darkest Depths I put myself outside of my comfort zone in regards to game design, and I confident that I’m a better designer because of it. I’m a lot more aware of design decisions that need to be made and a lot more confident in my ability to make them.

Being better at design will, ideally, result in better games and at the very least help me ask the right questions when faced with a design issue.

In Transmutation, as I mentioned in that post mortem, I became a lot more confident in my abilities as a leader, and my abilities to keep a team organized (although there is still room for improvement).

Continuing to improve my leadership abilities and group organization skills will be very hand in the future, whenever I am working on a team that doesn’t seem to have any project leader I will be confident in my abilities to step up to the mantle.


The Bad

As I mentioned, I feel like I let myself down. I didn’t achieve all of the learning outcomes required of me, such as the audio and 2D assets. Sure, I did lose a bit of time due to “life getting in the way” but that won’t stop and working in the industry life getting in the way isn’t going to change impending deadlines.

In the future, if and when something disrupts my workflow I need to make up for lost time. By using google calendar I will allocate time to update my schedule every Sunday and Wednesday so that if something does disrupt my schedule, I can re evaluate my current schedule if need be. I will also make sure to allocate extra time for project work throughout the week, making using of my nights (as that’s when I seem to be the most productive), so that if at any point throughout the week I’m not as productive as I usually am,  I have a chance to still get done an amount of work I am happy with.


What I Should Have Done

Below is a list of learning outcomes I did not meet, and what I should have done to meet them.


To meet this criteria I should have done more tools development.

I was given the opportunity to work on a 3rd person camera, which I didn’t utilize. I’m sure if I asked, I could have also helped contribute on the clutter generator or the sound controller or at the very least tried to think of another major thing every game uses that I could have developed a tool for.

Specific Skills

To meet this criteria I should have been more conscious of how I am scripting.

Knowing I have these learning outcomes, I should have been more aware of finding ways to do the functionality I am trying to achieve, and designating time in a projects creation to evaluate and improve on existing functionality to make it less hard coded and easier to use.

2D & 3D assets

To meet this criteria I should have contributed more to the creation of visual assets.

This would largely have been a factor of not scheduling my time properly. Again knowing that I have these learning outcomes I should have planned out how I could have achieved these in a way that’s relevant to the creation of one of my current projects.

Audio: Iteration

Although I did achieve the LO for the design and placeholder sections of audio creation, I didn’t achieve the iteration part. I should have iterated on placer holder audio, so that even if a team I was on didn’t end up achieving the audio we wanted from outside sources, we still have have had audio of a decent quality.

Process: Iteration and Post Mortem

This is most likely an example of not recording my work properly. I was apart of every team session in all of my projects where the idea of the project was altered, but I guess I never recorded them in my progress reports. The problem most likely extends from the method I used to report tasks for the majority of the trimester, where I would report all my tasks throughout the week at one time. In the future I will be more cautious with how I report my tasks and report them as the tasks are finished.

As for post mortems, I need to improve on how I wright them. Instead of talking about what went wrong or right, I need to cover why it was good or bad, what was the cause of the issue and how I can attempt to replicate or prevent it from happening in the future.


As mentioned above, I need to iterate on documentation a lot more, making sure that any changes that happen to the idea, happen to the documentation so that it always stays relevant. I also need to include an art bible in future documentation so that the game looks the same way as the team collectively imagines it and so its easier to communicate with animators on exactly what we want them to create.


and last but not least, I need to blog more. On my weekly schedule I will allocate at least an hour per week just for blogging. If any extra events happen (such as future exhibitions) I will allocate an hour per blog at some-point within the fortnight at the latest. This will make sure that I have time within my schedule to blog, rather than the generic tag of “uni work” and making sure that I do it at least once a week should stop them from piling up and if they do, I will have time to separate the blogging sessions to make the workload more appealing.


What I Will Do

The major difference between this trimester and main trimester is going to be the severe increase in planning. This extends past just scheduling, but figuring out what LOs I need, how I can achieve them and deciding what LOs I will work towards achieving in the current and future projects in regards to A) What I would like to achieve during the project and B) The minimum LO progress that I want to earn during the project (In an attempt to apply how I deal with the scope of a project, to the scope of the entire trimester)


Transmutation Post Mortem

Last Friday I finished up my final game of the trimester and I am very happy with the results. I worked alongside two of my fellow students to create a game that had three separate player characters that could only be controlled one at a time and was set in a restaurant. Through brainstorming and iteration we finally came to the group of ideas that resulted in Transmutation.

Transmutation is set in the canteen of a nuclear facility that is currently in a meltdown. The player must control three characters and try to survive the onslaught of mutants as they wait for the elevator to reach their floor so they can escape. As each mutant is killed, they leave behind radioactive goop that lights up the otherwise dark room and can/will kill the player characters.


The Good

As mentioned, overall I’m happy with what my team and I got done. I thought we worked well as a team for the must part and achieved something we can all be proud of. Personally, I’m also quite happy with myself for stepping up and taking a leadership position on this project.

Multiple times a week I would set up a list of things that needed to be done by the next class and making sure my team was aware of what needed to be done, why and if they had any suggestions to the schedule. With every idea the team collectively came up with, I also made sure that every team member had their input on the idea.

Having someone to keep track of what tasks were done and what needed to be done was potentially part of the reason the team as a whole managed to get so much done. It would have kept things organized and avoided having anybody sit around wondering what to do, or waiting to be told what to do.

In the future, if a team I am apart of seems to be lacking some kind of leadership, I’ll be much more confident when it comes to stepping up if need be and keeping the group organized when it comes to scheduling and milestones which will greatly contribute to the quality of future projects.


The Bad

Unfortunately, we made the cut off date to receive assets from our collaborators way too late, and so we didn’t manage to get all of their hard work in time for the deadline, which is very unfair to them.

This was likely because there was a lack of communication in the team regarding the collaborators, which lead to the due dates given to the collaborators not being ideal in terms of content lock before a milestone.

To avoid this in the future I will make sure all collaborator conversations are somewhere where they can be seen by the whole team, such as Slack or Discord, so that any team member who wishes to communicate with them can.


Another issue was the lack of updating documentation, in disregarding it for the most part once the team started the project in Unity. Without documentation, we definitely hindered ourselves in regards to how much we could have gotten done.

Looking back, I think the documentation process was rushed. We filled out the HCD, GDD and TDD to a include what we thought we needed at the time and to a level we were happy with, but it was never updated to include things we decided to add after iterating on our design. Once scripting started, by looking at our code its apparent that the TDD was never referred to, which would have contributed to the overall messiness of the code, which made it a lot more inefficient than it could have been, hard to find variables and functions that were needed.

In the future I will personally hold myself accountable to look at the documentation relevant to the tasks I am working on at the time, and constantly remind me team to look at documentation, especially in regards to scripting, to make sure that things are being created as we had already planned them out, which would remove any and all guess work and increase the teams productivity. I will also make sure that relevant documentation is updated as necessary so that any information people need will be in the documentation.


Darkest Depths Post Mortem

A few weeks ago I finished up designing a board game with two of my fellow students called Darkest Depths.

The board game involved 3 players having to work together to beat a boss at the end of the game, however, only the person who beat the boss at the end was considered the winner. Ideally we wanted players to work together to an extent, but still make conscious choices to screw other players over so that they don’t win, but not so bad that the whole team loses.

As a programmer, I was kind of unsure of how I could contribute, but eventually I managed to get pretty good at the design aspect of game development (in my opinion) to the point that one of my team mates would jokingly say “You’re such a designer” whenever I gave feedback on something or presented an idea. I enjoyed the process of designing a game (even though I missed scripting) and I definitely feel like I learned a lot about design that will help me with future games.

What Went Right?

I tried doing things I wasn’t entirely comfortable with. In the past I have had little to noting to do with the design of a game, so this project was initially off-putting, but still tried and eventually I was comfortable with helping design the game. So the first lesson I would take from this project is to try new things. In regards to code, this would mean finding new ways to implement systems I have done before or trying to do functionality that I haven’t done before. In regards to game development in general I will continue to apply myself in the design aspect of the project when I can.

What Went Wrong?

The project was over scoped. To get the desired gameplay we wanted we would have needed a lot more play testing than what we had. I wouldn’t say that it necessarily means we needed more play-testing sessions (as people showing up on their own free will was quite rare and more a case of an entire class being told to go play test during class time), Its more a case of needing to be more aware of what the team would be capable within the time we have and with the resources available to us, especially in regards to player emotions. For future projects I will make sure that projects with a shorter development length have simpler ideal player emotions and behaviour.

Overall Im pretty happy with the project. I think we made something thats was fairly well received during play tests, even though I don’t think we quite reached the level of “Co-opish” that we were trying to achieve.

What I Want To Be When I Grow Up Part 2

Since my previous blog about what I want to be when I grow up, I’ve been looking at more of what a gameplay programmer does and how I can go about trying to get a job as one. 

In January 2014 Anna Ljungberg, who was a gameplay programmer for Codemasters at the time, did an interview with Develop about what developers look for in people applying for becoming a gameplay programmer, and what her job role is with Codemasters.
To begin with, Anna says she is currently working on the camera system for a title that’s in the works, but confirms what I have read a gameplay programming as she continues to say she works on “All game-related tasks as required.”

When it comes to getting a job, Anna recommends not only to know how to program and how games work, but to prove that you can do it for a living by doing stuff in your spare time to prove that you are committed and interested in making games.

When looking for someon for her team, Anna said she looked for people who are enthusiastic about about making games and the knowledge to make one. 

Finally Anna says that the thing she enjoys the most about being a gameplay programmer is the opportunity to further her knowledge in multiple fields and the opportunity to specialise in a particular area and become an expert in those fields.
That last part in particular basically sums up why I want to be a gameplay programmer. I’m excited by the idea that I can get better at multiple fields and if later in my career I decided that there is one thing that I really like doing, then I can advance my knowledge on that field and ideally work on just that component.

Ball Ball Self Evaluation

The blog will be about how I feel I went with Ball Ball, specifically where I felt I did well and where I can improve and what lessons I will take with me into my future projects.


What I did well:

As mentioned in the post mortem blog, I felt my communication with my team mate was very good. We would both constantly update the other person with information like when we are working on the game and what we are working on, and ideas for how to fix any issues that might occur. I will definitely make sure to continue to keep communication with team mates in the future.

I also tried to do things I haven’t done before, such as using a line renderer to track where the mouse is in relation to the ball after the ball was clicked and the mouse is being held down, and I iterated over code so that it would perform the same function but in less lines of code or slightly more efficient. In the future, I will definitely push myself to try new things in my code, as its the only way I’ll get any better at programming. I feel that iterating over my code is also a very good practice to get into.


What I did not do well:

One area I felt I was lacking was definitely the amount of work I did. Although the project did get to a point we were both happy with, my team mate did most of the work and I definitely could have done more. Life getting in the way was partially to blame for a small portion of the project time, but it was mostly just me finding it to get back into the swing of things after the holidays (I have already regained the drive to do lots of work), which is in no way a good excuse for not doing work. In the future I will make sure to allocate my time better.

In conclusion, after identifying the strengths and issues with my work ethic over the previous project I definitely feel ready to work harder in the future and improve my work ethic.