Tag Archives: Feedback

C++ pseudo code, header implementation and how-too videos are the reasons why I am not liking C++

While I am sure that C++ is a great language to knuckle down into memory allocation and stack organising but i you have no idea how to implement the language into headers and use the resulting functions correctly, it is all but useless.

That is the situation for me at the moment.  Over the last few weeks, I have been subtly expressing my rage with comments that C++ makes me want to be a Unity developer and I have finally understood the reason why.

My latest two inquiries into the realms of supposed knowledge in the C++ world have been about how to create and implement a quadtree and collisions using Box2D contact information.

There is a wealth of information out there about problems encountered with quadtrees, if you already know how to set them up.  There is ample pseudo code detailing what is happening with them.  There are several complete pieces of code that outline the headers and .cpp files but alas, they don’t quite fit the bill for me.

Wikipedia has a great section on Quadtrees : https://en.wikipedia.org/wiki/Quadtree

It includes some pseudo code to outline how they are made and how it is created, called and accessed.  The problem for me is that I haven’t the foggiest idea how I can implement this pseudo code into headers and then into viable functions.

Box2D seems to be amazing, but again, only if you know how to use it in the first place.  While there are “tutorials”, it seems that there is no clue how to implement the header file and not solutions for errors that arise from the inevitable mistakes in writing the code.  I know that people aren’t born with this remarkable understanding, but I am buggered if I can find out how they came across this knowledge.  It seems to be on some secret internet that I have no way to access.

Any attempts to try and locate tutorial videos only reveal the startling results that various programmers have achieved with what it is you are looking for.

My problem is that tutorials can be found for Unity that will step you through the process so that you know what you are doing and why.  This has led me to believe that, with the internet, tutorials and forums are set up for a vastly different user experience when it comes to Unity and C++.

Unity and c#/js videos will go the extra mile to make sure that the viewer knows what and why something is being done.  C++ forums are set up for experienced programmers experiencing unusual problems and how to troubleshoot those problems.  C++ “how-to” videos are almost non-existent and C++ forums do not seem to cater for inexperienced C++ programmers.  When they do try to help beginners, their language is hard to understand and their expectations of your knowledge is beyond my abilities.

Over the last 5 – 6 weeks, I have spent countless hours researching Quadtrees and other spacial partitioning methods, Box2d collisions, header bloat, Making a GUI interface, Networking, installing libraries into Visual Studio, installing omp into Visual Studio.

From those countless hours, I have achieved installing omp and libraries into VS and bits and pieces of code and pseudo code that I can’t implement.

The reason I am not liking C++ is because it feels like I am learning to code with heavy blinkers on my eyes and both hands tied behind my back.

If I should stumble across any user friendly C++ tutorials and sites, I will edit this post with their addresses, but I don’t expect you to hold your breath waiting for them.

Advertisements

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 😉

Post Mortem from play testing of WWW

From the play testing of WWW, I have notice several important events that significantly affected the outcome of our project.

The first being that out lack of feedback to the player seriously diminished the play value of our game, to the point that it seemed that random chance was affecting the outcome of the player’s decisions.  I saw on the videos of the play testing, that several times, the player had done what he needed to do to get out of the level, but the lack of feedback meant that they didn’t know they had done that thing, and continued to move around the level, trying to work out what to do.

Secondly, the tutorial level was designed in such a way that all of the implementations/restrictions of the player were in full force.  That is that the player needed line of sight to the minions before he could take them over.  This could not be implemented and a simple switching between the characters had to be implemented, which meant that puzzle components didn’t need to be used for the tutorial level in the order that it had been designed for.  A lack of communication between the programmers meant that the switch and the jumping box had almost the same shade of green and that led the player to believe that these two elements had to be worked in together to solve the puzzle.  This, along with the lack of feedback, led to a great deal of frustration and saw many players exit the game without even finishing the tutorial level.

