REAL WORLD LIMITATIONS

 

Our minimum viable product for the game slime herder was the Samsung Galaxy Tab 3 Lite tablets that we have available for testing here at SAE. These have very limited resources available, like a low CPU clock speed, only dual cores and only 1GB of ram. This means that we cannot have any high-cost parts to our game. One large concern was the jelly-physics that we added to the slimes themselves that would affect each vert in the mesh of the object, and have them slightly slosh around, giving them the feel of a slightly fluid character. This could have caused an issue with the large amount of mesh transforming that this involved in every frame, and would heavily affect the framerate on a lower-end device.  To avoid this being an issue, we found someone’s solution for the jelly physics that had a relatively low cost to run, and stress tested it in the build environment and testing device as early as possible.

TECH SPECS for our test device

Processor

  • CPU Speed
    1.2 GHz
  • CPU Type
    Dual Core

Display

  • Size (Main Display)
    7.0″ (178.0 mm)
  • Resolution (Main Display)
    WSVGA (1024×600, 169PPI)
  • Technology (Main Display)
    TFT
  • Color Depth (Main Display)
    16M
  • S Pen Support
    No

Memory

  • RAM Size (GB)
    RAM 1GB, Storage 8GB*
  • ROM Size (GB)
    8 GB
  • External Memory Support
    MicroSD (Up to 32 GB)

OS

  • OS
    Android 4.2/4.4

Sensors

  • Sensors
    Accelerometer

Audio

  • Audio Playing Format
    MP3,M4A,3GA,AAC,OGG,OGA,WAV,WMA,AMR,AWB,FLAC,MID,MIDI,XMF,MXMF,IMY,RTTTL,RTX,OTA

    Our game needed to go through multiple hurdles to play correctly on the test devices alongside as many other devices as possible. The main things we did was reduce the play area size so visibility was not an issue due to small screens. We also had to hard code the aspect ratios, anchoring and camera positions to deal with screen ratios of 16:9 and 16:10, as not all phones and tablets are the same.
    We also needed to deal with the minimal resources and the large amount of functions running and limit the amount of checks that we are doing per frame. This meant putting a soft cap on the amount of slimes active at any point in time, and building messages to send off and trigger, rather than check to see if something is true every frame, where possible. Due to there being little to no 3D elements or light particles, we are able to save heavily on rendering cycles, something that is usually dealt with using integrated graphics in mobile devices, leaving more resources for simple sprite animations and particle effects.

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.

SuperSprint

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.

[over]clocked.

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

Scope:

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.

 

Design:

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.

 

Programming:

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

Motivation:

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.

Research:

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?

prediction

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, 
       checkVelocity))
   {
     bestMagnitude = currentPos + (tempMagnitude*(i - 1)*0.1); 
   } 
 }
 tempMagnitude = bestMagnitude;

 

never gonna be A*

 

A* is a computer algorithm that is widely used in pathfinding and graph traversal, the process of plotting an efficiently traversable path between multiple points, called nodes. It is noted for its high performance and accuracy.

How does it work?

This video tutorial goes through each step of setting up an A* algorithm, which will then need to be implemented into your project (for example, how do you use the list of nodes once it is returned or how do you identify impassable areas of terrain).

I am still working on implementing this pathfinding into my killbot, I have run into a lot of issues and am currently stuck on this:

The path that is returned seems to enjoy moving through walls, or the selected nodes to travel along are spaced very far apart (moving across wall sections as well).

I’m not sure this will be ready for the bot tournament, not unless I go without sleep, but I can’t afford that as I have 2 other projects due this week, and I’m leading a side project.

However, the side project is off to a great start. It is an endless runner designed to show off the capabilities of a whole bunch of animators at once. It is set up to have each team member working as much in parallel to one another as possible, and will have the capability to give credit to each artist as their work comes up, as well as allow control over things like the flow of time and camera positions. This week, I started recruiting animators, there are about 17 working on the project right now. We also chose the main themes that everyone will be working in, as shown here:

 

Those were chosen through voting, from a list of 20 mood boards, each submitted by a member of the animation team. Each member then got to vote for 5 different themes, meaning that everyone voted for their own board and then 4 other boards. These five were the most popular, so everyone got to have their say. Now they each get to choose one of these 5 themes to create from. The whole point of this is so that we can have background music and skyboxes that fit the models specifically (and I don’t have 20 audio guys to do 20 music tracks). I am extremely happy with the work that has been put in just to make up some nice mood boards and I am excited to see the work in its completion!

Meowder Mystery Post Mortem

Meowder Mystery: the purrfect crime is the result of our teams pivot for our Remembrance project. We were finally made aware that Remembrance was a terrible game that had only run into issues and would completely fail at its main objective, to make someone feel a connection. During a class, we had a lot of fun playing around with the idea of instead having the player control from the perspective of a cat, that would display subtitles for it’s meows. For now, though, let’s go through everything that went right and wrong during the production of this game.

