Friday, 23 October 2015

Weekly Summary: 06

This weeks focus was on making the prototype to a playable standard, I ran into a lot of complications so I had to spend more time it than I thought I would have. The demo works as a mechanic taster, in which it shows people what the game would include, I'm thinking of breaking the mechanics up more into levels specified around the mechanic, but for now the level is there to show what the game could be.


To start, here's a photo of the intro sequence to my game, I decided to keep the character simple as they style works well with what I'm trying to achieve.


The character is made up of basic geometry and a few different textures, theres an alpha map on the outer sphere and eccentricity on the inner to illuminate the character. A light is inside the spheres, this light get's brighter when the character collects the light pickups in-game.


I worked out the second section of the demo, as you can see in the illustration below the player starts to head underground and is faced with a few puzzles and a dramatic change of mood when they reach the area marked as 'teleport'.


I also added animations to the level, certain areas of the level are played more than once, so when you reach back to certain points a second time the area will have changed to allow for a new route.


This blueprint is for the first blockade of the level, to allow the player passage they must have collected all 7 lights in the previous area, when they do the blockade will be removed as they approach it.


To add a puzzle platform to the game I decided to create box-objects that can be moved by the player to do things such as create steps to walk up and trigger doors and events where the player will have to complete a task in a certain timeframe. at first the box moved out the way and wouldn't push in the right direction, I simple edited the boxes preferences so that it could only move on the Y and Z axis.


I wanted to create a sequence in the demo where the player can feel a sense of freedom, kind of like a metaphor from momentarily freeing themselves from the crutches of darkness, I was thinking that when most of the lights are collected there will be a part where the character must dodge things and collect the final lights while having their movement heavily modified. I did this by creating a trigger that adds something to the players movement and then another than reverts it when they get to the end of the sequence.


Here's the trigger, the size ensures that the player can not go over or around it. The only issue now is that if the player re uses the trigger it will then add more speed, I need to find a way to cap the walk speed.


Here's an example of how the set up would work, the player enters the speed boost, completes the segment and then their speed is reverted bad to normal.


 I also added an underwater segment to the level. To allow for an extended axis of movement while in the water I simply set up a condition to check if the character is inside the physics volume that is tagged as swimmable. It then overrides the jump buttons to allow the character to move up and down.


Here's a screenshot of the character floating on the top of the water.


I've included narrative in the game by creating a repeatable prefab sequence where a 3D widget is made visible and then slowly floats away. I ensured to destroy the actor when the sequence is finished but there is an issue where the text blurs and stays at the top of the screen. 


In addition the the playable mechanics I created UI menu's to make the game feel more like a viable product. I created a simple pause screen, when the player presses 'P' the game will freeze and the pause UI will be showing, when continue is pressed the game will unfreeze.


I will be providing a video update soon with a play through of my level, this will be included in next weeks summary along with the testing results.

In preparation for testing I have created two google forms, one for before gameplay and one for after. This was inspired by a recent QA testing experience in which the response of the player was monitored before and after playing the game.

Pitch Document:

This week I also created templates for the pages of my pitch document.



I'm trying to keep the theme throughout my design. I will get these looked at before I move on with the documents.

3D Practise:

For a bit of practise in 3D I created some simple assets to get more of a feel of the pipeline for creating PBR material based assets.

I decided to create something simple, so I chose a cardboard box using one I have as reference. The goal was to make a model that retained a lot of detail but had an incredibly low poly count.

I started out by creating a basic box in Maya, ensuring that there were no three sided polys so that the model would subdivide without any issues in Zbrush. I then exported it into Zbrush, sculpted the detail and baked the High poly model onto the low poly model in Maya. I also created an ID map for dDO to speed up the texturing process. 


Next I created the maps using a mixture of Photoshop painting and editing, and the Quixel suite to generate PBR materials. there were no presets for cardboard so I used one of my own skin textures (as the texture slightly resembled cardboard grooves) and then edited it to suit my needs.


I went through a few iterations until I thought the texture was to a useable standard.


Here is the final outcome. I plan on going back to the texture and changing the logos so that I could actually use this in my work. Next I will be working on LOD's with the challenging of getting the box below 10 poly's.









Wednesday, 21 October 2015

Research: Management structures

During a lecture based around management structure I learned about something called LEAN development and how to use it to create my MVP (Minimum Viable Product) to allow public feedback and useful iteration. What I will research is the differences between LEAN and AGILE management and which one I want to use throughout my University projects. I will use my existing knowledge to compare and contrast the two different types of management while showing what I have already used for my current project.

