How to: Breakable Models in Unity

Tools Required:

• 3D modelling software capable of exporting an .obj file
• Blender
• Unity

-----

To get started, make your object in the 3D modelling software of your choice (for this example I am using Maya).

Export that object to an OBJ file and import said file into Blender. In Blender one will need to go into the plugins and turn on Cell Fracturing. With that enabled there will now be a Cell Fracture button in the Objects Tool pane when selecting an object. We'll be using that tool to separate the model into tinier chunks that we'll be using as debris in Unity. Here's also where the trial and error comes in! Playing around with the setting and testing will be the best way to make a model that will shatter in the size and way you want. In the picture you'll be able to see my favored settings. Feel free to use those and see how it works with your model.

Then press 'okay' to allow the program to work through the model. Blender will begin splitting the model on the screen. Do not interact with it or close the program, just let it run its course. If the splits you decided to make aren't too small or plentiful then the model should be cut relatively quickly.

Now that we have a model with all of the broken up pieces we need we'll once again import the entire model as an FBX this time so we can use it in Unity. Once you have the FBX dragged and dropped into Unity we can start interacting with it in the engine.

Firstly, make sure the object's imported model has the Generate Colliders box checked. As the object is right now we don't have any of the necessary components on it to do our interactions, so we'll have to add them. First off, delete the Animator component of the object. It won't be needed for this tutorial. Next we'll need to add a RigidBody, Mesh Collider, Mesh Renderer and whatever other scripts we wish this object to hold. Once those are added, before proceeding, go into the Mesh Collider tab of the object and set it's mesh to the original model of the object. This model will have been included when you exported from Blender and will look like the object without being cut up. You can also freeze the constraints of the object, choose to use gravity or alter the mass of the object while we're here.

Now that we have the object created we need to affect it in the main script we have for running the level. Where the object is made in code, we'll also have to make an array of MeshColliders. This array will house all of the chunks we made via Blender and allow us to interact with each of them individually. However two extra items will be added to the front of the array that has to be dealt with. The first or [0]'th spot in our array is the model that is used as the object's collision. It is essentially an uncut version of the object. Unfortunately it is also visible so we'll need to turn it invisible so the chunk can be noticeably affected. To do this we'll call the [0]'th spot in our array and get the object's MeshRenderer before setting its 'enabled' boolean to false. By doing this we'll be turning off the rendering of the mesh, making it so we can still interact with the object just not see it. After that there's still one more object in our array that will mess with our functions. In the second or [1]'st spot of the array is the actual uncut base model of the object. It has been passed along between all of the editors and is just sitting in our array. We have to deal with it because otherwise our chunks automatically detect that they're colliding with it and explode outward. While impressive, it isn't helping us out.

So the best way to deal with this extra model is to just delete the [1]'s gameObject. Next, the best choice of action is to create a for loop that iterates over every chunk in our array. Inside this for loop we'll apply any alterations of the chunk's properties to all of the chunks. Firstly, we'll have to add rigidBodies to all of our chunks otherwise they won't interact with things as they should. As well, we need to set the MeshCollider component's 'convex' boolean to true for all of the children, thus allowing it to react to the chunk's specific model. I also recommend turning off gravity and freezing their constraints once more, just to be safe.

