Tag Archives: Team Work

Postmortem on Pulse Monitoring Plug-in for Designer’s Game

I found that this was an unusual process.  To date I have been deeply immersed in most of the games that I have collaborated in.  The closest to this was my involvement with “Valour” where the programmers went in hard to start with, set a lot of things up and then had much less contact with the designers as they advanced their ideas through the game play.

To even mention “Valour” send shivers down my spine and it is not a comparison to the final product of “Be Brave”, created by Savik Fraguella.  My involvement was even less, in the scheme of things.  I created the software to get Unity to accept an incoming pulse beat from the wearer and feed that pulse rate into an system that would emit a “Fear Factor” rating that Savik would then be able to use to influence the content of his game.

I quickly, over the space of about 2-3 weeks, completed this task and handed it off to Savik to await any problem that might emerge.  There was one situation where the program would quit and then restart as the level was changed but this was quickly over come by making it a persistent singleton that could start during the main menu and then remain through the levels but destroy itself when either quitting, or completing the level(s).

Savik, at one stage, did borrow the equipment needed to test the game, but he either didn’t install the FTDI drivers, or there was a problem installing them.  I referred him to my blog post regarding the project for installing them.

As we got closer to Open Day, where the game would be displayed, I regularly checked with Savik if he wanted the Arduino to test the game, but he wasn’t interested, focusing on the art work of the game.  It wasn’t until the day before Open Day that I realised that there were some problems.

The pulse rate wasn’t getting through to the build of Unity.  It still processes the information quicker in Unity than in the build but that is another story.  I narrowed the information coming into Unity in order for the information not to clog the ability for the build to run.  Instead of collecting all the information, I narrowed to Arduino to only send information that I could use, which was the actual beat rate.

Video showing the Pulse rate through a simple GUI and the Fear Rating being influenced by the pulse rate.  (I must apologise for spelling “Serial” wrong)

With some help from my tutor, who performed some Unity black magic, I was able to get the build to work properly.  When I find out what black magic was performed, I will amend this post with the information.

Savik showed some quite advanced scripting skills that impressed me, both with him knowing that they existed in the first place, and with the application in a game setting.  Using Pims Algorithm to randomly generate a level so that the exit was not close to the entrance was among the concepts that I found interesting.  I would do well to sit with Savik and discuss how he came to implement them and other ideas such as, apparently, using the fear state to assist in the generation of the level.

What I have learned through this project is not to adopt a “set and forget” mentality.  By remaining closer to Savik as he progressed through the making of the game, I would have been aware of the problems with my component much earlier, and I also would have gained a better understanding of how he utilised and adapted those scripts that left me with a positive impression.



Gallery showing Post-mortem.

What a random placement schmozzle .

Learning from the past, we actually organised a play testing session after we believed we had fixed all the bugs from the previous play test.

The 3ds Max bug that affected my laptop last time, was still present, so I could not build from my computer.  For some odd reason, Tim could still see the missing assets on his laptop.  I could not explain this, and still can’t.

We were satisfied until we got to the venue and did a quick speed run of the level.  That is when the camera gave up the ghost.  It worked perfectly fine in the tutorial area and then had severe problems in the later stages of the level.

We tried to quickly trouble shoot this problem and then decided that for most of the final end of the level, to include another of Savik’s trigger boxes to try and keep the players aimed in the right direction.

We did another build and had to call it quits at that point.

Then Unity took over and nothing seemed the same again.  Camera angles that were working previously, now didn’t work.  Fog that had spawned in the exact same place since the beginning, suddenly spawned in one of two places, the place where it was designed to spawn, or at a place that seemed to be somewhere outside of the temple.  Target points for the cut scenes suddenly seemed to move of their own volition and occasionally the camera couldn’t make it back to it’s starting position.  The camera check for hitting objects seemed to be hit and miss, occasionally staying way high in the air.  Most of these weird bugs could possibly be attributed to some error in the quick fix for the camera at the end, except for the random spawning of the fog, and the sudden maneuverability of the camera targets for the cut scenes at the shrines.

The game seemed to be pretty well received and it was a huge improvement over the first effort put up for play testing, but in the end, it still left a bitter taste in my mouth.