Throughout college and University I was introduced to SCRUM management, a cycle in which you relay information about tasks completed, not completed and ready to do are relayed to the team on a daily/weekly basis both in person and using something called a SPRINT sheet. A SPRINT sheet is a document where you document exactly what you are doing, have done and will be doing while using SMART targets to describe everything. A template of what this looks like is below.




Alongside this I create a spreadsheet document called a Gantt chart that allowed me to follow my progress of the sprint sheets on a weekly basis, currently I have created a Gantt chart for this project as it came in handy when expanding the chart from a weekly thing to a daily thing, allowing me to tick off what I have finished and easily see what I need to do.



LEAN development is a management structure in which you build and release as fast as possibly to get something out to the public, get feedback and then change the game depending on the feedback, this process is repeated until the product is deemed worthy by you or most likely the public. This allows you to create a Game (Minimum Viable Product) easily with little funding. It also allows you to create a game to your constraints, which means based around your own skills, you must constantly ask questions like ‘Do we need this?’ and ‘What can I strip it down to?’ to ensure you’re getting the absolute necessities for your game and nothing more, after all it’s all about making your game coherent.


The difference between LEAN and AGILE is that LEAN allows you to iterate with feedback fast, while with AGILE nobody will see the game until testing phase, so if something isn’t right with the game, it’s unknown for a long process of development, so generally LEAN saves a lot of time, but for single play-through story games such as limbo it wouldn’t be a great structure to use. This is because people aren’t going to replay a game that isn’t made for replay value.

With my current project it wouldn’t be possible to use LEAN development completely due to the narrative nature of the product, but I could still implement it by doing closed testing to ensure it doesn’t reach the public. If i did this often I could still save a lot of time and increase the desire of my product. Throughout University I feel like both styles will come in handy for different projects, so I will keep an open mind when deciding on how to manage my projects.

Monday, 19 October 2015

Research: Apples Approach to Polished Design

Due to my major influences being games such as Journey, Limbo, Never Alone and many more I thought a lot about what they have in common. I came to the conclusion that they all have a very polished user experience. The games aren't crazy big, they include what they require and bin everything else. The biggest influence for me currently is Apple. Having looked into their design before I know that their UX design is very upper echelon, and I want to find out how and why that is so that I can use the information to create a polished user experience for my audience.

"Apple products are often defined by small details, especially those around interaction"

When I think of an apple product, I think of a single polished item that is much more desirable than another product that has 5 different variants but just aren't that great. The polished design of one product far outweighs the desirability of a multitude of choices, this is used in everything from phones to watches. Obviously the magnitude of this design can't be achieved with a team of one, but it's definitely possible to use take inspiration and create a small, very polished area.

Apple likes well-rounded designers, the type of designers that fiddle with code in their spare time so they understand how the pipeline works, they don't have a set of rigid tasks they must complete as they believe you can not innovate if there is a deadline involved, instead they will create ideas, and sit on them until they find a context to use it in.(fastcodedesign.com)

"Every product at apple starts with design"

UX can be the be all or end all, my game could look cool and have sweet mechanics, but if the movement and camera are clunky then people will put it down and never return. Let's take the smooth scroll interaction for example, when you scroll up and down on a macbook, the screen follows and fades, it feels organic, like the trackpad is an extension of your hand. This is exactly what I've tried to re-create with the camera movement in my game. As my character moves the camera delays and then follows, and then transitions to it's new location.




Apple always maintain a coherent design vocabulary between their products, originating from the "Snow White" design language Steve Jobs invented with Hartmut Esslinger of Frog Design. This design was used to create the apple products from 1984 to 1990.






In conclusion everything in my game must maintain a similar visual language in conjunction with my colour choices. If everything is kept coherent and simple then my prototype will not only fit criteria, but it will be a product than I can work from, iterate and maybe even release as a full game. Considering design and functionality in unison from the start will entitle me to grow my game so that there is a balance, similarly to the balanced user experience that apple products offer.


Reference -

Weekly Summary: 04-05

Early on in week 4 i created a piece of art work to help myself visualise the game in my head. It helped me have somewhere to work from while working as a great intro art piece for my pitch document!



It was difficult deciding on how to make the text look, as I'm going with the working project name of 'Light' I thought I'd make the logo represent a sort of light bloom or blur. Here are a few different logo's I created.


I decided to go with the second one, it looks a bit withered and the effect just looked great to me, the rest are either too subtle or too in your face.

Unreal Prototype:

