Here's How You Should Be Thinking About Data

[Music] hey there level 2 game devs i'm charles and in this video we're going to talk about working with data and data structures in unity this video is a collaboration with jason's story and our goal is to give you a better understanding of how you can structure your own games data in a way that's easier to work with and extend when making games one of the core building blocks you'll find yourself using is data data is nebulous and unconnected it usually doesn't have meaning until you structure it into something that tells you the relationship between it and what it represents here's an example of some unstructured data in unity these data structures which is where the name struct comes from by the way are meant to represent things they're often also known as records as they're similar to a file recording facts about something in fact another name for a record is a pod which stands for plain old data which brings us full circle here's an example of structured data in unity structured data like these records are easier to reason about share and store so records are one type of data structure which contains related information that you care about usually though you care enough about structuring your data because you intend to have a number of things that match the same structure probably the most common form of data structure is the array the array has a similar job but instead represents a logical collection of elements here's an example of a data array in unity this is a way of storing data in contiguous memory blocks in short instead of logically grouping your compound data like with the record example you can store the data in lists and access the elements by id just like this for example this kind of data management can be very performant and this contiguous memory concept is actually a core part of unity dots which is aimed at high performance use cases but it can get very unwieldy and hard to reason about the reality is that in software everything is a trade-off and a common concern is where do you focus on performance versus where do you focus on making the code faster to develop easier to debug and more resistant to change in general though a rule i like to follow is to ask myself what the core loop of my application is if something is run rarely like the loading of objects into memory at the start of the application or changes rarely like altering the stats of an existing weapon at runtime i usually favor making my application easier to modify maintain and debug until performance becomes an issue if it ever even does following the pareto principle there are usually one or two changes that will have a big impact on improving performance and those big things are usually in the core loop so what does it actually look like to structure our data using arrays before we look at that if you're interested in this type of content then i'd like to invite you to sign up for the level 2 gamedev newsletter once a month we'll send you an email with curated content that's designed to help you take your game dev career or hobby to the next level and help you keep your finger on the pulse of what's going on in the industry we'll share content from infallible code thousand and and some of our friends in the space like jason story if that sounds good to you visit the link in the description and sign up today alright so what does it actually look like to structure our data using arrays well here's an example in unity now we have data that is logically grouped into records we can add new entries and access their elements by array index there's one small problem though a data structure's job is to store and maintain elements in this case our weapons whatever's handling the data structure is taking on all the responsibility of managing that data so why is this a problem well let's say i gave you a list of a hundred weapons to add to the game how would you do it i assume you'd begin typing out all that information well let's say i change my mind and give you a hundred different weapons i want you to replace the original 100 i gave you off you go right are you done yet okay i changed my mind put the original 100 back as you can see having a way to store and index data is one problem managing that data is another this is where we get to the difference between data structures and objects before we solve the problem of filling out the data let's solve the second problem i asked you to fill out one set of items then another then go back to the original the problem is that because you're changing the elements of the data structure you're making destructive changes in other words putting in new data destroys the old data you have no way to go back to the old data without redoing all of that data entry this is because to you this specific set of items is an important distinction it's something worth naming and storing so let's fix that this may seem like a pointlessly small script but it's surprisingly powerful in our hierarchy we can now comfortably distinguish between different types of weapons and despite all these changes our original code actually doesn't look all that different as you can see here now instead of dealing with the data structure directly we have decided that weapons are a concept that we care about and so have made it a dedicated object which brings us to the difference between objects and data structures data structures simply store data in general they're considered passive in contrast objects add behavior to that data allowing you to perform operations and make it easier to use and work with say for example a common request was to ask which items a player could afford like in a shop for example we could use this snippet of code here this brings us to an interesting point now that we're wrapping our data structure in an object a weapons object we should no longer be talking to the data structure at all any operations we need to perform should be things that we choose to allow or expose on the weapons object itself so let's make a few small changes now our data structure is private we can't access the items directly instead we can ask for data by calling public methods on our weapons object which are helpfully listed by our intellisense and called like any other method so we now have a way to talk about weapons what they are what kind of questions you can ask about them etc we've solved the problem of creating different weapon objects and being able to drop different ones into our script and swap them out without having to redo any work of filling out the elements the other problem still exists though we still actually have to fill them in this is going to be a bit of a nuisance if we have 50 to 100 items we want to create now we get to another interesting property of our weapons object we've encapsulated the concept of weapons so now we don't know anything about them other than the methods that they expose to us to interact with in short we've completely separated the creation of data from the use of data this gives us a lot of flexibility for example a quick way to solve our problem is to use a spreadsheet so here we have a standard google sheets document we can add as many items as we want share it around and have it edited have a lot of different sheets but how do we get that data into unity well one of the common spreadsheet formats is csv so let's make a version of our weapons object that knows what a csv is as we can see here now the actual lines of code don't really matter here that's not the point of the exercise the only important thing to note is the top line csv weapons derives from weapons and is a version of the weapons class that's csv based over in the inspector it doesn't look all that different from the original weapons object only now instead of having to manually type out all the elements if we right click and press load it'll automatically populate our items for us and what code do we have to change in our example script to work with our new csv weapons none whatsoever because a csv weapons is just a different type of weapons object but it's still just a normal weapons object at the heart of it so in summary we've gone from a loose collection of data to structured data into records to grouping those records into a data structure called an array to wrapping that array in an object that adds operations to the data and handles interacting with it why go to all that effort well where we are now if we want to completely change the data like for instance if we wanted real data for production and test data for development we can do that if we want to use a different method of storing and changing that data like a spreadsheet we can what if instead of a spreadsheet that data came from i don't know a web service maybe even a database what if we had database weapons csv weapons web service weapons json weapons xml weapons heck even scriptable object weapons it doesn't matter we can make that decision about where the data comes from completely separately from how we use it the data is now handled by an object that no matter where it comes from makes it look like it's just an in-memory collection that we can interact with that is the definition of the repository pattern that's what a repository is it's taking the various interactions that surround data and separating the requests for info about them from the source this is why in general the question of what is the best way to store my data or should i use json is not as important a decision as people think what matters far more than where you store your data is if your architecture allows you to change that decision to best suit your needs without causing you a lot of work or headaches as it stands now we can change swap and add as many new sources of weapons as we like all the while the rest of our application doesn't care at all this is not only what the repository pattern is but why it's important imagine going back to our early examples imagine having 5 000 weapons in your game now imagine having to change some of them there's still a lot more to cover with the repository pattern most notably the editing of data this is a different problem and is usually done by combining the repository pattern with another pattern called the unit of work but we'll cover that in another video if you enjoyed this video and found it useful you'll definitely want to sign up for the level 2 game dev newsletter using the link in the description also don't forget to comment like and subscribe thanks for watching and as always i'll catch you in the next video thank you to all of my supporters and a special shout out to alwyn caravella due to dustin jennifer irwin nicholas monter bungo soroff chatterjee umet sarin lucifali castle and urizer thank you guys

Channel: Infallible Code

Views: 15,920

Keywords: data structures, game development, game programming, programming for game development, unity3d, unity 3d, gamedev, game dev, game coding, unity coding

Id: KH_rXIJlMKU

Length: 10min 56sec (656 seconds)

Published: Fri Oct 08 2021