Hot answers tagged architecture
4
You should clearly separate GUI (view) from the actual game state (model). GUI just shows the model to the player (in one way or another) and lets the player control it, but the model itself is solid enough to know everything it needs (level, player, etc). The GUI should know only things GUI needs, which model does not care about (e.g. controls positions).
2
How do I use the engine's vertex shader while still allowing the programmer to provide his/her own vertex shader for other calculations in their game? What is the normal approach here?
There is no normal approach because engines generally don't let you do that.
Generally speaking, engines take one of two approaches: either the user provides none of a ...
2
Higher-end engines typically use a higher-level abstraction than an individual shader.
Simpler games just allow each model/material to specify shaders and then to use HLSL includes or the like to allow all common code to be easily reused. You'll need a bit of discipline in applying the shader includes properly and it can be a bit repetitive sometimes, but ...
1
I've got a big, somewhat controversial discussion over here about why Game Components are "bad".
The most annoying thing about GameComponent, for me, is that it looks really important. It looks like a first-class part of the XNA API - like Vector3 or SoundEffect - but they're actually not (everything in the Game assembly is technically optional).
So many ...
1
The answer to your specific question, how does the GUI know about the level being played, is: it doesn't.
The GUI displays everything it's being told to display, but it doesn't have any information about what that data actually is.
A common approach is to use a message system to pass messages from one component to another. When the LevelLoader has finished ...
Only top voted, non community-wiki answers of a minimum length are eligible
