Free HTML5 Game Tutorial for Beginners: Page 5
Learn how to create technical specifications for a game. The technical specification explains how various programming components will interact with each other. Components are separate sections of an application. Sections are divided into components based on purpose. For example one component will display information to the player, and another component will save the score. Therefore the technical specification provides the application's structure.
With the MVC design pattern, a programming component refers to the model, view, or controller, separately. When necessary, components may refer to subsections of the model, view, or controller.
Level of Detail
The level of detail provided in the technical specification, depends on the purpose of the document.
For example, clients may want a document which provides a general idea of how the application will function. Clients sometimes won't understand software development details. Therefore it's helpful to omit specifics for some clients.
On the other hand, software developers may want a high level of detail, including algorithms, the database model and properties, programming interfaces, and control flow.
Algorithms detail the progression from one step to the next, to accomplish one task. Programming interfaces explain how various components will interact with each other. The interface describes inputs and outputs of a component, rather than details within the component.
Sometimes the details are unknown when the technical document is composed. If the specification is prepared for programmers, then provide available detail. Explain the issues regarding unknown details, as a starting point for developers.
From a development perspective the specification provides enough information for programmers to start writing code, and fulfill the request of the Product Requirements Document.
Ideally the technical specification will work out the more complicated issues for developers, before they prepare the code.
Overview: Model-View-Controller Design Pattern (MVC)
Perhaps the most important technical aspect of the Surface Game involves dividing the project into manageable files.
The MVC Design Pattern section provided an overview of the MVC design pattern. MVC works great for games.
The model is the part of the game which stores and loads data output, such as the score, level, and question number. The model also loads data input, such as questions, answers, and paths to image source files.
The model input will use XML. Each XML file will represent one level. Each XML file will contain a set of questions. Each question will include three text nodes; the question, the answer, the image's source file.
The user data, including level number, question number, and score, will be saved to local storage or cookies.
If the device the game runs on can save to local storage, then user data will save to local storage. Otherwise if the device can save to cookies, then user data will save to cookies. If both storage methods fail, then a message will display to the player, asking them to allow local storage or cookies.
surface-game-model.js will not share variables
Self contained files minimize errors with Dependencies in HTML5 Game Development. Self contained files are also well suited for re-use in other games and applications.
The controller will call
loadXML(number) will load an XML file with a file
name which contains the number provided through it's parameter list.
loadXML(1), will load an XML file
1.xml includes input data
for the game's first level.
loadXML(number) will return an XML DOM Object
to the controller. The XML DOM object for each level
includes questions, answers, and the path to an image file.
The controller will call the functions defined
model module of the MVC design pattern.
scoreModelSet() retrieve and save user data.
The view is the part of the game the player sees.
The desktop version of the game and the phone
version of the game will have separate views.
For more information
View: Product Requirements Document
The view includes five sections.
- HTML elements
First, design graphical shapes as GIF files. On each graphic display the width, height, or base, as needed for the player to answer questions associated with the shape. The same GIF files will be used for both the mobile and desktop versions of the game.
2. HTML Elements in the Game's Web Pages
The Web page which runs the desktop version of the
will include the CSS and HTML to display
most of the desktop and tablet view.
The view is described in the
Product Requirements Document.
The Web page which runs the mobile version of the
will include the CSS and HTML to display most of the mobile phone view of the game.
The view is described in the
Product Requirements Document.
Create separate Web pages for the mobile and desktop views.
Yet declare HTML elements with the same
Both the desktop and mobile games
id is called an HTML attribute.
The value is the name assigned to the attribute.
For example the following HTML markup declares a
element with the attribute
var cvs = document.getElementById('cv');
Third, define color, location, width, and height of HTML elements with CSS.
HTML elements work with the CSS. Because the mobile and desktop views will look differently, both the mobile and desktop views have separate style sheets. However any shared features should be factored out and placed in one shared style sheet as well. Both versions of the game load two style sheets. One style sheet is shared. The other style sheet is specific to the horizontal or vertical view.
The term implement, means to create code
which puts in place the requirements expressed by the
display color animation when a level is complete.
will provide functions which
uses to show information to the game player.
viewText() will show information to the player
about the level, score, and question.
viewImage() will display
images on the game board and function
will display error messages.
viewDebug() displays debugging output
during the development phase.
Features such as Google Chrome's Developer Tools,
help find errors during development, yet sometimes it's
useful to include and display other errors.
It might be helpful to remove
viewDebug() and all
references to the function after thorough testing.
surface-game-canvas.js provides most of
the display interaction for the game.
resizes the canvas in response to browser resize
and orientation events.
the canvas according to tap,
mouse over, and drag events.
an array of digits the user has dropped onto the answer box.
The controller includes the logic of the game. The controller determines if an answer was correct, increments the score, plays audio, and calls methods in other files. Methods in other modules animate colors, reset the view, show text, and show graphics.
The controller accesses functions within the view, display, and model. The goal is to prevent the view, display or model, from accessing functions in the controller. Design a one way communcation mechanism from the controller to the model and view files. Sharing a minimum number of variables between files makes debugging easier.
Tightly Coupled Files
This game minimizes the use of tightly coupled files. Unfortunately there are a few issues requiring close interaction between files.
This article explained the basics of a technical specification. This tutorial discussed how the model-view-controller design pattern components of the game will interact.
Subsequent tutorials in this game development series,
explain details of the various functions within components
Now there's just enough detail to start making the game!
For the next tutorial, tap the image icon containing text which says
Next Lesson, or
the right pointing arrow at the bottom of the page.