Game Development Reference
In-Depth Information
It is conceivable that not every element may require a controller for example a health bar
does not need any form of input or control from the player, it is optional to provide one.
class view
{
public:
view(element& element);
virtual ~view();
virtual void Create();
virtual void Draw();
protected:
element& m_element;
private:
view(const view&) = delete;
view(const view&&) = delete;
view& operator = (const view&) = delete;
};
When we construct a view we pass the element in by reference because the view will al-
ways be a member of the element and we will need it to retrieve any sprites or controls we
wish to draw, it also provides the interface to the data model. Through the element we can
get access to the player whose health, ammo and other properties we can query in order to
draw.
view(const view&) = delete;
view(const view&&) = delete;
view& operator = (const view&) = delete;
If you are wondering what the purpose of those lines is, these are a C++ feature introduced
into the standard in C++11, deleted functions . What we are doing is explicitly telling the
compiler that we do not want these functions to be a part of our class. If someone tries to
copy a view or assign one view to another they will get a compilation error. In our case we
are disallowing copying by constructor, copying by assignment or moving our view class
because it can only belong to the element that created it.
The controller isnearlyidentical,themaindifferenceisthatitwillonlyneedtoprovidethe
implementation for a HandleInput function, within this function it can communicate any
changes by the player to the element .
The idea is that this input function will control things relating to the element itself and not
the player or the player's property directly. So for example, if we are interacting with a
Search WWH ::




Custom Search