What went right

Pivot
Boy did we pivot. Our game went from being a story about a father’s battle with depression and grief after the loss of his daughter, with the player being able to affect the trajectory of the father’s battle through interactions with objects in his memories, all wrapped up in a VR experience to a story about a cat who must uncover clues to solve the mystery of its dead or missing family through questioning and abusing inanimate objects, without any VR. This was made fairly simple by building the game around the assets and scripts that we already had available. Due to the general behavior of the scripts being very close to what we needed, a lot of the changes that we needed to make was the removal of a lot of the code and only had to set up a few smaller codes for things like the cat idle animation (when you are holding an object).

I really wish we were working on this game weeks earlier, this problem stemming from our team latching onto a single idea at the beginning of production. There was a mix of some members not being open to other ideas and not many other ideas being available (possibly from the first idea involving a hospital to explain the no player movement constraint) To help avoid this in the future, we really need to push each team member to create several ideas for the game and in a brainstorming session, go through each one, build it up and identify the best parts of it, then pick the best one and pull any brilliant parts out of other ideas and work them into the best one, if possible.

After that, there should be a way of getting outside perspective into the project as often as possible, to help identify any areas that are just not working, like playtest sessions. If any of the feedback hits on one of the areas that are in the core brief (like people constantly asking how we expect to make the player feel anything for the daughter, our main point of connection) then that may be a good time to pivot the whole game.

Do not fear pivot, it sounds like you have to start from scratch, but that’s not true. Many of the assets and scripts can very easily be repurposed into almost anything with very minimal effort. Trying to keep most or all these things in the new pivoted game is also a huge amount of constraint, which is very healthy to the design/brainstorm process.

Collaboration
This is something I went over in my previous post-mortem, before we hit pivot (found here), and went over in greater detail why our collaboration team worked so well (here). To recap though, I basically set up a cheap and nasty version of what was required for our production documentation for the collaborators and held skype meetings every night at 8pm, to ensure all the work required for that day had been done. To improve upon this should include bringing the collaborators further into the production process. I think this should be made as easy as possible for them, as a lot of time spent on figuring out these complex structures may discourage them from joining in, but I mean this in a ‘user experience’ kind of way, not a ‘don’t include them in the work’ kind of way.

Meetings
Our team mostly did a decent job at meetings, we got into regular skype calls and stayed online to help or support each other during production hours and to help ensure work was getting done and each member was on the right track with each task. It has been brought to my attention that these skype meetings sounded like a waste of a lot of peoples time, but a lot of development happened during these calls and they were also comforting. They tended to help people get work done and ensured that others were working. They allowed people to just ask any questions, as they cropped up in people’s head and also helped deal with any working blocks as soon as they arose. This also helped build a team identity, when work needed to get done, most members were more likely to put in their working hours when it felt to them that the whole team was doing the same, that we were all putting in the effort.

While this felt very positive, it is important to also make sure that our use of time is as efficient as possible. These meetings should have started off with a structure to them, for example, go over the work that had been completed since the last meeting and identify its successes or flaws and how to improve on them, ensure that tasks are being met and go over the next set of tasks that are due. These could also include a time for taking a step back on our project and taking a look at its current state. Is it still meeting the brief? are our time estimates still falling within the deadlines? are there any blocks or risks that we can forsee? Has anything cropped up amongst the team members that will shift the pipeline or timeline? Are any team members failing their duties and if so why and how can we fix it?

Better management
When we pivoted our game, one of the main issues we identified was poor leadership and a lack of availability from a few of our team members. Before the pivot, we were strung along with the completion of the production tasks, such as the Gantt chart and risk management. As a team, we failed to recognize that this was not actually being done and needed to be shifted onto someone else. There was also a large amount of sickness and other blockers in our team and with little to no management, this brought our production of our game to a halt. We did eventually get back on track, but our game was about a week or two behind where it needed to be, which we failed to really identify or act upon. After pivot, Harry and I took on the tasks of setting up our production and team management, also designing the pivoted game to be completable by the three people who were regularly available to work. We should have spent more time maintaining the tasks list and Gantt chart that was made up, but defaulted to reporting and assigning tasks over the skype meetings. These verbal task reports took the form of the ‘current three most important tasks until the game is done’ model, outlined in class, but followed the general task list set in the GDD.

This better management was able to take into account the needs of each member, like time to write their blogs, ask for expected availability and set tasks that should fit into that time slot.

