Tag Archives: Communication

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.

First Play Test Post-mortem

What a schmozzle.

While people did have a lot of fun playing our game, it was for all the wrong reasons.  When the player controller hit the edge of a mesh collider, it had the possibility of becoming airborne and bounce across the scene on the edge of the cloak mesh.  In conjunction with this, semi-skillful use of the jump mechanics would make the controller float across the terrain to the point where one piece of feedback called it a NASA sim.

The “Tutorial” area of the game was buggered because while the test elements worked on our individual test levels, they didn’t work in in the game proper, because Tim and I didn’t account for the puzzles being childed to one or more empty game objects.  We were using transform.position to move our puzzle elements, when we should have been using transform.localPosition.

This would have been identified had we organised play-testing before hand.  There was also miscommunication about how many levels there would be in the game.  I was working under the impression that there would be only one level and that the fog would be moving, or chasing, the players through a “valley”.  I found out on the Thursday or Friday night that there would be 3 different levels and that the fog would be chasing the players over open area.

This caused a major revision of how the camera, and fog would have to operate.  As a stop gap, I had the camera always facing towards the end of the level.  I then compensated by having a List of targets that the camera would move towards and a function to receive a message that would move the distant target to a new location.   One problem with this was that the targets were set up for the players to gain a collectable to activate the shrines, but this collectible wasn’t ready for the game.  The camera would move once the players were in a certain distance of the collectible, but as it was a short radius to achieve, the camera wouldn’t move on. The feedback was that the players wanted control of the camera, which was never going to happen, as part of the camera mechanics were used for jumping and who should have control of the camera.  Two players battling for control of the camera would tend to break the Trust mechanic that was the intention behind the design of the game.

Things that I have learned from this play-test is that there need to be a very clear understanding of the game, it’s design and how the levels are going to be created and laid out.  This understanding needs to be gained in the very early stages of development.  That way, I would have had a clearer understanding of the level well in advance of the play-test.  Any changes from that design need to be made in consultation and agreed with by all the members of the team

As has been a problem with other projects in the past … play testing is vital before trying to demonstrate our game.  This iteration was never play-tested by us as a group before we tried to impose the first play-test on our “public”.  Many of the bugs that were in this game would have been easily identified and could have been corrected, if we had the opportunity to play test.  In that way, we, or at least I, would not have been so embarrassed by the bugs that became apparent during this test.

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 😉

What have I learned this Trimester.

There are so many little things, that I wouldn’t know where to begin, so on a larger scale:

I have learned how to build a quick prototype and create hacky code fixes to get the game running.

I have learned how to set up play testing for the prototype.

I have learned that feedback is essential to show the player what he needs to do and to avoid the things that he just did.

I have learned how to set up a repo and manage it.

I have learned how to do a technical design document (better than when I started this trimester).

I have learned that having no team leader but good communication is way better than having a team leader but no communication.

I have learned (hopefully) how to deal with several team situations. Like, when you think that you are not being heard in relation to game decisions and game choices, when team members let you and the team down, how Risks need to be more than just identified, how we need plans to overcome the risks.

I have learned how shaders work to translate vertices to screen pixels … and how you can start manipulating the information during the shader pass, or passes.

I have learned enough about web site design to feel confident in giving it a try over the holidays and set up my own web site.

While I have learned many little things with C++, I still feel like a fish out of water with the language.  The SFML project was such a quantum leap from Greg’s classes, that I was originally keeping quiet because I thought that I was well behind the 8 ball, until I realised that nearly  everyone else was in the same boat.  Moving forward, I have found some tutorials to do over the break, that I hope will give me some help in further understanding C++, and pointers.

I have learned what I want to be when I grow up.

I have learned that there is way to much to do over the break.

How my TDD and Repositories have evolved between the 1st and 2nd group projects.

Link to my WWW TDD:


My first attempt at creating a repository went very well.  I was using Bitbucket with SourceTree and created the repo easily.  The problem came when I first tried to push the initial project to the repo.  I had what seemed to be a catch22 error.  Couldn’t push because I hadn’t pulled, and couldn’t pull because I hadn’t pushed … at least that is how I remember it.  Corey was my programming partner for this project and we quickly changed over to GitHub for windows.  This went OK up until the last day when the repo crashed and nothing could be done.  Pat Monaghan quickly amended our “gitignore” file and fixed it, just like that.  *sigh.

Our TDD reflected my use of Bitbucket, but did not evolve when our need to change repositories occurred.

This was not a “living” document …. and on reflection, neither is my second one, but we will get to that shortly.

The document itself, is full of useless crap from the template, that should have been deleted.  There are no risks documented and considering the genre of this project, there should have been some risks.  Player not understanding the puzzles, player not understanding the way to transition between characters.   These were obvious after play testing and should have been documented then, at least.

The reason why this, and the next TDD wasn’t a living document, is because it was not a priority.  To be totally honest, the first time I looked at these documents, since creating them, was just now, before writing this blog.  That makes me a little sad, because the work and thought that went into them was wasted.


Link to my Valour TDD:


The thought and effort in my second TDD is more apparent.  The only useless thing from the template at the start of the audio section.  The remainder is concise, to the point and relevant to this project.

But again, it is not a living document because the concept about parallax scrolling of the scene and Lists/arrays for checkpoints throughout the level are still mentioned.

It is interesting to note that I did identify three risks and that each one of them came to fruition.  I naively did not identify the risk that team members would let the project down by leaving the art assets until the very last moment.  In hindsight, it could have been foreseen.

But this risk section needs to do more than merely identify the risks.  It also needs to identify the ways that the risks can be averted.  References to the GDD document would be applicable for the three risks I identified, and if there was nothing in the GDD, then it needs to be amended to make sure that my risks can’t be traps for the team to fall into.

As to the risk of team members letting the team down.  I believe that there should be a detailed, documented course of action for keeping the team on track and dealing with members that are not pulling their weight.

As to making it a living document, I believe that any changes can be made through using the strikeout feature and re-writing sections, at least for the duration of this course, so Lecturers can see that the document has changed over the length of the project.  As the document’s creator, it is my responsibility to make sure that any changes affecting the document should be discussed with all the other members of the group and bringing in the Game Producer if there is any lasting conflict over the changes.

Most of the content needs only be done the once and then reproduced for future projects, with minimal changes.  For example, a tutorial for using github only needs to be done once and only changed when a flaw has been identified, which only means that you have a new version for the project after that.  The same can be said about the process for checking if team members are pulling their weight.

My second attempt at creating a repository was a lot better. There were no conflicts with pushing, pulling or merging.  I don’t know if that it because I am still using the essence of Pat’s gitignore or whether everyone was more aware of using a repo.

Two think I will take out of this, is that there need to be more documentation about using the repo in the TDD.  There needs to be more than just supplying a link to it.  There should be provision for what to put in the comments when pushing.  No comments, or “The name explains it”, are essentially useless.  Full details should be provided.  The documentation should take a new comer by the hand and help them create, load, clone and use the repository.

While there has been a marked improvement between the two documents, there is a lot more room for improvement.