Thirdly, the game was essentially designed to be played with a controller and not a keyboard and mouse.  As we had only one controller on the day, the 3rd person controller, which can be a pain in the best of circumstances, had to be used with the keyboard and mouse.  This was not optimal and made for rather sketchy movement.  Although this could have been forgiven if both the earlier issues had been better resolved, but in this case, it only added to the frustration that the player felt with our game.

I think a lot of these things could have been handled better with more communications between the programmers and designers and a work flow that allowed for the inclusion of audio clips to be included at the time of writing the code.  The first things written in the code should be the variables and the audio clips that will be used and neither programmer thought of including this.  I know for my part, the audio has been one of the last things I think of when doing assignments and now realise that it should be one of the first.  I personally think that another cause of these issues is that we currently have no team manager to keep the focus on the final outcome.  Everyone seems to be tied up in their own problems and no one is looking at the bigger picture.

I know that I have learned the feedback is vital to any game.  Without feedback, the player could easily think that random chance is affecting their actions.  It is doubly important for our project so that the puzzles seem to be solvable and not at the whims of a “dice roll”

I think to overcome this in the future, I will make sure that the first thing I make provision for, in my code, will be the allowance of audio clips.  By thinking about what the player is doing, I will create sound effects that will indicate what they have done, and also keep in mind things like with a switch, changing the texture of it when it has been activated or a simple animation.

While there was nothing in this level to really get my teeth into with regard of AI, I did learn some aspects for creating code for a prototype.  I also gained an understanding in a couple of areas.  That in an Indie environment, a programmer must be way more that just the tech support for the project.  I need to be more involved in the design aspects of the project and not leave all those decisions to the people who I may think the job belongs to.  I have also gained an understanding of how I need to approach my own coding, even for prototypes, whereby I can put audio and visual feedback into the game.

For my part in this project, I created the TDD and added the 3rd person controller and investigated ways to try and establish line of sight with the other characters.  The methods I tried to implement did not pan out and although I have since established them, they did not appear in the build for play testing.  I also bought in the 3rd person Camera and a smooth follow script.  I created the code for the jumping box to propel the player into the air(although it would only do that if the player rushed the box.  Try as I might, I couldn’t get it to work when the player jumped in top of it.), The prefab for the bridge and the code that activates the bridge by rotating around the pivot points, resets a times and raises the bridge after a period of time.  I also created three place holder models for all the characters, although at the last minute, we did recieve a model for the wizard at the last moment on the day before the build was needed.

The biggest way that my choices affected the quality of the finished prototype, was the fact that I had dismissed feedback as a “nice to have”, rather than a “need to have”.  By not putting myself into the players eyes, or head, I failed to see the obvious when the player could walk off a platform and fall into an area that he can not solve the puzzle from.

When we started the project, I volunteered to set up the repo, which I did following the directions of my teacher.  Unfortunately, the first time I tried to push my changes onto BitBucket with SourceTree, I encountered a catch 22 error.  I could not push because I had to pull first and I could not pull, because I had changes to push.  This was resolved by changing the repo to GitHub, being controlled by the  other programmer.  Only the two of us currently have access to this repo and any other items are uploaded to the groups Google Drive.  While Unity is the preferred application for this project, there is a problem in that one of the team has only passed Scripting 1 and has no real idea of what can be done with the application.  While he should become more used to the package as time goes by, it will be a while before he realises how versatile it can be.

The biggest things I learned from this session have been:

“Feedback Dammit!!”, in the words of our teacher.  My first thought should not be how to make this bridge work, but what sounds will this bridge make, and what visual feedback will the trigger have.  For every action the player can make, there needs to be visual and audio feedback to help him with any future decisions.

Tutorials should be designed by the team as soon as the mechanics have been decided and not left up to one person.

Communication to all team members about every decision you have made, why you have made it and even explaining why you can’t complete something, inviting discussion about things that you didn’t consider at the time of a meeting and making sure that every person contributes to the discussions.