The game was playable
This was due to the pivot of our game having a decent way of keeping the scope in check. We kept the ‘crucial’ parts of our game to a minimum and had as many non-crucial elements as possible. This way, if they did not make it in, the game was still playable. This should be taken into consideration right from the start of the project, as the only way to deal with a loss of working hours due to sickness or other risks is to use any flex time you have set up for your project, which is unrealistic as most people in the team will have to sacrifice other things like projects or home time. No one wants to be forced to work till 7 in the morning on a project because someone else couldn’t make it in. This way you can start cutting out the less important parts of a project and still be able to provide an MVP. If you do find you have extra time, this means you can even bring back in those non-crucial parts that were cut out, or even the extra stuff you thought wouldn’t make it in. This also allows you to structure and set up tasks for the project once MVP has been met, rather than lose your team’s interest in working as their work is ‘done’.
In saying that, you have to be able to create an MVP that takes next to no time at all to produce, in the off chance that you lose the main amount of working hours available. This is done by building up the idea of your game and then cutting back everything you can while still being able to call your game a game.

What went wrong

Time management and production
When we started the project, tasks were handed out amongst the team, and the project lead took over the task management job. A confusing spreadsheet was set up to use, and we were told to fill it out. This never happened and needed a full team meeting with direction on how to fill this out and needed to be kept up to date, most likely through daily meetings that went over these tasks, to identify what was getting done and what was missing. The team was soon struck with sickness and indifference towards the project and this was the last effort to be put towards the production management. After this our meetings were mainly focussed on arguing over design elements of the game and a couple of weeks in, we started working on seriously working on the documentation of the game, including taking meeting notes and setting tasks in those notes. It was brought to the team’s attention that the Gantt chart had not been set up, so we allocated meeting times to generate the task lists for the chart and were assured by the team lead that the documentation required would be set up asap. Not getting a deadline for this meant that we never knew when the task should be completed by and in our heads, all we could do is ask about it the next time we got a chance to talk. We did not want to do it ourselves as we were already overloaded with tasks and the production management tasks were a huge amount of work. It felt wrong to complain about it, as we were being assured that it would get done and the person who was working on it was providing other work also. To bring this up with Tony or Steve would be the same as stabbing them in the back as we didn’t know if it could adversely affect them.

I myself ended up spending way too much time into trying to make a VR device work on my laptop, to no avail. This was critical choice for our game, and had affected the way we designed the systems and the MDA of our game. Not being able to get this to work was very disappointing but was not removed from the game till much later and this possibility did not even make it into our risk assessment. If this task was managed correctly, it would have been a non-critical task and only had a few hours dedicated to getting it to work.

To avoid this, the main thing we need to do is correctly identify when a critical task is not being completed much sooner. Every task needs a deadline set up when it is assigned and this needs to apply to the initial production documents creation. This will allow to sooner identify a failure to complete and allow a task to be reassigned. The set up of a project needs to be treated so very carefully, as the last three projects have completely failed to get any production documentation like the Gantt chart due to someone or something falling through and no one else realising that it hasn’t been done until it was way too late for it to be of any use at all.
To help assist with this, face to face meetings and skype meetings should be going on for most of the early project, so the whole team can be a part of the creation of the game, helping avoid a team member not knowing what the game is and allowing task breakdown notes to be generated during.
Good team management is what is required for this to be completed successfully, described in this blog.

We also needed to maintain our production documents. This did not happen due to them not being set up until way too late in the production cycle to be of any use yet again, but I have seen this work correctly with the animation team task reporting. This worked as it was set up to allocate tasks, deadlines for each task was assigned by the individual who was creating the object, the document was dynamic, able to change to suit the needs of the users (adding in a task swap section so that broken down parts could be handed over to someone who was able to do it) and the document use was managed, due to going over the current tasks that were due each night. This exact setup with a Gantt chart will allow for its maintenance and usefulness. Setting up a Gantt chart at the start of a project will also allow for it to be used and maintained.

Poorly assessed and managed risks
While we did eventually get a risk management document, it was well after we suffered from most of the worst risks defined in it. The reason we didn’t have this set up is explained with the time management and production issues, but this is a document we have created before and these risks are common. We were not ready to have half the team go missing and were also unaware of the consequences that that would have, namely the healthy team members losing interest in doing any work for the project. This happened due to the realisation that we would have to pick up their tasks after we had already had a huge amount loaded onto each of us. We also no longer had the whole team available to bounce ideas off or work through the game design with, so we could no longer make team decisions. I myself did not want to work on the TDD without my team of programmers, as I was not aware of their capabilities and couldn’t tap into their ideas of how to set certain systems up.

These risks should be set up at the start of the project and maintained. Meetings should include a time for attempting to foresee any future issues, possibly with tasks that require research and the chance that they may not come to fruition.

Audio
For this and other blogs, I have been talking about how strong our collaborator team management and the team themselves were, but I have not taken into consideration our audio guy. He was absolutely fantastic, I asked him to work through our timeline setup for the story and plan our the audio feel and planning, which took him a few hours to do, and a week later he provided his concept work for us to put into our game. This was about all of the contact that I had with him, a failure on my part to set up meetings and task management with him. This meant that there was no iteration or polish on his work, and we failed to put anything he had provided into our game or even tell him about the pivot.

