Making The Game – Teil 10: Spiele-Konzeption


Many different factors must be applied in the development of a multimedia, natural learning application. So I decided not to use a typical software-development model.
Instead i used the agile process model in the development.

Waterfall model
Waterfall model

This approach was chosen because compared to the waterfall model, where at the beginning of the development all specifications must be set, it is much more dynamic to changing requirements and add new ideas can during the development process. In addition, the costs and project progress at the beginning of the development is difficult to predict, so the use of an agile and iterative approach that adapts to the current situation has many benefits.
Since most agile processes based on set, that they are trying to reduce the design time to a minimum and generate executable software as quickly as possible (to present it at any time), the development is performed in individual, sealed iterations.

Agile Process Model
Agile Process Model

In each iteration a complete development cycle is gone through. That ensures that the developed program can be run at any time. Therefore the currently made ​​step is analyzed, designed, implemented and tested
So new knowledge and changes in the existing application could more quickly influence the future development and risks of development are identified more quickly.
Before the actual design phase of the NUI edutainment application first, the target rules must be set. These form the backbone of the game and dictate the direction of the program structure.
The application is developed within the field of entertaining learning. It should, in addition to the traditional mouse and keyboard control, be primarily played with natural control using touch input and body movement.
It should also be noted, not all control options are available on every device, so any natural input method should have a conventional alternative.
The application is designed primarily for use in the classroom. So lessons will be more interesting for the students and the motivation to learn can be increased. The use of the student’s home to “normal” computers should not be excluded.
The program is located in the category of “drill and practice”-applications. It will present no new subject matter, but only tests it. The application only controls the knowledge of the player and strengthens the already acquired knowledge.
One of the main aims of the application is the extensibility and openness to nun developer.
As this developed edutainment application, like most other educational programs, leveraging on a question bank, it is of of great importance that it may be extended or altered by anyone. It should no technical knowledge be needed, in order to modify the knowledge base.
In addition, it should be possible in and with the knowledge base to adjust the difficulty level of the game, without changing the program code itself.
With these two objectives is to ensured that parents and teachers with no programming experience can change the knowledge base and fit it in the the current topic from school.
Besides the possibility of changing the previously stored questions and adding additional languages ​​as well, the creation of a new knowledge base also should to be possible. Through this openness the use in language schools and in foreign language classes are made possible.
Technical Conditions
In addition to the requirements that determine what goals to achieve with the program, there are other conditions in this project. These result from the technical characteristics of my available hardware.
Since the aim of the program is to run on different computers with different hardware limits it is to look to this conditions during the development.
The application has to differentiate between powerful and weak computers on the one hand and the possibility of multi-touch input and control via mouse and keyboard on the other hand.
This differentiation will be necessary to define precisely what kind of hardware for a mini-game must be available so that it is executable. For example, no body control games may be started if no camera is present.
To keep the general hardware requirements low complex animations and effects are cut out, or at least tried to implement an optimized version of this effect.


Upcoming blog entries
Making The Game – Teil 11: The Storyboard
Making The Game – Teil 12: The Graphics Library
Making The Game – Teil 13: The Sound Management
Making The Game – Teil 14: Knowledge base and question selection / Working with XML


Leave a Reply