Jump to content
Sign in to follow this  
  • entries
    8
  • comments
    8
  • views
    12249

advanced object oriented programming and modern c++

Sign in to follow this  
GamerX1221

4017 views

Techniques that "professionals" use are just that, techniques. There are a variety of best practices used in the industry that can definitely provide you a programming advantage. These have been determined mostly by, and for good reason, by individuals for together in large teams, or even good size teams. Object oriented programming allows for modularity in code. In c++, you can use and reuse modules depending on how you structure them, to be adaptable for different kinds of code. Before you start writing your code, it is up to you to determine what parts of your game library you want to be reusable or engineered that way. If you are already an excellent programmer and write all your code dynamically and oop fashion, you can should understand the following about game design:


  1. Understand what piece of code does in the game
  2. Get something working
  3. Refine it until it is object oriented

You can also start, depending on your expertise, from step 3 -> 1. The best way to do this is to do an overall requirements gathering about your game or game project, and then group together functionality that be derived or have similar "factorizations" or similarities. This is like simplification or factoring in mathematics. Once you can do this precisely, you will be able to engineer great building blocks for your games or projects. This is called software engineering and can be a great help to you if you practice enough. The reason why it is a great help is because:


  1. aEUR'Save time using reusable objects
  2. You can refine those reusable objects later, and make them more "code" friendly, if you like to share
  3. Once you have something, you can figure out how to make it more efficient or come up with great ideas on how to use it for something else.
  4. Helps you appreciate shortcomings in your design, and understand why industry "best practices" were created in the first place.
  5. Helps you appreciate advantages in making something yourself, once you become an expert, after lots of practice!!


In C++, there are even more advantages because of pointers and addressing. this is important for game design, because if you become great, you can figure out how to create huge performance speedups at little or no space or computation time cost. I mean "huge". personally I have only seen these so far in rendering, game loops, and interactive programs, but I know they also can work for database programming, network programming, input and file i/o, etc... This way of thinking, can definitely also help you creating speed up for mobile programs or web applications, either client or server side, where resources are important to be used wisely.


I'll add some resources and links on these kind of topics in the near future.

Sign in to follow this  


4 Comments


Recommended Comments

Man I haven't heard anybody try to justify OOP in games in a very long time. With small projects it might be okay because being fast isn't a huge concern, but there's also the problem of object oriented codebases being some of the most convoluted I've ever seen. With all these different classes, templates, interfaces, and more functions than anybody ever needs (every time I see a getter and setter with no logic in it, part of me dies), it's really easy to get lost, not knowing what code is actually running. I think something like ECS is an objectively better way to structure your code when it comes to games. You get all the speed, more modularity, and it's super easy to make more content after you've got enough components.

Share this comment


Link to comment

With the advent of cross platform games becoming popular, I think game programmers should know there is the do it yourself option.  Basically these are things that game engine or render engine programmers do to get highly efficient frameworks or game engines in place.  It's what I study and do, so its what I blog about.  One of the points I brought up,  is that this way of thinking can help a game programmer or developer get better techniques or learn tricks that may be useful in other areas where graphics programming reside, like interactive multimedia and user interface programming, which are graphics intensive.  

Share this comment


Link to comment

Dont get me wrong, i like OOP and use it everyday, but to point out making everything object oriented is not the smartest way to program. Heavy object oriented code makes it harder to debug, harder to follow and harder to understand - especially when there are a lot of generics (c++ templates) going on.

 

Use classes, interfaces when it makes sense, but do not introduce oop just for the sake of it! Object orientation has its benefits when used properly.

 

- I get tears when i see classes which have literally one or two methods in it without any or useless fields

- I get more tears when i see classes with a singleton patterns just to simulate a global variable

- It hurts when i see getters and setters which does nothing than returning and setting a value.

- I starting to dislike code when i see templates over templates over templates (Std Library is a good example, even though its properly implemented and really fast)

- I get more tears when i see classes with more than 3 level of inheritance

- I get much more tears when i see constructors which does heavy operations, like doing collection lookups, file loading... that sort of thing -> Constructors and destructors should never do more than initializing fields.

A database class should never start connecting to the database when i just call new Database("localhost").

A asset class should not load any assets when i just call new TextureAsset("mytexture").

- I start to curse the developer when there are exceptions thrown in the constructor or destructor

 

 

To summarize it:

- Use object orientation when you really need it to be abstracted that way, but not the other way around! it does not matter if you do game programming or web programming or business programming whatsoever.

- Object orientation is not a holy grail to solve any problem: sometimes it helps, sometimes it can´t and sometimes it simply makes your code unnecessary complex

 

Thats my personal opinion after doing programming since 25 years, seeing so much code which is just unusable, just because its so much abstraction going on making it near impossible to understand or to debug.

Share this comment


Link to comment

Well, the point of the blog was just to introduce Object Oriented Programming from my perspective, as I introduce some tutorials or code sets later on, in later blogs.  I am using a teaching blogging, discussion style, where some "students" or "audience members" with lots of experience, such as Finalspace, may already know the material and have experience with it, but even if 1 or 2 readers may not, it can still be useful information to them and it is worth it to present.   How many times have we seen a lecture or conference, where the presenter or teacher is discussing something, and half the audience is saying "I already knew that."  Well, it is definitely still useful for the other half, and even a review or discussion doesn't hurt, and can maybe help you with something or a fact or detail you might have missed :)

I absolutely agree, that sometimes object oriented code is unnecessary, and in fact sometimes you can even include repetitive functions slightly modified in different classes, if it's only used once in a while and don't feel like writing a class.

Object oriented code patterns are useful for writing utility code that provide features like Reflection in java, where all methods and classes follow the same pattern and thus can easily be searched for providing information to the search utility.  This can help with more advanced features like dynamic code generation or statistical type information about large code sets.  This is more so for project leads and project management, and falls into the category of software engineering.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!