We also had the issue of leaving our audio till last. This is mainly an issue with the production documentation being left until too late and not being able to identify that it wasn’t being done. We didn’t have anyone in the team who was particularly interested in the music, so it was left until last.
Once again, this should be fixed through production documentation created at the start of the project, rather than at the end.

The management part is fairly easy to handle in the future, just manage the audio team in the same way that I managed the animator team. I did not include him in the animator collab meetings as I felt he would be spending most of his time listening to information that did not affect him, but I did not realise that this meant he lacked a team identity and was not able to have his efforts presented to the team, he would get no recognition for his work. Even just sitting in would allow him to generate a better understanding of what the game was, through seeing what it looked like, and showing his work would give the animators a better idea of how the game was meant to feel. This was a terrible choice on my part and one I should never replicate again.

 

To be better in the future

  • Start a project with role assignment.
  • Ensure that multiple ideas are brainstormed
  • Get task notes during documentation generation
  • Create a Gantt chart as early as possible
  • Work as a team to generate tasks for the Gantt chart
  • Have constant team meetings until the production documents are created
  • Set up repeatable meeting topics, and have very regular meetings
  • Do not segregate disciplines, the work they provide helps define your project
  • Minimalize the critical path and pipeline
  • Make your project modular
  • Pivot early

 

Post Mortem of Remembrance

what went right

animator team comms
A google sheet was created for the animator team, including a milestone based task completion tracking system for all of the objects in the game, with each object assigned to a person. There was also a section for swapping out parts of said task (such as texturing). This was coupled with my overseeing of the team, implementing daily skype meetings and weekly face to faces to account for any setbacks, holdups and to allow showing off of each team members work. This was made possible by some team building exercises, such as working together on drawings, creating in-jokes amongst the team, or staying on the skype call together after a meeting to catch up with each other (only if they were available)
This can be replicated by working on team building exercises, making that a part of the time allocated in the time management, rather than only talking to each other under work conditions. This sort of thing seems to come fairly naturally amongst the games students, as most of our interactions have been online. In the past I have tried to stamp out most of the shenanigans, as they distract from the work at hand, on average taking between 30 minutes to several hours before people got back on task, but making time available for these things could prove very useful for team building. Even better would be to begin research into structured frivolities.

Documentation
While it took us a couple of weeks to get around to doing it, this was the most documentation I have had a part in creating for a project. This was very helpful for defining our project, and just as it should, creating an HCD made a GDD and then a TDD much more possible. It helped to keep people accountable and on track. We found that the team members who took a greater part in working on the documentation also had a greater shared knowledge of what the game was, how it worked and what happened.
In the future, I would like to focus more heavily on setting up documentation, creating the structures around that and getting it all done earlier in the pipeline.

what went wrong

Sickness
Most of our team were struck by sickness throughout our production time. While we had not set up a Gantt chart, it was easy to see that this was blocking others from working. We were unable to set up full group meetings and found this as an easy excuse to put off work like design, documentation, and build. Too much work was being placed on the shoulders of the healthy, who soon became exhausted or overloaded, lowering the quality and quantity of work being done. There were brief moments when we were all able to get together and complete large amounts of work, but this project was scoped for a healthy team who were mostly there the whole time.
Unfortunately this sort of risk, while easy to expect, is hard to accommodate. The result of this sickness is a reduction in available working hours, once you burn through the flex time and reassign tasks onto already overloaded available resources, the only thing you can do is reduce the scope of the project. Our project did receive this treatment, although it was not controlled at all. Tasks were simply not being completed.

A possible way of avoiding this in the future is to have better leadership in the team, and to plan out the scope of the game in a more modular way. The core game loop should either be extremely simple or not wholly rely on every part to be implemented to work. for example, our game was meant to use VR, and one of the goals was to make that optional. This was implemented and when I failed to get the VR working, the project did not fail due to that. It did fail though, as most of the other functionality was unable to be completed.
Lack of leadership
This was a huge issue. At the start of the project, we let a team member opt-in to project management, which I chose not to ask for, as I had been the project lead for every project so far. The person who became project manager failed to oversee the project or check up on any of the tasks. they were also in charge of time management. I failed to identify this earlier and take charge of this, despite being hinted into doing this multiple times. What needed to happen was that the project lead needed to complete time management tasks, with the help of the whole team and identify tasks that were behind, properly reassigning them as was needed. When tasks were not being completed, there needed to be follow up and when the project was falling behind the scope needed to be reduced.
Next time, Tasks need to be assigned within the first week of the project and the team lead needs to be reassigned the second the current lead fails. This is a difficult situation, as we all thought, every time, that this would be the last time, and that they would pull through or catch up by tomorrow.

