Sign in to follow this  
noodleBowl

Clean up and what to keep in mind

Recommended Posts

noodleBowl    713
I'm sorry if this is super broad, but I'm about to do my first clean up phase for my framework and I really want to get the initial foundation down for this so everything is maintainable. Something I feel like that was kind of put on the back burner when it comes to 'general' design practices, because I don't really know what they are when it comes to C++

So I'm wondering what kinds of OO concepts / general things, even if they are little things, that I should keep in mind?
I'm talking about things like The Rule of 3 or little performance tricks and tips Edited by noodleBowl

Share this post


Link to post
Share on other sites
Irlan    4067
Time is the only source for getting experiences with game engine architecture, so  you should read a lot and keep motivated.
 

There is some best practices that you should do but the best advice it's to follow the SRP (Single Responsability Principle) that states that only one class should have one single responsability, or if is have multiple responsabilities that one should be related to the class itself; it simple states that you shouldn't mix stuff that doesn't make sense in classes.

 

You should use the module approach in any application you do (that not applies only to game simulations).

 

Actually if you're using module approach you're already using the SRP in the context of your architecture; each module it's responsable of one thing; such thing can be a physics library, a graphics library, a file system library, memory library. etc.

 

There is tons of optimizations that could be don once the program is created and that not applies only to C++; C++ is a language that should be used to make games, more specificly to make games run  faster and have full control of its flow.

 

There's no performace "tips and tricks" for a single thing. There is a milion of performace optimizations that are allowed to do in a specific case but that not applies to any type of project; you shouldn't have even think of optimizing a graphics module if you don't know how the GPU works.

 

Such "tips and tricks" depends pretty much of what you're doing. 

Share this post


Link to post
Share on other sites
frob    44975

This type of thing requires experience.

 

People gain experience in two main ways:

 

1. Reading about other people's experiences, then reasoning and learning from them.

2. Making mistakes and gaining your own experiences, then reasoning and learning from them.

 

 

Reading for the first route only takes you so far. You will read some things, but you will be limited to the things you have read about.

 

The second route is also very effective. Make mistakes. Lots of them. Show it off and ask other people for feedback.  When they tell you something is bad or problematic, take notes. When something is annoying to you in your own systems, also make notes. 

Share this post


Link to post
Share on other sites
SmkViper    5396

The second route is also very effective. Make mistakes. Lots of them. Show it off and ask other people for feedback.  When they tell you something is bad or problematic, take notes. When something is annoying to you in your own systems, also make notes.


If I haven't made a mistake in a particular day, I obviously haven't done anything terribly interesting tongue.png

Share this post


Link to post
Share on other sites
bioglaze    1619

Some points are slightly off-topic, but these are some of the things I do to maintain code quality:

 

* Avoid mutable global state including static variables inside methods

* Make sure that classes and methods do not do too many things ("Separation of Concerns")

* Avoid boolean parameters to functions, they are not very readable and are often used to select code paths that belong to their own separate functions

* Express intent by using algorithms instead of loops, wrapping stuff into well-named methods etc.

* Use forward-declarations as much as possible

* Declare everything const and use non-const variables only when you have to

* Avoid too many method parameters

* Read Effective C++ series

* Use static-analysis tools like CppCheck and PVS-Studio and high warning level in your compiler

* Compile your code using different compilers to find missing STL #includes and non-standard code

Share this post


Link to post
Share on other sites

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

Sign in to follow this