Use an object pool full of value types, with a swap/remove semantic, and punch anybody in the face who tries to make you change to a microallocation system. You don't need to start out with a pool of 10k objects slots, you can make it smaller, and reallocate to size*2 every time you run out, then do a full copy. This won't be taking place on every single frame.
I wasn't joking about punching them in the face.
If you have 10k transient objects you need to pool, or else your memory will be scattered all over the shop, there is no two ways about it.
There is an important thing to understand - OOP does not imply classes, interfaces, operator new, inheritance, polymorphism... Those are implementations of OOP. You can still call a design which is based around objects being instanced, even if no other canonical OOP language features are used, as OOP. Just in case you need to beat back some academics at some point.
Is it bad to use OOP?
You need to stop worrying about how much memory is being used and start worrying about how effectively you're using it. Memory usage is one of those tradeoff areas where sometimes accepting some extra overhead can result in huge gains (in terms of performance, code cleanliness or otherwise) elsewhere. It's largely a complete and utter myth that "more memory usage always == bad" - within reason, of course. If the extra memory is available, and if it's being used to do something valuable for your program, then using it is a good thing. Memory is a cheap and plentiful resource, programmer time and performance are not.
you must use the programming paradigms, whose most fits to your taste.
ideologies should not influence your code.
ideologies should not influence your code.
Your problem isn't the programming paradigm, it's plain application performance (your design).
Simple question, each player got like 10000 items right? Do you need to allocate the entire 10000 items at the same time in memory for each player? Sounds like a 'no' to me.
This kind of issue is up to your application to solve it, this is no matter of language or paradigm. There are multiple ways to handle this, as already mentioned in the topic. I also want to add it a consideration of using an game engine/framework if you are having a hard time with this issues.
But I don't want to discouraging you, designing yourself is really rewarding.
Simple question, each player got like 10000 items right? Do you need to allocate the entire 10000 items at the same time in memory for each player? Sounds like a 'no' to me.
This kind of issue is up to your application to solve it, this is no matter of language or paradigm. There are multiple ways to handle this, as already mentioned in the topic. I also want to add it a consideration of using an game engine/framework if you are having a hard time with this issues.
But I don't want to discouraging you, designing yourself is really rewarding.
Um, correct me if I am wrong, but using OOP should just be a way of referencing the data and adding functionality to it, instead of adding extra space. If you really are worried about it and you just have properties, assuming you are using C++, use a struct. They don't take up more space than the individual components do (ie if an int is 4 bytes, then a struct with 3 ints is just 12 bytes, whereas if you managed it yourself, you still would end up with 3 ints, or 12 bytes).
Um, correct me if I am wrong, but using OOP should just be a way of referencing the data and adding functionality to it, instead of adding extra space. If you really are worried about it and you just have properties, assuming you are using C++, use a struct. They don't take up more space than the individual components do (ie if an int is 4 bytes, then a struct with 3 ints is just 12 bytes, whereas if you managed it yourself, you still would end up with 3 ints, or 12 bytes).
Use a struct versus a what? What benefit does using a struct provide?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