Lack of motivation
With this sickness and lack of leadership came a lack of motivation. As a group, we started thinking, if no one else is doing anything, I don’t want to either. If I turn around and do everyone’s work for them, then they will keep avoiding their work. At least, this is how I felt, with good reason, as this is what happened in my last project. This was one of the main reasons why I did not want to become project lead. We also had KPI feedback during the project, with some bad news adversely affecting some of our team members. I tried to cheer them up, suggesting things they could do to help them achieve their goals, but it still affected their workload. Not much could be done about the general lack of motivation, as it meant that team members would not log into skype, or decide to leave the team early. I have noticed that team members throughout our core team and also collaborators that were not a part in any team building were much more likely to leave early or be affected more by lower moral and motivations. This may be subject to confirmation bias, so I hope to further test this in future projects.
So how do you encourage motivation in your team?
Get your team to feel something about what they are creating. Get them to share a story. Create a focus on the progress of your project. These are the things that went right with the animator team on this project. I described the story, explained to them all of the things that would excite them about the project, showed them the progress of the project, and their effects upon it. I kept them on track, ensuring that they knew about their deadlines, which they set for themselves. If anything was behind, everyone knew about it, but instead of shaming the person who had fallen behind, we instead looked into finding out why it had happened, and what could be done to fix it (this is how the task swapping came to be, as one of the team members had not provided concepts. I found out it was not due to laziness but because they felt they were very bad at it).
Time management
While the animator team was managed pretty well, The programmers and designers did a terrible job at it, which was terrible, as everything went wrong and even some simple time management would have given us a chance to reassign tasks and correctly identify when the project needed to be scaled back. This issue with time management is one that I have had with every group project I have worked on. It’s the first thing that needs to get done, yet is often the last, or just never done. It seems to happen because of different reasons each time, this time, it was because of sickness and lack of communication. due to not being able to get the team together in a group, we felt we could not complete the HCD and other documentation in a fashion that would satisfy the whole team, and without that we had no clue on what the actual task breakdown would be. To be honest, the only way I can see this getting done is by locking down the team in a 12-hour face to face meeting during the first day or even week, to knock out all the basic documentation and a crude task breakdown, which would immediately get set up into the rough Gantt chart. From now on, I will not settle for any less in a group that I work in.
Lack of skill
I have a problem where I assume that any task that is currently outside of our knowledge is simply solved by adding research time to the task. The issue is that most of these tasks are being completed early in the morning, and the time required to comprehend and solve the issue is much larger than anyone ever applies to the task. I had an issue with trying to find if an object is currently being rendered within the view frustum. I ended up creating planes to visualize where these planes actually were, and they were rotating all over the place as I looked around the scene, so I knew so little about it after hours of working on it that I could not even set up a debug to correctly visualize it. This lack of skill also meant that tasks that were worked on for hours had to be reassigned to someone else, taking up their time too.
In future I would definitely limit the amount of tasks that sit outside our current bounds of knowledge to a minimum, and focus on creating the documentation like a TDD as early as possible, to help identify gaps in our knowledge.

 

What I want to be when I grow up

First of all, I would like to say, that there is a large difference between researching a career, and experiencing it first hand. This alone makes a question like this nearly impossible. I know what I enjoy doing, but have had a very narrow experience and find it kind of difficult even articulating what I have enjoyed most, but in short, it has been making my games look pretty. Were I to make that my career path, the closest job that encompasses that in the gaming industry is as a Tech Artist.

so what does a tech artist do?

“Technical Artists help Artists and Designers get their content into the game with the least pain possible, and help Engineers and Artists communicate fluidly.
Technical Artists must know what a healthy art pipeline “looks like” and must help make sure that content creators have the tools & support necessary to do their jobs.”  –Polycount wiki

A local Tech Artist would be Chris Webb, who is currently working as a Programmer at Defiant Development. I was reading through his twitter feed and found out about Godrays, which I thought were sun shafts because of the free unity camera effects asset package that includes them in it.

Tech Artists will normally work in a specific subset, which can vary widely through companies, the most common task being to write tools for the artists in that company.  These will usually involve Rigging, Shaders and Visual Effects.

 

The two that I have been interested in recently were creating my own 3D trail renderer and a shader that mixed a toon shade effect with a crosshatch effect, to override the regular shadows in Unity.

Learning how to effectively program well-optimized shaders that can make objects look amazing would be very useful, especially if I can reduce the cost of them enough to be used on mobile platforms. This means learning how to move away from bodging together code, which I am awful for and focussing on planning and documentation. I could figure out great places to start by reading through blogs of other Tech Artists and even asking them or finding out about the things that interest them.