Now we'll need to make and add a script to the object that will be its manager when it is struck. To have the object detect when something has collided with it we'll use the OnCollisionEnter(Collision collision) method. This method automatically detects if another object is intersecting this one. So the first thing that has to happen in this code is that it has to detect that the object that is hitting it is the actual object that is supposed to hit it, instead of say something like the floor or character (unless of course you're planning for it to collide with those). So to detect this the object that is hitting has to have it's own manager. If it does, then we can use an if statement like such: if(collision.gameObject.GetComponent<ObjectManager>() != null). Doing that will check to determine if the colliding object has the ObjectManager we're expecting to collide with.

Now we can't just simply allow the object to react since the reaction it will do will be applied to the whole object instead of the chunks it collided with. We have to determine which chunks the colliding object will be reacting with. To do this we'll need to create a new array of Colliders and set that array equal to a Physics OverlapSphere. What this overlap sphere does is generate an invisible sphere on the colliding object which will detect all of the chunks that it is going to collide with. An example would look like such: Collider[] hitCollider = Physics.OverlapSphere([Here we pass in the position of our colliding object], [and here we pass in the scale or size of the OverlapSphere. I suggest using a value from 0.5 to 1, otherwise the sphere gets too large and starts making unnatural collisions]);

Now that we have all of the chunks we're colliding with we have to iterate over all of them and interact with the struck ones. We do this via another for loop of course! This time we'll iterate over the length of the Collider array we made. Inside the loop we'll use whatever physics or interactions we wish to apply to the hit chunks.

---

And that is how you create a breakable object and interact with its parts in Unity. Thank you for reading!

Meeting Ryan McBride

Ryan is a developer who has been with many of the large game companies in the Greater Salt Lake area, mainly being EA, Disney and SmartBomb. He talked a lot about his experiences getting into these places and the hiring process. He started off with a small explanation of who he is and how he started. He began in the QA department of a video game development studio. Over time he learned to code and then slowly transitioned into a developer position at the company he was at.

Next he explained a few of the difference between working at a smaller scale company versus and large company. He recommended that we all start with smaller game companies for jobs. Not only are they easier to get into but they'll also be using your skills in many different aspects. This shuffling around will give you experience in multiple places in game development and maybe help you find you niche. Then once you have suitable connection it is significantly easier to migrate to a larger scale game company. Often times companies look at your completed projects and contacts before even looking at any sort of education you may have, if checking that at all even. Then out of all of the types of video games he said that mobile was the easiest to get into currently since that market is expanding more than most, then later you can consider transitioning into PC or a console based company.

So Ryan explained to us a few good ways to impress companies. The first way he said to impress them was to pick up an open-source API and build something cool with it. By doing that we'd be getting experience working with code that is not ours and showing that we can take something pre-made and develop something neat using it. The next thing was to improve your Server managing skills since many things are moving to Cloud-based, that way you can 'wow' the companies by being prepared.

Ryan discuss that in his personal opinion these were his priorities when deciding if he should hire someone:

• People Skills and Communication come first because if you can't communicate effectively it will be hard to work with you.
• He then checks how their brain works. If someone is of a similar mindset then they'll be more open to your ideas and easier to work with.
• Finally he checks their experiences and education, more oriented towards their experiences. He explained that companies want to see that you can complete a project rather than leave many half-finished.

A few extra side notes he left us with were:

• That readable code will always be superior to compact code. Just because your code has less lines in it doesn't make it any more coder-friendly. The few milliseconds you shave off with the compact code slows down the overall development time because other coders will have to decipher what's happening, rather than having the code explain itself.
• And then he listed a few goo areas for developers to get jobs.
• San Francisco
• Seattle
• Austin

Meeting Shane Smit

When Shane Smit came in to present to us he covered a few new topics as well as going into depth on a few previously introduced topics.
Firstly he discussed his experiences in industry. Most of the time people will get tossed around to various areas of the industry to help out in multiple parts of the game, especially in smaller companies or as indie developers. So one should always be prepared to learn new concepts and be willing to learn. The industry is also heavily driven by money. This should sound like common sense but people underestimate just how important it is that video games make a profit. Every time a company agrees to make a game they, usually, have to invest large sums of money. A quote from Shane touched on this topic: "Video games are a service." Now that means that we, as developers, must make sure our games fit as a service and give the users something they're looking for. That means we have to adapt to what is currently popular with our audiences.

Shane went on to discuss how we have to make a game successful based on popularity. As previously stated, we must adapt to the constant changes of the market to make sure our games are relevant to what the consumer wants. One way of doing this is by developing games after popular movies. The hard part about making movies into video games is that they both have to be released at the same time, to capitalize on the market's hype. If they aren't released at the same time the game might suffer because the movie will lose some of its hype and become less popular. So crunch time is very important for these types of games. If the game isn't released by its expected date then the company is already losing a large sum of money.

Finally he discussed how games have to come together as a whole. To make a game successful it must be solid and complete. Now that might sound like common sense too but there are many games that are 'complete' but not 'solid'. To have a solid game aspects of the game cannot be missing or lacking. If UI or sound is missing or terrible quality people won't play it because of the general unpleasantness of it. One big aspect of the game that draws people in is the menu. The menu has to be appealing and cool to make people want to play and proves that your game isn't just a crappy student project. So making the game is actually a very small part of the designing process, with a majority of it spent making tools and making those tools work with the game.

Meeting Victor Chelaru

In our meeting with Victor he explained some of the process behind creating a game and the pipeline of people it goes through. He drew a diagram how a common pipeline would work: it starts at the developer who makes the concept for the game, then the developer passes it off to two teams; the artists and the programmers. The artists then draw up all the graphics that might be implemented in the game before passing those assets onto the programmers as well. The programmers then have to take all of this and make it into a workable game which is then sent off to marketing to promote. The problem with this way of doing this is that there has to be a constant dialog between the programmers and the artists / developer. And each dialog that has data loss, ergo some of the idea is lost from the developers original idea to what the programmer completes. Victor estimated that about 10% of the information was lost each step, so by the time it got to the programmers it could be as low as 50% of the original information that was intended to be passed along.

A fix for this, that Victor proceeded to speak about, was cutting out the middle man. Ergo he said that the developer should be as much of a programmer as possible, therefore negating the information loss. By doing this the game's core concepts are all there. As for the artists he explained how they should have an easy enough time implementing their assets into the game so they can see how it works and fix it as needed, thus removing the dialog between the programmer and the artist as well. Now this is the best case situation and it may be hard at times to even come close to achieving a pipeline such as this.

To finish he spoke about our goals and how we need to focus on what we truly need. As programmers & developers, we shouldn't try and expect what to do way ahead of time. If we try to predict everything we'll never actually get anywhere with coding it, we'll be stuck in the theory stage. Also the best feedback is from those who aren't developers or programmers, and who aren't afraid to hurt your feelings.