The secret of success for a good camera is to have no feedback over it.  It becomes such a part of the game that it isn’t noticed.  I realise that 6 weeks is hardly enough time to develop a fully evolved camera system, but I feel that this should have been better … at the very least, to point in a direction that it was intended.  My only solace is that the guy bought in to work on the camera for Journey spent almost two years getting it right.

For the first play test, my responsibility was for the wind turbine trigger, that was never used in any iteration of the games, the mechanics of the headbutt trigger button, the player controllers, the fog and the camera.  The main problem I had with the player controllers for the first play test was probably that I didn’t realise that the controllers had a .isGrounded function built in.  I was achieving this through a raycast, that was probably not quite grounding the player enough.  After the first play test, my main focus was now the camera and to a lesser degree the fog mechanics.

It wasn’t until after the second play test, when I was trying to explain how my camera was supposed to be operating, that I realised a serious mistake in working out my height and what the camera was looking at.  I wasn’t applying a base y position for these applications.

After the second play test, my main focus was on the camera and the cut scenes at the shrines.

Things I have learned from this project:

Making time to play test as soon as you have a viable core game loop happening.  That way you can identify bugs early and work to correct them sooner than we did in this project.

Clear guidelines from the outset as to the number of levels and the arrangement of assets/puzzles within those levels.  This way, early testing of things such as cameras and character controllers can be devised and implemented before making it into the levels.

Just because a system will work in one part of the level doesn’t mean that it will work in all parts of the level.

Did I mention that full play testing will reveal what works and where it doesn’t, so make time for the team members to play test the systems within the game.

Second Play Test Post-mortem

What a schmozzle (again).

There were so many problems with this play test that it is hard to know where to start.

For a root cause, I would probably start with the lack of private play testing before hand.  Again, most of the bugs would have been identified before hand.

For a second problem, we had no way of building again the morning of the play test.  The designer incorporated .max files in the repo which meant that no one was able to build from their lap tops, and as we were using Unity 5, we couldn’t use the college computers to create another build.

As a result, we were stuck with the build that was created the night before, that we knew had serious bugs.

The player controllers worked well, but the camera required boxes that changed the settings for the camera and the target.  The problem with these boxes was that they recorded the previous target, but when boxes overlapped, the original target was overwritten by the boxes and eventually, the distance target was lost completely.

What I really needed, for this game was to have a camera that would have the ability to free roam, without the wild erratic swings when the players changed direction, and incorporate them with the camera box triggers that would direct the player to the right area.  The ideal would be to have triggers that would load up points of interest within the scene and give a weighting to them, but I doubt there would be enough time and I wonder over the effectiveness of this method, when the ideal is for the players, in the tutorial area, to experience the fun of an unorganised area, where there is no pressure on them.  Where they can enjoy getting to know the mechanics of the game and learn what can be done with them.

The other main problem was with the shrines, themselves.  I needed to take absolute control of the camera and create a cut scene so that no other actions, either by the player, or from any other source, could affect the camera at this delicate stage.

The fog will also need more effects to hide the actual spawning of the fog, and the transforming of the fog from spawn mode to full scale fog.

I didn’t learn anything new from this play test, except that shit can go wrong at the worst possible time.  We repeated many of the mistakes from the last play yest.

When communication and GDD’s aren’t enough

For weeks, I have been designing assets and scripts believing that my team’s current project,  “Atl and Ollin”, was to be one single open world.  Two nights before the first play test, I find out that it will be 3 separate levels.  Apparently, it has been so for some time, but I wasn’t aware of it and it isn’t covered in the GDD.

I don’t know if I made an assumption about the state of this game, but I believed that my concept was valuable to the desired outcome of the game which is the need to build trust.  There would have been no breaks from the immersion of the characters and their journey across the landscape.  I knew that there were 3 different stages of the game, but I don’t believe that they should be broken up with different levels.

I will endeavour to try and convince the designer to consider this idea and try to compare it with life itself, where there is a stage of learning and playful abandon (tutorial area), followed by the panic of the middle years (disturbing the fog) followed by the inevitability of death (final area).

I didn’t even have a chance to even write up this blog as the pedal was to the metal all weekend.  Sleep deprivation..who needs it 😉

Studio 2: Projects I worked on over the break.

Aside from catching up with my favourite games, I had plans to do animation related research over the break.  However, while watching a C++ tutorial about a sudoku solver, I turned my attention to this.

While the C++ tutorial was talking about a brute force solver, I was thinking of a quicker solving method that used some form of logic and set about creating it in Unity using C#.

Utilising only 2 scripts (one to draw the cells and menu and the other to perform to logic.  I have come up with a solver that clears the “Easy” and “Medium” levels with ease.  It also solves the “Hard” puzzles about 95% of the time but is unable to fully solve the “Evil” levels and won’t even generate a single number in the “World’s Hardest Sudoku Puzzle”. http://www.telegraph.co.uk/news/science/science-news/9359579/Worlds-hardest-sudoku-can-you-crack-it.html

Medium puzzle entered into the solver.

Medium puzzle entered into the solver.

Solved Medium level Puzzle.

Solved Medium level Puzzle.

Hard puzzle entered into the solver.

Hard puzzle entered into the solver.

Solved Hard level Puzzle.

Solved Hard level Puzzle.

I have programmed the solver to look for hidden pairs in Vertical, Horizontal and within the sub-square of the puzzle.  It also can search for the formation called “X Wing” and has reasonable success with the formation called “Swordfish”.

Evil puzzle entered into the solver.

Evil puzzle entered into the solver.

"Solved" Evil level Puzzle.

“Solved” Evil level Puzzle.

I have not been able to program in a way to search for the formation called “XY Wing” or “Unique Rectangles”.  I will hope to continue work on this project over the course of this trimester and my aim will be to solve the “World’s Hardest Sudoku Puzzle”.

The other project I worked on was my team’s entry into the “40 Hour Make a Thingy” competion at Qantm/SAE.  This project was “Running Late” (pronounced like the coffee, with an accent over the ‘e’).  The words were Coffee, Comb and Crescendo.

As the group had 5 programmers and I couldn’t be in on the Tuesday due to Centrelink commitments, I ended up reverting to my old degree and looking after any assets that couldn’t be located in the Asset Store.

We over scoped and as seems to be my lot when creating assets for a “Make a Thingy” comp, none of the assets were used in the final version for the competition (Only once have my assets been used in the final of this competition, and on that occasion, my team won.  Will have to let future teams know this 😉 )

The only code I can claim responsibility for is the hot/cold shader for the coffee temperature bar, which was simply a bastardisation of the health bar I created for “Valour” last Trimester.

Clock running in test window.

Clock running in test window.

Coffee to go with temperature marker overhead.

Coffee to go with temperature marker overhead.

Custom light shades created for level.

Custom light shades created for level.

Mail trolley to be used as mobile barricade in the level.

Mail trolley to be used as mobile barricade in the level.

You need hands to carry the coffee.

You need hands to carry the coffee.

Even though my assets weren’t in the final version we ended up showing on the day, I believe that, as a group, we will continue on with the development of this idea.  We only missed the brief by a few days and it will be an interesting game to have on display for the occulus rift in the library for future generations of Qantm students.

Postmortem on “Valour” .. my latest group project.

This was meant to be the highlight of our trimester.  We had 6 weeks to produce a game with the only stipulation being that it couldn’t be from any of the favourite genres of anyone involved in its development.  For the most part, we had to rule out First person shooters and First and Third person RPG’s.  Really, it wasn’t much of a restriction, because who wants to make on of those games over 6 weeks, while still having to work on production code as well.  Who would want to play one made over that period.  I couldn’t be that good with that time constraint.

I found that I was more vocal during the design stage of this project, but also found that my views were not being listened to.  The original idea was for something that I would not consider a game.  I thought it was very soft on gameplay elements and more like a movie.  I have since learned that the best way to approach this is to call in one of the lecturers and have the designers pitch the idea to them.  It feels gratifying when some of your ideas are later incorporated into the design.  Health Bars, health drops (which weren’t included in the final “game”).  I felt my idea of having the health drops being scripted to spawn just out of view if it looked like you were going to die, would have helped give the appearance of some sort of gameplay.

This is a game, where the main character moves through levels, releases some prisoners and then dies … only to be revealed that he was actually a toy being manipulated by a boy in a sand pit .. only to be revealed that maybe he could have been real after all with is mother being told of his death.  Lovely twisty story, but Journey, it isn’t.

The early days of development went well, with  one of the designers accessing a 2d side scrolling game that we could look at appropriating the character from, and also some parallax scrolling scripts from.  The main aim of my brief, was to look after the special effects.  Particle effects. explosions, any shaders that could be used in the game.

About 3 weeks in and I was told that we are no longer using the parallax scrolling scripts.  The designers didn’t like the fact that the player was stationary and the scenery was moving.  Jamie and I didn’t like the sound of this move but as the designers were looking after most of the level design, I believed that what ever made their job easier would be better for the team and this project.  I had nothing to do over the last week of the project, after getting rid of all the arrays, checkpoints etc from the game, as we were making small levels that only had the one checkpoint at the start.    This gave me the chance to focus on Production code and some side work on shaders and gaining an understanding for how they worked.

I was getting worried by the Tuesday before the first draft of this assignment was due, especially after being warned that Gibbs tends to leave things till the last minute and Nick suddenly lost all ability to access Unity or Github.  Gibbs didn’t turn up in the Wednesday that the fallback version was due, and ended up submitting all the levels, slowly, over the Wednesday morning.  My first look at the levels was Wednesday afternoon.  I find it hard to understand how the game moved so far away from the original design to what was submitted.  This was done without consultation and obviously on the fly at the very last minute.  The levels looked nothing like what was planned for.  The character was walking on box colliders, infront of a solid piece of scenery.  The original design had several layers of foreground, back ground and middle ground.

It appears that this was the easiest way out for a designer that did nothing towards the art for the first 5 and a half weeks of this project.  This is reflected in the pushes to the repo.  55 pushes up until last Friday.  Then nothing until Tuesday afternoon.  19 pushes over the last 2 days of this project

I believe I must also accept a lot of responsibility for the way this project ended up.  Gibbs was the team leader and seemed very keen.  I should also have been a “back up” team leader and made sure that the art was being done.  I believe that I shouldn’t have to be a parent, but it is obvious that someone had to be in charge.  I am just as responsible as everyone else in the group for the mess of this project.

To think that I was bitching about the last project because there was no leader.  There was, however,  great communication between the working members.  With “Valour”, there was a leader, but no communication.

Communication, I now believe, is the key to a projects success or failure.  Moving forward, I believe that for my next group project, there needs to be an understanding from the start, that the group members will have several skype check ins between classes, checking how everyone’s work is progressing.  This can be bought down to daily as deadlines approach.  Everyone can relate how they are going and if they are having problems with their work.  Anyone that reports that they have done nothing, or if their work doesn’t match what they claim to have completed needs to be cautioned, and in the event of repeated failures, need to be, either evicted from the group, or bought before the Lecturers for counseling.  Anyone who does not report can be assumed to have not done their work and treated in a similar manner.  This means that the documentation needs to be well thought out, well published, followed up on and amended, if necessary.  The gantt chart needs to be reasonably accurate and time MUST be made to allow play testing after prototype has been completed and also before release of the final version.  Simply put, what the lecturers have been expecting from us.

A full list of my personal credits for this project are:

Modifying the existing player controller script (from the ActionGame2d package out of the Unity Asset Store) and modifying the Parallax scrolling script that was abandoned from the project.

Creating the prefab and script for the mine.  It had two “lights” that flashed on the top, an area trigger that started a countdown and flashed the lights at a rate that became quicker and quicker till the mine exploded.  It also had a collider that instantly blew up when touched.

I created the particle effects for when it blew up.  There was the explosion, smoke and bright sparkly bits that resembled pieces of the mine.

mine particle effects

mine particle effects

I created particle effects that generated puffs of dust from the player moving.

Player generating dust puffs from footsteps.

Player generating dust puffs from footsteps.

I also created 4 different types of smoke.s to be used in the scenes and in the backgrounds, however these were not utilised in the final game, probably due to the lack of depth provided by the final art.

Smoke effect indicating High smoke that is close to the player.

Smoke effect indicating High smoke that is close to the player.


Smoke effect indicating High smoke that is further away from the player.

Smoke effect indicating High smoke that is further away from the player.


Smoke effect indicating low thick smoke that is close to the player.

Smoke effect indicating low thick smoke that is close to the player.


Smoke effect indicating low thin smoke that is close to the player.

Smoke effect indicating low thin smoke that is further away from the player.

Created a shader that could work the health bar of the player (previously revealed in this blog post https://richarddanielstein.wordpress.com/2014/12/01/yay-shaders-a-breakthrough/)

Created the Game Director that handles the explosions, the player’s health and some sound.

Created a prototype health pickup that restored the player’s health but was not utilised in the final project.

Created a lot of Lists and objects to handle having various checkpoints within a level.  Also had functions that destroyed all the assets and then re-instantiated them when the player re-spawned.  Had some fun with that when I was trying to destroy the assets in the screen and Unity told me that if I wanted to destroy them, I had to use DestroyImmediate(object, true);  I was an obedient servant of Unity and did this instruction … only to have all of my prefabs deleted from their folder.  I then created a throw away list to keep the clones in and deleted them, if they existed.  But that is all moot, because the levels changed down to simple levels and had only one checkpoint.  This allowed that the entire scene was reloaded when the player died.

This project has helped me with my professional goals by providing an opportunity for me to get involved, albeit in a small way, with creating particle effects that could be used in this game.  The only real one that survived into the game seemed well received as we displayed the game.  The others gave me experience in trying to work with particle flows, sizes, rates of speed and experimenting with their length of life.  All of these particles were created in the old legacy system as I had great trouble understanding the Particle System method of creating them.

The 3 important things I have learned from this project are:

  1. Having good communication is better than having an ordinary team leader.
  2. I need to become much more assertive in all areas.  From design ides to team leadership, I need to become more of a parent and make sure that work is being done, on time, and as recorded in the Gantt Chart.
  3. I want to work with particles and effects, but I also want to become a better general programmer and work further with animations – more leaning towards 3d models and the shaders to show off the work.  I really think that will help me get into this industry.

Details and post mortem on final presentation of 1st group project

A full list of my personal credits for this project are:

3rd person controller and camera scripts (prototype)- converted over to a standard first person controller and camera (Final).

Scripts and prefabs for a drawbridge to lower and then raise after x seconds.  Included collision boxes down the sides and under the bridge to prevent the player falling through or off the bridge.(both prototype and final)

Model and UV unwrap of the bridge model. (final)

Model placeholder assets of all main characters.(prototype)

Game director to handle the swaps between the characters. (prototype and final)

Script for jumping the main character through the jumping box.  (prototype and final)

UV unwrap of button and texture.  Animate the pressing in of the button in Unity. (final)

Failed script for the line of sight mechanic and the subsequent scripting that allowed for button changes between the characters. (prototype and final)

Changed the pivot point of the final models in 3ds max (rotating them so the Y axis was up) and imported them into Unity, as well as their textures. (final)

Sourced, scripted and edited the following audio clips:

  • footsteps for all characters.
  • bridge mechanism.
  • Jumping.
  • jumping box.
  • heavy box and jumping box  hitting the floor.
  • small teleporter.

This project has helped me with my professional goals by providing an opportunity for general coding practice and working under pressure towards a strict deadline.  It has also helped me work out exactly what areas I would like to focus on with future projects so that I can be gainfully employed within the indie games circuit here in Queensland.

The 3 important things I have learned from this project are:

  1. Get the prototype working well in the first instance.  It seems that the more you get accomplished with the prototype, the less pressure you will be under for the second half of the project.  While the code might change, you already have a good starting point with the code from the prototype.
  2. Provide more time for play testing and factor that into the time line of the project.  We didn’t allow enough time for serious play testing and trying to find the bugs and glitches in our game.  In all honesty, we didn’t even factor that into our time line, which had production all the way up until the night before the first build was due.
  3. I believe that all teams should have a team leader.  We did not have a leader on our team who could check that tasks were proceeding as scheduled, could make a decision to change the Game Design Document and could chase up the people who were not contributing fully to the efforts of the team.  Without a leader, I feel we were affected by a lack of direction and seemed to be hopping from one emergency to another with a small group of people doing the work that should have been done by others.