I could instead end up working for a smaller company, where the skills that are required in me are more general, like becoming a programmer for Halfbrick or Lightmare. Halfbrick tends to work on mobile and console games and have recently been creating them using Unity as their engine, which I have a bit of experience in already. Halfbrick offers internships for programmers, offering a friendly place to start, the people who built Halfbrick also studied at SAE. Lightmare  has also been looking for interns lately, but I have heard that they can be a slightly less friendly environment.

Getting a job in a smaller studio like these would be a great place to find out what it is really like to work in the industry and help me to find my focus, which would help me decide where I would end up if I choose to work in the larger industry, or at least give me experience if I wanted to create my own studio or work in someone else’s start-up.

Without being known in the community, though, I would find it difficult to get a job in any of these places. I have recently joined a couple of meetup groups and facebook pages, specifically Game Development Brisbane and Brisbane Unity Developers. I also began following IGDA Brisbane and plan on attending these events (with my professional face on, of course) and do my best to keep active on twitter.

 

Playtesting reflections and post mortem

Last week my team and I presented our game Titan Tussle for playtesting, this is my findings on our notes and feedback from that.
People found the balance of each character to be fair, each had their strengths and weaknesses (usually attacking created vulnerability) and most saw that teamwork would be required to successfully take down an enemy.

The main issues people had were:

Figuring out how to play (no one read the instructions, even when instructed to do so, it turns out everyone hates them and are then disappointed in the game as they did not know what to do) and players did not understand the objective of the game.
This means that players either need to be forced to read instructions (something very simple, like ‘Knock out the enemy team!’) or be showed some graphic on how to play a game, like a simple or animated image, or a simplified round. Pressing/holding the A button could be required to begin the game also. The original idea had the players choosing their character, where some of these options could be used to explain play to the players.

Players were unaware of teams.
Several set-ups were planned for the game that had not made it into this version yet, like the colour themes for each character reflecting their team and players choosing their characters (where each team will be displayed in this menu). Another brilliant suggestion was team colour outlines on the titan models and on their respective icons at the top of the screen.

They found the controls for the small titan confusing and found the small titan too weak.
The control issue was my own stuff up, I forgot to reverse the input value on their turning, which made them overly complicated. As for them being too weak, there are a few values that can be played with to fix this, like reducing the time they are busy attacking to be much more than the stun time and increasing the range of the stun attack. Another thing that will help is the visual feedback of animating the attack and adding some ‘swipe’ effects like you would find on a sword swing.

There are also some serious visibility issues that need to be worked on, like the difference between fading out an object so a titan can be seen behind it and destroying the object, and also how to better handle distant titans, as their abilities and facing directions can become hard to see when they only take up 1% of the screen.

This is my post-mortem of the project so far.

What went right
Team Management of animators and quality of work from the animators.
This was due to a great work ethic on their part and through great communication, we were able to figure out what the amount of workload they were each capable of. We set up a task sheet for them, with broken down goals and assigned tasks to them there, while passing out deadlines as we were made aware of them. We also assigned a team leader to the group of animators to help keep them on track.

Got a working game loop set up in time for the play testing session.
This is less than I have done in the past but is an achievement in the face of the struggles our project had leading up to it, namely multiple failures in source control and hours of work lost, and the hours of time needed to repair the project. I was able to prioritise the functions and mechanics that were core to the game through the intense development and iteration processes that our project had undergone in the previous 3 weeks and when I was lost, was able to go through the documentation that we had set up to help identify the next jobs I had to do.
The assets the animation team had provided also helped give me direction, as I felt it necessary to implement and show off all the work they had put into this project.
This shows why it is necessary during a project to have all hands possible take part in the design, iteration and testing processes, as it helps form the game in their mind and helps them create the game envisioned by the team, even when everything is failing.

What went wrong
Source Control, Documentation, Meetings, Team management of everyone else, Parts of code broken

why
Source control:
I didn’t know enough about it to properly set up a new bitbucket project & didn’t think of that as an issue. This was a lack of knowledge in the tool and in the consequences, as I thought just setting up a gitignore file was enough. I failed to set up the file structure correctly, was not aware of the correct contents of the gitignore file and did not know how to set up the unity project either. What I needed to do was research the subject, or even go to a lecturer at SAE to walk me through it. Since becoming aware of the depth of this issue, I have set up a meeting with Ian McManus to help walk me through this problem and to also create a video of this process to be shared with my colleagues and anyone else who is struggling with source control.

Didn’t do anywhere near enough documentation, specifically a Gantt chart, risk assessment, failed to complete an HCD or GDD of good quality, and haven’t yet completed a TDD.
This documentation were planned to be set up and worked out as a group during face to face meetings, however, our team failed to show up to these meetings and the documentation either suffered or were never created. They further suffered from a lack of enthusiasm in our whole team for the project. We also suffered in communication, as the team leader it was up to me to push for our team to work together and get everything done to a high standard. I was unable to communicate with my team at most times and feared that pushing my team to hard would seem like I was asking for more than I was doing.
There was little to no team management from myself, attempts that I made to document tasks were not maintained and barely followed up, some team members are only contactable on facebook.

