Game Development Reference
In-Depth Information
Implementing a data-driven system
With a good class hierarchy in place, the next step is to ensure that your UI can be
created easily from a configuration datafile. While it is perfectly possible to create all
your controls in code, this is hard to maintain and, most crucially, can then only be
edited by a programmer.
Allowing your UI to be constructed from a datafile means that other members of
your team can help with designing the UI. Having a datafile format also makes it
easier to develop a user interface layout tool if you want to make the process even
easier for people to use.
We've already seen how we can use the ITX file format to construct our own custom
classes from a file at runtime, so it makes sense to employ this methodology to our
UI code (refer back to
Chapter 2
,
Resource Management and 2D Graphics Rendering
, if
you want to refresh your memory on this). No point in writing more code than we
have to!
Responding to user input events
The user interface of a game must solve two main issues. The first is relaying
information to the player, and we've already discussed how this can be done earlier.
The second is responding to user inputs.
As discussed earlier in this topic, modern mobile devices allow a great many ways
of allowing the player to interact with a game. Which of these you support, depends
on the devices you are trying to target, but by far the most popular choice is the
touch screen. Pressing on-screen buttons is just a very natural way of interacting
with a application, so it is pretty much guaranteed you will end up supporting touch
screens for your own UI.
Obviously not all controls need to respond to being touched. For example, a label is
unlikely to do anything, so it makes sense to provide some mechanism that allows us
to indicate which controls should respond to touches and which shouldn't.
While we could just add some virtual methods to the element class that gets called
whenever a touch has been detected within its bounding area, this is probably not
the best solution as it starts to make the element class a little cluttered.
We really want to encapsulate this sort of functionality somehow, and a good way
of doing this is by using an Event system. Such a system works by having a central
event manager whose sole job is to receive event messages from one part of the code
and pass those messages on to any class instance that has registered itself with the
event manager to be notified of a particular event.
Search WWH ::
Custom Search