How do different parts of a game interact?
Author
I'm busy writing a FPS using c++ on windows and i was wondering how should the different parts of the game interact?
For example how would my camera class interact with my model class to do collision detection and spatial partitioning etc...
Thanks
One way to do it is to have the camera maintain a view frustum and have the model contain a bounding geometry. When rendering you check if the model bounds intersect the view frustum. The spatial datastructure organizes your models spatially to make frustum culling and other spatial operations more efficient.
Author
OK say my model is split into a quad tree. How do i calculate which of the four sections cant been seen and shouldnt be rendered?
Quote:Original post by hahaha
OK say my model is split into a quad tree. How do i calculate which of the four sections cant been seen and shouldnt be rendered?
You use a quad tree to partition the space of the scene not the model. The idea is that if a certain space is outside the view frustum then all subsections of that space is also outside the view frustum so you can disregard huge chunks of the scene at once.
There are various ways that programs can communicate internally. You could just have global access to your data, or you could use an object oreinted approach and use interfaces for each of you code modules.
Current thinking tends towards the object oriented approach.
For example, you could have a monster object. As part of the interface for that object you could have methods such as getPosition(), moveTo() etc.
That way, the overall structure of your program will remain reletively simple and well defined, whilst allowing you to change the underlying behaviours with little impact to other modules. E.g. you could override your moveTo() method for a flying monster, yet you still only need to tell it to go to a certain place.
You could also easily change your code to work on multi-core platforms by changing the way your interface works, e.g. by passing a message rather than a direct function call.
Current thinking tends towards the object oriented approach.
For example, you could have a monster object. As part of the interface for that object you could have methods such as getPosition(), moveTo() etc.
That way, the overall structure of your program will remain reletively simple and well defined, whilst allowing you to change the underlying behaviours with little impact to other modules. E.g. you could override your moveTo() method for a flying monster, yet you still only need to tell it to go to a certain place.
You could also easily change your code to work on multi-core platforms by changing the way your interface works, e.g. by passing a message rather than a direct function call.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