Due to a failure in source control, and not creating a local backup, and failing to save regularly, a unity crash lost hours of work, and when it tried to recover data some code was broken without throwing an exception. this meant that the main mechanic (titans knocking around other titans) was not in the backup build presented during playtesting.
In the future, working locally or through source control, I must stick to a schedule for saving and backing up data. I only missed the issue with the main mechanic being broken because I was very tired and out of time to work on the project anymore, but learning how to correctly use source control and saving more often should help to reduce the chance of such a bug getting past me again.

What I learned from SOMA

First of all, SPOILERS. This whole post is spoilers, so go and play SOMA first, if you haven’t yet, I highly recommend it.

The story felt compelling, interesting and unobtrusive. This was achieved by not removing control from the player during dialogue, except for the beginning dream sequence cutscene, which is about 30 seconds. You wake up in your apartment, answer a phone and are told that you have to find and drink a bottle of tracer fluid, and then make your way to an appointment. The apartment is the perfect safe zone for the player to learn the controls and basic mechanics of the game (find the thing, use the thing. This covers every objective in the game, along with: find the exit and avoid the baddies). The next scene provides you with an option to answer or decline a call, showing the player that they have options. These options were fairly infrequent throughout the game and I found that they did not seem to have any consequence at all, even the large one at the end where you choose whether or not you kill the last human or killing your own copy. I did only play through once, but these choices I made, along with others, never came up in dialogue again.

That having been said, the story itself was fantastic, although that may just be because I am interested in high science concepts and their philosophical repercussions.

The use of light to direct the player towards objectives was often very strong in this game, keeping that in mind during play made finding my way around very simple and helped lower my stress, although I had to make the conscious choice to look for these areas at times, as there were some areas with a lot of other sources of light, or they were obscured by scenery, however these areas never featured time constraints, giving me the time I required to figure them out.

The anxiety/boredom flow was used pretty well in this game, safe areas in the early game felt very safe at all times, but in later parts of the game had constant creepy or dangerous noises playing to make those areas feel much less safe than the earlier ones.