So this week I decided to start making my game in a different version of Unreal, so that it's compatible with the computers at University, this was a great idea because it's good to re-create everything at a better standard. I'm planning to have my prototype finished and tested by the end of the week so that I can spend the last two weeks tweaking it.

I created a few mechanics, the light collecting mechanic is currently working great, basically the main collectibles in the game are lights, the more lights you get the brighter the level becomes, but I still need to make it so the level gets brighter, but I do have the collectibles hooked up to a HUD item that tells the player how light the level is becoming.



I don't know whether to apply the lighting change to the areas of the level where lights are found or the overall light intensity that surrounds the player, or maybe even both.

I've decided to go towards the idea of turning my game into a sort of therapy tool that people could possibly use to help themselves. I came to this idea after having an individual tutorial this week and going through my ideas. Having had personal experience in the area of mental illness it helped to bounce my thoughts and ideas off somebody who had similar experience. Now I need to start researching into how I will turn my ideas into reality. I definitely think I need to consider the meaning behind each mechanics and explain them so I've decided to create a research post dedicated to explaining my mechanics.

The design of the level is starting to make sense in my mind, this was the first iteration of my level design. The level uses to much backtracking to keep a consistent story, therefore I'm going to re-design the level to keep moving forward instead of getting the player to replay a lot of the level. I will still keep this idea for some areas.




I noticed that I constantly used blue, green and yellow in my designs, which makes a lot of sense, blue represents cold, shyness and anxiety, while green represents life and yellow represents warmth. To test this theory I created a questionnaire and asked around a pool of about 35 people what the colours meant to them. I was happy to hear that over 80% came back with similar or exact meanings. Using this data I created a colour gradient map for my game and illustrated the core game loop.




With these colours in mind I will recreate my level design to cater to gameplay based around these colours.

Maya Practise:

This week I did a bit of practise in Maya, I decided to start working on an endless runner game just for a little project so started churning out a few models to improve my skills.






I'm going for a more realistic style so it gave me a chance to test out PBR techniques. The final poly count is 300 polys. I used Ddo to texture and baked the normal map using a high poly model in Maya. Overall the pipeline worked well and didn't take me long at all, although there are a few issues with the model such as the white edges but that's just an issue with the Specular that I can easily sort out.

As a bit of fun I also made a dirty sink, in effort to start recreating a scene I made not long ago for my portfolio, I didn't document the creation of it but this is a render of how the sink looks.



I think I need to cut back on the scratch damage as it's making the material look less reflective.


Portfolio:

I recently started to learn HTML and CSS in order to make my own portfolio. This week I worked on the home interface for my website. My goal is to make the pages incredibly simple but very interactive. Here's what I have so far.



Soon I will upload a proxy website so that you can see how the website is interactive, but currently the web hosting I use is having issues.


Coherent Worlds Lecture:

Today I had my introduction lecture for my next project, which is a 3000 word Essay about How games create coherent worlds that we believe when we play and how they draw their influences from the history of entertainment through games (fun fairs, carnivals, war games).

this topic interests me deeply, I find it very interesting how the earliest of games such as Circus Charlie were so heavily influenced by the likes of Carnivals. Back when it was tech teams creating games it would be quite difficult them to come up with new artistic concepts, so it makes sense that they drew influence from existing entertainment platforms and just changed up the medium. This was the start of interconnection between analogue and digital entertainment. This was of creating games has become very standard, generally people do always tend to match the narrative with the design and mechanics, otherwise the appeal of the game just isn’t there. 

The idea of drawing reference from entertainment platforms to create coherent worlds bought me back to the concept of Flow in video games, during the lecture I thought deeply about a certain thing that was said about amusement parks, it was about how they were initially designed all around where and how the public manoeuvred around the park to drive them to certain points of interest ,and how to have them reach different areas of the park at certain times. This reminded me of how I used to do the exact same thing as a child while playing theme park world on the PS2. The entire game was based on the flow of success in the theme park that you design from scratch. That game is  good example of direct influence from past (also present) entertainment. The game worked because I believed that I was the manager, that I was actually making my own theme park, there’s no better feeling than having a smoothly running park… well until it get’s too repetitive, that’s why the game progresses in difficulty as the player progressed, to maintain flow.

It is well known that human beings as a whole feel the need and desire to create where and when possible for many different reasons, for entertainment, training, competition, the list goes on, it’s part of our instinct. As a child I would grab anything in my grasp and delve into a portal of my own imagination with it, all things from simple cardboard boxes to board games specifically designed for people to play, we know to do this from a young age, I feel as we grow older we learn how to turn our imagination into coherent worlds that we can share and experience with other people, and gaming as a medium is an incredibly effective way to do so.

