Advertisement

How essential Data Structure and OOPS are to Game Development?

Started by September 28, 2022 08:18 PM
11 comments, last by cozzie 2 years, 2 months ago

Hi all, I am new to Game Dev but have been coding in C,C++,C and Python, so I have knowledge about coding concepts, but haven't been coding for a year or more. I have been out of touch with Data Structures specifically, OOPS have been utilised heavily in Unity. How important is it to Game Dev and what all should you learn to get a job?

I think it's especially essential to games. I've heard arguments against things like OOP from people but the tech industry is all about OOP for the most part even when it's not game related.

In games, a lot of things are “Objects.” You need a base class for a character that all sub types derive from. You need a base class for guns. You need a base class for projectiles. Etc….

Outside of game development (And actually also in games) you have things like Windows, Buttons, Text, Network Connections, Lists, Maps.

We think of things as different types of objects and in hierarchies all the time, so coding that way is a great natural progression.

And when you're not strictly using OOP, you're using things like Composition, which in a way is OOP but without some of the built in language features.

So there's the usual OOP concepts like Inheritance, Polymorphism, and Encapsulation that you see in all the textbooks. There's composition which is a kind of way to get OOP without using OOP. There are the typical data structures like arrays/lists, maps, trees, etc… Knowing Big(O) of various algorithms is usually essential to passing interviews.

Then there's actually the real world outside of passing an interview. Unfortunately interviews are like a skill of their own you have to be good at that have almost nothing to do with being good at your job, but you have to be good at both to even get the job in the first place.

Advertisement

I would say knowing about data structures and algorithms is essential. Usually these are not language dependent and as such can be used in any language.

OOP is used in games but so are other patterns like Data oriented design. So knowing them always helps.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max, Watch Dogs: Legion

The Faster You Unlearn OOP, The Better For You And Your Software

https://www.gamedev.net/tutorials/programming/general-and-gameplay-programming/the-faster-you-unlearn-oop-the-better-for-you-and-your-software-r5026/

So for Game Dev jobs, you should know Binary Search, Trees, Linked List, Stacks? And if, then how much is good enough?

The way I am thinking is, it's not an SDE job, they are looking for Game Engine knowledge and Coding Knowledge. So I just wanted to be sure about the amount one should learn about these things, because its not useful to learn things which no one will ask or is necessary! Looking for some advises, thanx!

Games very much are software, if you are looking at a coding role on a game team that very much is a software engineering role. So you would have to know the same things.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max, Watch Dogs: Legion

Advertisement

I manage a Telegram group for cuban Godot developers. Most of the problem of newbies are mostly derived from knowing nothing about programming (we have one that insisted he would make games without learning to program first, just copying code from tutorials) and knowing nothing about data structures. You tell them “need to use a singleton for that”, “a what?”, and how can you help somebody who doesnt knows the basics?

Data structures are everything. The classic statement is that if you show me the data structures I can tell you your algorithms; if you show me your algorithms I can tell you your data structures.

Many people - ESPECIALLY STUDENTS and inexperienced developers - equate “object oriented” with a particular style of programming. That specific style, implemented naively, can have terrible performance in certain circumstances.

The concept of object oriented programming, that is, the theory that you have opaque blobs of data and you have operations you perform on those blobs of data, is quite sound. However, the approach many people use is that each tiny discrete thing should be an opaque blob of data, where a more practical real-world approach tends to be batches of data and collections of data. That is, don't do one thing hundreds of times, do a batch that contains hundreds of items. It is still object oriented, but more intelligently organized.

And since you asked about jobs, at the entry level during interviews I will absolutely ask you about classic data structures and algorithms. I expect that junior developers (especially those fresh from school) will have core algorithms and their matching data structures down reasonably well. At the experienced or senior level I won't even mention them but still expect them to show evidence of smart structure and data organization in everything they say and do. If I start talking about a tree structure I'd expect you to know the corresponding structures, if I start talking about dynamic arrays, about heaps, about deques, about hash tables, I'd expect you to know the structure. At a senior level I'd also expect you to intelligently speak on the performance implications of each in a range of scenarios.

@rogerdv you are right! So pretty much everything in it is important to know, know matter if its used further or not, for interview its essential, right?

roopesh23 said:
matter if its used further or not, for interview its essential, right?

I hope not! A bad interviewer might ask you questions that are irrelevant to doing the job.

As a programmer every time I devise a new interface, create or extend an implementation, or otherwise manipulate code, in that moment I'm adjusting data structure, algorithms around the data structure, or both. There are some which are core that are implemented all the time. They're so commonplace that most people don't even think of them, it's simply “adding items to the class”, or “adding a function to a base class and the tree”, or “changing the composition of this object”. These are so core, so fundamental to understanding code, reading code, and writing code, that they usually go without saying. Failing to understand it means you fail to understand procedural code as it has existed for the past 60+ years. If you don't understand that languages like C are object oriented, then you fundamentally don't understand it.

This topic is closed to new replies.

Advertisement