SomaPC12There was a small problem with the increase of enemy difficulty, where I moved from one area with an enemy that teleports around, and kills you if you look at it (which could see and hear you) and kills you if you are too close to it, to an area with an enemy that could not see you and you could look at, that seemed to only respond to sound. This was an enemy that was less dangerous than the previous one you encountered, in an area that you had more ability to move around (the previous was in a sunken ship, with tight corridors and was completely flooded so it felt like you had less move speed. You were expected to find your way through the ship and although the level itself was fairly linear, you had to spend most of the time not looking around or moving as quick as you can through the level, making it difficult for the player to map out the area. In contrast, the next level was just very dark. It was also a bit maze-like, but because of the nature of the enemy you had plenty of time to take the area in and get your bearings, not to mention the darkness meant that the use of lights to illuminate the goal were very obvious in contrast.

This situation could have been used to allow the player more confidence in themselves and may have been required to keep players interested. I myself felt quite hopeless when facing the previous enemy, if this difficulty had continued trending upwards, I may have given up. The problem I had was that there was a severe build up of this second monsters difficulty, much more than the previous, through constant ambient noise and story elements. This monster did not really need to be less difficult than the previous one though, as there was a whole level in between these monsters without any threat and much less ambient build up of stress.

355020960I noticed the possible use of an FSM in one of the enemies AI when I got it
stuck in one of its states. From what I could tell, it had 7 states; Idle with / without target, Patrol, Search for not – visible target, Search for lost target, Found target – Submissive / Aggressive behaviour. This particular AI (the small corrupted submarine with red lights) seemed to have a medium range of vision and hearing (you could sneak behind it but not run). If it spotted you, and then lost you, it would move to the location it last saw you, move around the area (possibly towards sounds made by the player?), then eventually return to its last position in its patrol (unless it heard or saw you). If spotted, the AI would move towards you, but in a submissive state, would attempt to keep a short distance between itself and the player (the player has a faster move speed than it). It had an extensive list of dialogue audio clips, in this state it would beg the player for their ‘structural gel’ (reinforcing the recent discovery that the player was not human). After a short time, the AI would move into the aggressive state, and advance on the player, attempting to collide with them. This was accompanied with aggressive dialogue and a change in the model (tentacles erupted out of its hull, reaching and wriggling towards the player).

I somehow caused the FSM on this AI to fall into its submissive state, but fail to move into its aggressive state (it just sat there begging me for structure gel). I’m pretty sure I was crouching and half hidden at the time, but I somehow caused its timer to never count down or to go outside its expected range, or possibly it skipped the exact number it was required to hit to move state, but that’s very unlikely. I held it there for a few minutes until I decided to move towards it, this caused it to move straight into its aggressive state and it killed me.

I hadn’t had any other issues with the AI in this game, so I believe that this was a freak occurrence and therefore nothing to worry about. This is also something that would be picked up in rigorous play testing.

The ending felt a little strange to me, as the copy of the player that was left behind could make its way back to the other sites, with Catherine’s copy (your AI ‘friend’ throughout the game), and just continue on with their lives, maybe working on the WAU to become something less horrible. I also don’t understand why the whole site did not try to continue the human race (and maybe nip the WAU in the bud, before everything got so nasty) and instead chose to only preserve the brain scans of a few people for a few hundred thousand years instead. This is just a prolonged but now inevitable death.

Pitching games & fab48hr gamejam

48hr GameJam

I went to the 48hr game jam at QUT which was full of impressive games and people. Here is my top 3, and what they were about:

CQdkYRLUkAABO_9SOL – I had a blast with this. While the controls were a little difficult the team had taken steps to account for this. Shooting a missile or asteroid at a target did not have to be precise, as these targets had gravity wells that would draw the projectile into the target. This allowed for more fast-paced gameplay, where you would fire and forget about it, immediately moving on to your next strategy before the completion of the last, creating a more chaotic experience. I found it suffered slightly from a slow ramp up in difficulty, which was helpful on the first play but not as much on subsequent plays. The colour choice of red and orange for opposing players was slightly confusing too, however, I was so quickly invested in this game that I threw my arms up in the air when I won.

CQcMLapW8AATNWLDUNE RAIDER – From first impressions I was surprised, this game looks complete. The amount of polish is astounding. The idea of the game is to move from the bottom of the screen to the top, grab some gold and move back to the bottom. The first to get enough gold wins. You have the option of how much gold you take, but the more gold you take, the slower you move. There is also the ability to leap forward, which you can use to knock another player around. There are also giant sand worms appearing randomly across the map, which will empty your gold sack if you touch them. Unfortunately, the best strategy to win is to fill your sack to maximum, and leap back to the goal, as you are only slightly slower than max speed at that point. Others can knock you around, but will be most likely focused on trying to win themselves. Still an absolutely brilliant game.

21743298288_ccf9e9e630_bWHERES MY SPACESHIP? – Playing over 4 four screens, fly a spaceship through wormholes to collect the most asteroids. The enjoyment/stress of this game comes from random screen transitions and the fun of trying not to collide with the other players as they franticly sprint around the room trying to locate their ship. Of course, you can steal each others asteroids so I sat at the drop off point and grabbed everyone’s asteroids as they warped in, easily guiding them into my collection port. Figuring that out was immensely fun, but I worry that once this strategy is figured out by players, gameplay may lose its excitement. Still a very impressive display of technology, and a highly enjoyable game.

I did a pitch for my game Clearcutter. In my pitch, I had issues with some of the slide content, where I had chosen to load up the videos on youtube. I should have downloaded them and dropped the files into the slide themselves to avoid loading issues. These videos were also not needed, as they were only showing the main view of the game and the general feel of movement & mechanics. I also drew a picture of the main screen, which was not needed as I ended up starting work on the project itself, which I presented for part of the pitch. This was able to effectively show the main player screen, basic mechanics and movement/game feel. The feedback that I received mainly pointed out that the way I was talking about how the game would work made it very hard to conceptualize the game itself, but the second I showed the prototype, It was instantly understood. I also had an issue with needing to read from a script, which I had set up on my laptop. This meant that instead of talking to the audience, I was talking to my laptop. A simple fix would have been to create small cards to read from and spending more time practicing my pitch, which is a recurring problem that I have.

Strong points that I had were generating interest with an exciting intro, explaining the background and theme of my game, even if it was a little confusing, and actually having a very basic version of my game set up to demonstrate what my game would be.

My plan for my future is after completing my current course, gaining industry experience, and to grow my network. Working in local studios will help with that and taking any programming jobs that have a decent pay, whether they are in the gaming industry or not, will help me save money to either move or help create my own studio. I also plan to take a course in business management.

1rIGqbm

Another game that was made for our week 1 project was Caffeine Chaos, by Ash Stevens, which had to meet the same brief requirements as my game. You had control over two avatars, Tony and Steve, whom you controlled using the WASD and arrow keys to move them around. Steve controlled normally, but Tony had an inverted Y-axis, which flipped around based on the proximity of the two avatars, and movement was the only control you had over them. Proximity. For having the avatars as close together without touching as possible, players were rewarded with easier controls over the avatars and increased movement speed. The game had a 2-minute time limit, there was no death, and the game was in real time

Through this, the game meets all the limitations set out in the brief. The game has two directional inputs, which is fairly minimalistic as most arcade games have a joystick and six buttons available. The mechanics are strong, but could be explained to the player better, with the inclusion of visual cues to display which state the control scheme is currently in.