I was interested to learn that the medium of gaming actually appeared from Military technology, obviously they were not initially as grasping as today’s games but it did spark interest, and that interest grew over a short amount of time. 

A recent rise in game design is the introduction of LEAN development, which is a managing strategy where people can easily create games and release them to the public in it’s alpha stages, and repeat the cycle while applying public feedback at the end of every cycle, this allows developers to cater the the desires of their audience (the reason behind the constant pummelling of pre-alpha releases on steam). This is taking off now, but it not a new concept. I was interested to learn that Charles Dickens adopted this platform with his weekly release of something called “The Penny Dreadful” The weekly Illustrated stories were very accessible to the public, something Dickens used to his advantage. He would change the direction of the narrative based on the views of the readers, this is something you’d see in the likes of Soaps and comic books today, so his influence is still heavy in today’s medium of story immersion and design.

Overall I learned a lot from this lecture and will immediately start to research into further things for my Essay.


Friday, 16 October 2015

Research: Plan, Practise & Improvise

Recently I watched a video by Extra Credits called plan practise and improvise, these are three different types of play found in games. I want to figure out what and why my game will use these styles of play in it's design so that I can use this categorisation system to my advantage. By doing this I will be able to structure my level design around adapting to the styles of play I choose to continue with.

First let me introduce the three types:
  • Plan - Most things strategy based involve planning, stealth games are a good example genre, having to plan your movements to gain a higher score.
  • Practise - The perfect example of this is guitar hero, you master gameplay through repetition, allowing you to learn and expand knowledge and be rewarded for your practise.
  • Improvise - You have no idea what's coming, you must continuously adapt the the situation at hand. Anything made to be beaten in one go is generally improvisational. 
(images from extra credits)


There is no set formulae for implementing this into games, you can use it how you want, some games such as Heavy Rain would rely a lot on you improvising as you move along the story, throwing quick fire decisions at you as you progress.



As you can see in the image above, the game throws quick time events at you, while also showing what button is coming next to allow the play a tiny amount of planning time, this is a great example of the two types of gameplay being mixed together.

Other games such Final Fantasy would have you incorporate all three, practising by leveling up your characters through mind-boggling hours of grinding, planning before a battle to ensure your tactics are set up right, and improvising, when you inevitably get caught off guard by a random event and get slaughtered by the opposition.



My game is similar to limbo in respects of narrative being the driving force of the game, meaning most of my game would probably have to rely on player improvisation, but if I'm giving the player an array of re-useable power ups then I can also include some elements of practise to allow them to experiment when identifying the effectiveness of the power ups in different scenarios. this will also allow me to change the fluctuation of difficulty of the game as the player progresses, directly linking in to the main theme of FLOW in my game. By play testing and generating user feedback I can create a level timeline in which I know where the player will have ease and difficulty of playing the game and how to transition between the two.




In conclusion I will be incorporating improvisation and practise at an approximately 80/20 split, throwing quick decisions at the player while also giving them the chance to explore between these scenarios by practising with the selection of level-traversing power-ups.

Research: Wall Climb Mechanic in Unreal

This week I practised UE4 by attempting to create a wall climb mechanic, the purpose of my research was to analyse if the mechanic would difficult to implement while contemplating if the mechanic was coherent to my design, forcing me to decide whether the mechanic was even worth implementing.


What I set out to create was a mechanic that allowed my orb character to climb up certain walls when a certain button is pressed when next to the wall, i thought this would add a new dimension to my level, in similar light to the world rotation mechanic in fez.




I set out to create the mechanic by following a tutorial (https://www.youtube.com/watch?v=QthdLYxqLEA). I quickly found that the blueprint design was incredibly complex for my basic understanding, so instantly i knew that I didn't really understand what I was creating. After getting so far with the tutorial I had a character that moved in the completely wrong axis at all times, completely messing up my control scheme. What this did allow me to do was test how it would feel to move in that axis.

The mechanic felt really strange and didn't really fit with the game, so I decided to take it out, it just wouldn't be fun for the player, if I'm trying to create a mood where it's dark, scary and you don't know where you're going, it would be too confusing to add another level of movement to that, it just doesn't make sense, but now I know that it definitely wouldn't work.


Through failure I learned that it's not necessary for me to go to extreme measures to just implement 'cool' mechanics when there is no reasoning behind them being in the game, if I can just use a jump pad and jump mechanics to help the player traverse, then why would I need to complicate it with more things, this defeats the point of creating a simple game. Instead of thinking about more mechanics for the character I am going to spend my time thinking about how collectibles work and affect the games environment.

The mechanic itself had no connected meaning to anxiety that would help it mould into the game, therefore my final conclusion is to completely remove the mechanic and focus on other ideas I have for the environment.


Weekly Summary: 03

Pitch Document Lecture: 

Going into this lecture I had a few ideas on how I was going to make and present my pitch document, in my head it was still fresh, very basic and probably wasn't what the tutors were looking for. This is a bit of a conclusion I gathered from my notes.

Last year I created a GDD (Game design document) entailing mass amounts of detail to do with my game idea, and although I received a very high mark for it (90%) I now understand how dated and unused that style of game design is. Initially I thought to recreate the document and WOW people with the detail, now I see that the document (if it even is a document, it could preferably be a wiki) needs room to breathe, it needs to be living, changing form as it progresses, which in honesty is a new and great concept for me to take in. 

A Design document can't possibly breathe when it's meaning is to set the design of the game in stone, this has resulted in the death of the GDD, you can't live if you can't breathe, which brings me to my next point: death by boredom. Most importantly it doesn't allow for failure, and failure is necessary for growth.

In reality nobody is going to sit and read through a 50+ page document and LOVE it, it's just not feasible, in fact it's just plain boring. I need to make my pitch document clear and concise, while also making it very pretty (to cater to the 90% of us that are attracted to shiny things, which includes me). I have exactly 10 pages to do this in, so now I need to devise a structure for the document to ensure I get all necessary things in there.





Idea Generation: 

This week I set my mind to finalising on an idea to work with. Within the space of a few days I bounced through a few dozen small sparks to conclude on a game about a serious topic that I care a lot about, but before I go into it I'll throw a few ideas at you that came before, to show how these initial ideas inspired the game I concluded with (obviously it has a lot of room to grow still).

I created a game level last year in CryEngine, so initially I knew not to set my scope too wide. that means no RPG's, MMORPG's or complicated mechanics, I need something simple that will boast 2-3 polished basic mechanics that are coherent with the games functional design.


(Game I made during second year at Confetti)

I sat down with the intent of coming up with some game ideas, trying to make them as out there as possible, here's just a few - 

  • Game about making music with star signs - actually pretty interesting.
  • Game about helping disabled people increase hand dexterity - topic I'm very interested in, would require much research and iteration.
  • Sim Game about growing an ant colony in different types of areas, have to do things such as get rid of large objects to clear paths, kind of like a CIV for ants.
  • Trippy game based on Ludic dreaming, mechanics revolve around controlling dreams.
  • Thriller game about discovering a civilisation of dead fairies in a forest.
  • Arty deep game about a river that i famous for suicides.
  • Game about a presentation room, you must make sure everything goes smoothly by juggling lighting, changing slides and various other presentation things.
the list goes on...


So my first idea was a game about an octopus in the ocean, the idea of the game was that you had to find something to latch on to and kind of just move it across the ocean to reach the shore. The game was supposed to be very arty with a deeper meaning, but it didn't get very far until I realised that I would have to delve into fluid dynamics and heavy math to make it work, and I kind of wanted something with a bit of gameplay for my first game.



My second idea was to take my game I already made and turn it into a 2.5d sidescroller, but I quickly shut this down after talking to a few people and realising that I should make something different and broaden my horizon.

My third (and final) idea is a therapy game about an orb that represents anxiety, you must collect lights to make the world brighter. I thought about the idea and expanded on it by creating a mood board.


The purpose of this research was to generate ideas about the colour, shape and mood that I wanted the character to express. I created some concept art for the main character just to help visualise my thoughts from picking apart the mood board.



This helped me think about what I want to express through the main character, I came to the conclusion that it needs to come across as soft and shy, so anything that looked energetic or aggressive just wouldn't cut it. I concluded that the top middle image would act as placeholder for the character.

UE4:

I've noticed this week I've spent most of my time in the Engine trying to solve simple issues that someone adept with the engine would know, but that's the thing with this type of software, there's a million and one little tips, tricks and conventions that you have to learn by trial and error.

I have managed to practise and play with the existing blueprint levels to create simple movement in characters. Here is a concept of my idea.



the player can move left and right, and I resolved a tricky issue where the camera zooms when the player goes behind geometry by removing collision testing in Spring Arms settings. This will prevent any camera clipping when geometry is in the way of viewing the player character.

This single creation has given me a few ideas about where I want to go next with the game. I will update next week on where I am with the prototype.


Weekly Summary: 01-02

Switching courses has been a tough challenge. It has required me to learn new workflows and techniques very quickly. I'm at the stage now where I feel that I have almost caught up and can start producing a strong amount of quality work on a daily basis.

Due to having to catch up, the first few weeks have been based around skill-building.

Maya: 

Having to switch from 3DS Max to Maya hasn't been a challenge, it seems as soon as you know one 3d package it's very easy to use another. My main source of learning material for this was a small course bought on a website called Udemy which directly showed me how to do things that I did in 3DS max in Maya. Very helpful for a starter tutorial. 

After I got the hang of maya I set myself three tasks. The first task was to create an environment prop so that I could learn the UV process in Maya. This was my outcome:

This turned out pretty great, it allowed me to understand how to set up maps such as Normal and emissive so that they work in maya. I researched into lanterns to find that this was a 1920's Circa lantern, battery powered with an oak finish.

Next I decided to create a low poly app-game asset based on sci-fi space. I chose this because I don't really have much practise in designing that area of models so thought I'd give it a try, this was what I came up with: 


The space vessels from Dragon Ball Z were a large influence in the design of this model. It taught me not how to be efficient but how to rebuild as you go along and not stick to the design you did on the first try, I mist have changed parts of the model a few times while working through it, bear in mind I spent no more than 2 hours on this piece.

The final task was to ask someone what I should make and just wing it, luckily the first response was 'make k-9 from Doctor Who' which was pretty fun to make, here's what I made: 



Throughout the creation of the robot dog I was able to learn a few more things about editing meshes, such as tools to add more vertices and so on.

My next steps with Maya are to figure out the baking workflow and to learn some high poly techniques, this shouldn't be hard as I am quite used to it in other 3D software.

Zbrush:

Before this course I had never used ZBrush, so this meant that I needed to delve into a multitude of tutorials. I opened up the introduction course on Lynda and watched all of it, over the course of a few days I was able to learn the interface and understand a few concepts. Currently I am creating my first asset in Zbrush. 

I decided to create an animal, an incredibly tiny animal. While watching 'the Cosmos' a show about space, I was inspired to research a remarkable creature called a 'Tardigrade'. This animal is no bigger than a millimetre long, yet when zoomed in, the detail of the animal is breath taking, so I decided to sculpt it, but then Zbrush crashed and I lost it, which forced me to learn how to properly save in the program.

I decided to try something a bit different, I learned how to import and export between Zbrush and Maya to create a simple pillar. This would teach me how to sculpt broken geometry, teaching me a lot about different brushes and how they work. this is was I created:


(Textured in photoshop & dDo, rendered in marmoset toolbag)

The workflow was incredibly fast, I managed to make the whole thing in less than 2 hours and make it look pretty good, while keeping an efficient poly count (>200 faces)

Now I am going to focus on learning how to retopologise in Zbrush and Maya, and then bake the sculpt onto the low poly model.

Research: 

PBR (Physically based rendering):

I've started looking at PBR, seeing as it is the standard in the industry currently. Most current engines, even the new Unity uses PBR to the users advantage! Having fiddled with nDo and dDo the past few weeks I understand pretty much how to manipulate PBR.

Obviously everyone in the 3D industry understands the basics of Diffuse and Specular (Diffusion and reflection). The official PBR theory marmoset post explains their physical distinctions. 

Here's a little bit of basic render theory:

Let's compare light bouncing off a surface to a ball bouncing off a wall, if the wall is smooth you're going to get a smooth angled bounce, so smooth that you could pretty accurately assume where it will go, this would be a mirror-like reflection (Specular is derived from the latin for mirror). As the post says, 'mirrorness' is a bit more awkward to say than specular. Different objects will reflect and absorb different amounts of light, if an object is more diffuse, subsurface scattering will occur, to explain this imagine throwing a ball at a very damaged, jagged wall, it is a lot more uncertain where the ball will bounce and the velocity of the ball.


PBR takes this theory and expands on it, creating an engine with more reasoning behind the detail and light of surfaces, allowing us to create more specific parameters for different materials. As the article write Jeff Russell states, it's hard to actually give an explanation for PBR, because it is a loosely defined term, but I'm going to be doing more research to come to a personal conclusion.

(Theory and image from https://www.marmoset.co/toolbag/learn/pbr-theory)

References: