Bullseye

you are in savethegaywhale || msc || designanddevelopment

sitemap

 

3 Design and Development

3.1 General Criteria

Arising from the review of literature and examination of current trends in the use of SVG, the intention is to develop a game in Flash, attempt to replicate it in SVG and subject the applications to a comparative evaluation. This design and development experience and subsequent evaluation will be used to answer the questions posed by the project proposal. That is 'to what extent SVG is likely to replace Flash as the de facto industry standard media for the delivery of vector graphics on the Internet?' and 'what key developments are required to facilitate wider use of SVG?'

Before considering the design and development of the application, it is useful to consider what defines a good application and declare the key criteria against which the applications will be evaluated.

3.1.1 A Good Application
In order to be defined as 'good', certain characteristics should be included in the design of a software application.
These as outlined by Stevens and Pooley (2000) are:

· Usable, it should actually work, with few or zero faults and have an interface, which is accessible to the target user.
· Flexible and extensible, software requirements can change and the code should be written to allow this with minimal alteration, such as the use of defined variables rather than hard coded numbers.
· Available, in this context, as the applications are to be deployed on the Internet, means considering attributes such as file size.
· High cohesion, desirable since low cohesion suggests grouping of unrelated activities (van der Poll and Kotze, 2002), so every aspect of a class should be directly relevant and related to that class.
· Low coupling, this is advantageous as it implies that classes are independent of each other (Riel, 1996).

These last two attributes are especially desirable in object-oriented programming (OOP) as they allow for the reuse of classes and lend a degree of modularity to the application. This enables developers to use classes written by others in their own application. As is implied by these comments, the applications will be developed as object oriented applications and modelled using the Unified Modelling Language (UML).

A further characteristic is accessibility in the context of hardware that it is reasonable to expect a user to have access to. Initially the minimum specifications (defined in appendix 4) are based on a computer approximately 4 years old.

3.1.2 A Good Website
As the applications are for use on the Internet, they should be subject to guidelines (heuristics) for good website design. Whilst a set of heuristics are to be developed to enable evaluation of the applications on the Internet using principles as outlined in Nielsen (2) (1994), Nielsen and Molich (1990) and Calongne (2001). These concentrate on keeping memory load low, providing feedback and being consistent. In terms of web page interface design this is expressed in attributes such as; quick download time, simple easy navigation, ensuring that there are no broken hyperlinks and avoiding horizontal scrolling (vertical scrolling is not such a concern).

3.2 Key Criteria

In addition to the general criteria described above the applications will be compared against key criteria of:

· Bandwidth, this, as discussed by Kong and Ghosal (1999) (citing the GVU WWW User Survey) who observe that Internet users state that slow download time is the primary reason for dissatisfaction with the Internet. Therefore the overall file size is arguably the most important attribute of any Internet based application.
· Speed of client side rendering. Both Flash and SVG are primarily client side formats. So whilst bandwidth is considered a very important attribute of any Internet application, this is only because of its direct influence on the time taken to display the web page or Internet application.
· Functionality, do the applications work as intended in their environment?
· Accessibility, as discussed in the review of literature, this will include matters of availability. Can the user run the applications as intended? If not are there appropriate messages provided?
· User Experience; is using the applications a satisfying experience, does the user have a preference for one format over another? And if so why?

3.3 Methodology

All projects are ultimately constrained by scope, time, cost and quality. The primary limiting factor in this project is time, only 2-3 weeks are available in which to produce working prototypes, this in turn limits the scope, which is further limited by the fact that the applications must be of a sufficient quality to fulfil the criteria listed above. Cost is not directly relevant. Whilst the design and development of the applications will not be subject to the strict application of a project management methodology, it will be broadly based on Rapid Application Development (RAD). In particular the project will be characterised by its iterative nature and continuous prototyping. RAD, suggest Agarwal et al (2000), also promotes the development of maintainable, reusable and extensible software.


3.4 Requirements Capture and Specification

The objective here is to define the applications in terms how the games will appear to the user and other relevant criteria.

The games have to be sufficiently simple to allow for development within the allocated timeframe and to be as similar as possible to allow for a like with like comparison of the formats. However they should nevertheless be able to test the features of the languages, and expose any limitations.

Some of the features the applications will seek to test are:

· Display of graphic primitives.
· Display of text.
· Use of additional effects, such as interactive sound.
· The ability of different playing criteria to be set by the user, primarily, 'levels of difficulty'.
· The ability of the applications to change attributes of elements, such as the position of objects over time (animation) and displaying the score of the game.
· The ability of the game state to be defined by non-user events, such as determining when a game is complete.

In order to complete the development of the two applications within the timeframe, the application to be developed in Flash is based on an interactive shooting game developed in that format by myself as part of an earlier project. This would allow resource to be focused on the development of the game in SVG, which would require a substantial element of new learning and working in an area for which there would be limited support.

This initial conceptual design is further expressed in a game scenario in appendix 5, which outlines a sequence of game play.

3.4.1 Limitations of the applications
At this early stage it is evident that the applications will have limitations. It is useful to discuss aspects of the formats that will not be tested by the proposed application:

· The user input will be restricted to mouse actions, there will be no keyboard input. This is likely to simplify development, as implementing keystroke commands requires bespoke coding in both formats.
· The applications are only to be developed for standard computer screens, not for mobiles or hand held screens. Whilst SVG does support the use of small devices, indeed SVG 1.1 is merely a modularised variation of SVG 1.0 to accommodate mobile and tiny profiles (World Wide Web Consortium (3), 2003). Macromedia have released a player for Pocket PC devices (Macromedia Inc (1), 2003). Flash. However developing versions of the application for these formats is beyond the scope of this project. It is also the case that, as subsets of the full formats, the proof of concept applications should be confined to the top level.

3.5 The Flash application

3.5.1 Designing the Flash application
Designing Flash applications in an object-oriented manner is achieved by modelling classes as Flash movie clips. Relevant ActionScript code can be written within the movie clip. This allows; provided the classes exhibit high cohesion and low coupling, for a high degree of modularity as each movie clip can be treated as a class and transferred to another application whilst retaining all its functionality.

As part of the design process candidate classes are identified along with potential methods. With reference to Riel's (1996) heuristic that irrelevant classes should be eliminated from the system this was refined to produce an implementation class diagram as shown in appendix 6a.

3.5.2 Developing the Flash application
A key feature of developing an application in Flash is that it is a singular development environment. Assets such as sound files or bitmaps are imported into a library and then manipulated using Flash's tools. Once such assets are imported the development process is undertaken from within a 'walled in' GUI environment with menus and right click (Windows) context menus providing appropriate options. Even ActionScript (Flash's scripting language) can be written in 'normal' mode, which provides an extensive auto complete facility. These aspects, argue Trippe and Binder (2002) restricts Flash, as only the feature set within the development application is available. However it does bring benefits in that everything the developer undertakes within the environment will work and if not an error message will be given.

The game is developed iteratively by implementing the game at its simplest level and then implementing further levels of difficulty until the game is complete. This process is accompanied by multiple prototyping to ensure that the intended functionality and that the application is reliable.

Having modelled an object-oriented application to be built in Flash, it is useful to discuss how successful the mapping was. That is, during development, were all the classes and methods modelled actually created and were any further features required? In the case of the 'Bullseye' application in Flash the mapping was successful, with all the classes being expressed as Flash library items and the methods envisaged for those classes being defined as functions within the classes (or library items). This creates classes, which are encapsulated and suitable for reuse in other Flash applications.

3.6 The SVG application

3.6.1 Designing the SVG application
A significant factor when designing in a language or format that is relatively new or that the designer is unfamiliar with is that although modelling languages such as the UML should be at a sufficiently high level that the programming language is not pertinent.

3.6.2 Developing the SVG application
Selecting an environment

In direct contrast to Flash, a key feature of SVG is that its open standard nature means that there is a strong likelihood of there being a number of possible development environments and viewers. This, as discussed in the review of literature, is indeed the case. As a consequence the SVG developer has to decide at an early stage what primary development tool(s) are to be used and what plugin(s) will be used for prototyping. Because SVG is an XML namespace it is possible to code an SVG application in plain text, it was envisaged that in addition to developing graphics there would be a need to write JavaScript for the application, a text editor was chosen as the primary development environment. Additionally, the review of literature established that ASV3 is the prevalent SVG viewer, so to ensure the widest accessibility, the application was developed and prototyped for this viewer. Prototyping was also carried out on ASV6 the (beta at the time of writing) successor to ASV3.

Creating graphics

Before discussing the development of 'Bullseye' in SVG, it is appropriate to consider the syntax of SVG with a simple example.

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="550" height="400" viewBox="0 0 550 400"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">

<desc>rectangles and a circle</desc>

<defs>

<rect id="backgroundBorder" x="0" y="0" width="550" height="400"
fill="none" stroke="red" stroke-width="10"/>

<rect id="purpleRect" x="0" y="0" width="150" height="80" fill="none" stroke="purple"
stroke-width="30" />

</defs>

<!--This is a comment -->

<use xlink:href="#backgroundBorder"/>

<rect x="100" y="220" width="200" height="100" fill="green" />

<circle id="blueCircle" cx="450" cy="320" r="50" style="fill:blue" />

<use xlink:href="#purpleRect" transform="translate(250 160) rotate(-60)"/>

</svg>

The above SVG code would be graphically expressed as in Fig5.

fig 5

Fig 5. A simple SVG image.

The structure of this simple SVG document illustrates the following points:

· The headers demonstrate that this is an XML document of SVG type using a W3C Document Type Definition (DTD), that the DTD contains a date in its URL, (20010904) indicates that it is in final form and will not be subject to further change, this assists developers; who can be assured that an application that references this DTD will always function in a consistent same manner.
· The <desc> element can be included to allow browsers without an SVG viewer to display information about the graphics and can also be accessed by accessibility software as part of the W3C web accessibility initiative (World Wide Web Consortium (2), 2003).
· The <defs> element ('defs' is an abbreviation for 'definition') is where primitive graphics are defined and if required grouped into more complex objects. This, observes Cagle (2002), allows for reuse, and elements declared within the 'defs' element can be considered as classes for object-oriented programming.
· The <use> element; elements defined in the 'defs' section of an SVG document are not rendered until called by the 'use' element, which is done by referencing the unique 'id' that the developer assigns to the element; 'backgroundBorder' as shown in the code for +figure 5.
· The <rect> element; 'rect', 'circle' and 'path' are all examples of graphic primitive elements that can be defined in SVG and form the building blocks of any SVG image.
· The transform attribute emphasises the Cartesian nature of SVG. SVG can be defined in various measurements such as 'in', 'cm' and 'px' which is the default (and so used if no unit is defined). Unlike HTML it is not possible to position an element with a relative attribute of <centre> or <left>. This illustrates one of the key limitations that Badros et al (2001) and Marriot et al (2002) sought to address in their constraint based work. However the transform attribute is useful for positioning elements, especially those defined in the 'defs' section as multiple instances of an element can be placed on different parts of the 'viewBox' (the viewing area).

The above points describe the main components of an SVG image and also emphasises the tag text based nature of SVG (as an XML namespace), which Trippe and Binder (2002) argue makes SVG attractive to established Internet developers who will be familiar with the general syntax.

When developing the 'Bullseye' application in SVG, the graphic elements were created using similar techniques to that used in the Flash application to preserve the design format and ensure that when comparing file size, the rendered image and overall functionality, a meaningful comparison was being made. The following sections discuss key features of developing 'Bullseye' in SVG and comparing the process with the Flash equivalent. A fully commented code listing for the SVG version of 'Bullseye' is given in appendix 7.

Bitmaps

The background to the main gameplay area in both applications is a 30k bitmap image. In the Flash application this is imported into the library and placed on the 'stage' (the Flash term for the viewing area). This is embedded in the final swf file, whereas in the SVG file it is externally referenced thus:

<image x="0" y="0" width="550" height="400" xlink:href="background.jpg"/>

This means that already 2 files are required to do in SVG what 1 can do in Flash, however it is noted that the aggregate application size for each format only increased by 30k. Probets et al (2001) argue that if the same image is used in multiple swf applications each instance of the same image will be embedded and require downloading whereas in a similar scenario in SVG the bitmap is likely to be cached thus reducing download time. However it can be argued that such circumstances are not especially common and that therefore the point is not significant. A screenshot of the gameplay area is shown in appendix 8.


Text

The text for the game instructions is inserted in Flash using simple word processing type tools, within this environment text can be selected in blocks (of whole paragraphs or parts thereof) and properties applied. Displaying text in SVG is more complicated, a point demonstrated by the code in figure 6. required to display the following 2 lines:

Welcome to Bullseye!!
Please select your level of difficulty, this will set

Fig 6: Text in SVG.

requires the following code:


<text id="instructions" x="275px" y="70px" style="fill:rgb(0,0,255)" font-size:24 text-anchor="middle">
<tspan>
Welcome to <tspan style="fill:rgb(255,0,0)">
Bullseye!!
</tspan>
</tspan>
<tspan x="275" dy="1em">
Please select your level of difficulty, this will set (and so on)
</tspan>
</text>

This complexity of code illustrates the point made by Duignan et al (2003) that text wrapping is not supported, this in part emphasises the previous limitations discussed that SVG is a coordinate based system. It is recognition of this that there are substantial enhancements to text handling in the working draft of SVG 1.2 (World Wide Web Consortium (5), 2003). However the ASV6 viewer, which Adobe (Adobe Systems, 2003) assert support all the main features of SVG 1.2 does not render the simple examples given by the World Wide Web consortium. This demonstrates a limitation of open standard development, that despite the advantages put forward by Neumann and Winter (2002) and Cagle (2002) in the review of literature, flawed software will enter the public domain where it can undermine confidence in a technology. The development of the simple text required for the SVG 'Bullseye' application is, once the technique is understood, straightforward, but time consuming if done with a text editor. Whereas, in Flash, the task is intuitive and flexible. That fact that the task may be simpler in SVG with an authoring programme is considered in the next chapter.
A screenshot of the introduction screen showing text display is in appendix 8.

Shapes and styles

SVG as primarily a graphics format supports graphical shapes well (Duignan et al, 2003), the following code demonstrates how a shape is defined and positioned in SVG. This can have an attribute (such as 'fill') applied, which is normally defined in the 'defs' section where it can be reused.

<ellipse cx="50%" cy="50%" rx="60" ry="20" fill="blue">
<set attributeName="fill" to="url(#white-blue-white)" begin="0s"/>

SVG supports a number of effects; the following code applies an effect to the ellipse defined above to produce the effect in Fig 7.

<linearGradient id="white-blue-white" x1="0%" y1="0%" x2="100%" y2="0%"
spreadMethod="pad" gradientUnits="objectBoundingBox">
<stop offset="0%" style="stop-color:rgb(255,255,255);stop-opacity:1"/>
<stop offset="50%" style="stop-color:rgb(0,0,255);stop-opacity:1"/>
<stop offset="100%" style="stop-color:rgb(255,255,255);stop-opacity:1"/>
</linearGradient>


fig 7

Fig 7: A linear gradient in SVG.

This example also demonstrates that SVG supports opacity. Producing these effects in Flash is again a straightforward matter, whereas in SVG the code whilst fairly simple is time consuming to enter into a text editor. However the text based nature of SVG means that developers using a text editor can copy and paste similar code and modify for the application under development. This does still require an understanding of the functionality of the code that a Flash developer would not need.

Simple animation

Animation can be undertaken in SVG by changing attributes, the code below shows the changing of coordinates, but the attribute could be visibility or opacity, the Flash equivalent is called 'tweening' which is conceptually similar in that a begin and end point are defined and the application moves from one to the other.

<defs>
<g id="target" >
<circle cx="0" cy="0" r="38" style="fill:blue" />
<circle cx="0" cy="0" r="25" style="fill:white"/>
<circle cx="0" cy="0" r="14" style="fill:red"/>
</g>
</defs>

<g id="moveTarget">
<use xlink:href="#target"/>
<animateTransform attributeName="transform" type="translate"
attributeType="XML" begin="0s" end="7s" repeatCount="indefinite"
from="- 20,100" to="520,100" >
</animateTransform>
</g>

Adding interaction

Whilst there are differences in developing static graphics and simple animations in Flash and SVG the formats do not show their strengths and limitations until interactivity is included. SVG supports mouse event handlers such as:

begin="mouseover" end="mouseout"

which could be inserted into the above code to produce trivial interactivity, key stroke event handlers are also supported, but are more complex. As has been demonstrated SVG supports xlink, a language for defining links it is implicitly defined in the DTD (Cagle, 2002). This can be employed to link to Internet resources thus:

<a xlink:href="http://www.google.co.uk">
<circle cx="100" cy=100 r="25" fill="red" /></a>
This simple interactivity in SVG can be used to hyperlink out of the application or to create simple state changes, rollover effects and motion, however to fully exploit SVG it is necessary to manipulate the Document Object Model (DOM) using script. An example of this is the 'traverse' function from the SVG code for 'Bullseye' in appendix 7. The SVG specification does not specify a scripting language, but as Duignan et al (2003) note, ECMAscript (a JavaScript variation) is the most popular and it is used to develop 'Bullseye'. It is the scripting in the SVG application that controls aspects such as setting the levels of difficulty, displaying the score, monitoring the game state (to decide when the game is complete) and stopping the game.

Specific points of interest in developing the SVG application:

· The only input device required to play 'Bullseye' is the mouse, represented on screen by the cursor, which is one of the most critical pieces of information you can provide to a user (Cagle, 2002). The model for 'Bullseye' requires replacing the cursor with a crosshair, in Flash this is achieved with the ActionScript code:

//hide cursor
Mouse.hide();
//replace cursor with custom cursor
_root["myCursor"]_.x = root.xmouse;
_root["myCursor"]._x = root.ymouse;


Achieving a similar outcome in SVG requires approximately 80 lines of code. This is in part due to the fact that ASV3 does not support the SVG (cursor modification has been in the SVG standard since 1.0) standard pertaining to cursors (Cagle, 2002).
· In relation to the last point ASV6 does support SVG cursor modification, therefore 'Bullseye' contains code to replace the cursor with a 5px by 5px transparent PNG. However the standard cursor is visible at all times when viewing with ASV3. This may be seen as a significant impediment to usability and whilst ASV3 remains the most common SVG viewer, this may prove to be a disincentive to developers to use SVG, especially when Flash offers a straightforward and effective solution.
· In developing the SVG application a number of difficulties were encountered in tracking the game state in order to end the game (which occurs when no targets are left) in Flash this is achieved by:

if(_root.targetsLeft==0 { //when all targets traversed
_root.gotoAndPlay("firstScene");
}

SVG does not use the 'scene' and 'frame' device that Flash does, the SVG (and XML) nearest equivalent being the DOM. Ending the game was eventually solved by grouping all the elements of the introduction screen together (with the id “intro” and placing them in the DOM such that the group was rendered on top of all the other elements then controlling the visibility of the introduction to reveal (or not) the elements behind it.
· Including sound in the Flash application is trivial as sound files can be placed in the Flash library and deployed by various means; the final swf embeds the sound in Mp3 format. Whilst sound for SVG is in the SVG 1.2 proposal it is not yet supported. As the model for 'Bullseye' requires interactive sound, use is made of the Adobe namespaces to enable the ASV3 support for sound. This illustrates another aspect of open standard development; the existence of a declared standard does not oblige developers to adhere to it. Whilst this can encourage innovation, it can inhibit accessibility by requiring a user to have a particular application (in this case ASV3). This point will be developed in the Evaluation chapter.

Using the techniques discussed both games were developed to be as similar as possible in overall functionality as possible to each other. The development was undertaken with the Flash application as the control and the SVG application seeking to emulate it.

When I began to develop the Flash application I understood how to create basic graphics and limited interaction, but had no knowledge of more advanced scripting. SVG was a technology with which I was not familiar and so spent some time learning SVG to the stage where understanding of both environments was similar. The Flash application took 3 days to implement once modelled, whereas the SVG application took approximately 3 times as long. These figures are approximations and have been reduced to take account of new learning. This difference is contrary to Trippe and Binder's (2002) assertion that authoring SVG is easy. With experience this development time would be significantly reduced and as is concluded in the consideration of workflow in the review of literature, knowledge of XML would be beneficial to developers.

3.6.3 Mapping the SVG application

Mapping the SVG application presents more problems than is the case with Flash, where library items can contain all the functionality of the modelled class. In SVG, as Cagle (2002) observes, elements can be contained within the 'defs' section (the library in Flash terms) and within that, elements can be grouped using the <g> tag as classes. However current practice is to place any script driven interactivity at the beginning of the SVG file or in a separate JavaScript library (as used in the 'Bullseye' application). This would complicate matters for the developer seeking to reuse components, as there would be a requirement to isolate code pertaining to a class, as it would not necessarily be adjacent to the code for the SVG elements of the class. This problem can be overcome by placing the relevant script within the 'g' element. As a proof of concept this was tested and found to work, an example of an encapsulated SVG class is given in appendix 9. Ultimately this approach is limiting and as is discussed in the next section, manipulating the DOM might be a preferable approach to defining classes. Lewis et al (2003) have been developing the idea of an open source SVG programmer's application resource kit, which they describe:

'a framework for reusable, SVG-based GUI components………..made using SVG and associated standards such as EMCAScript, CSS and XSLT. Generally, component reuse depends on standardizing APIs and conventions through which a component communicates with an application.'

Lewis et al (2003) envisage components defined without styling in separate JavaScript files, which are used to generate instances of components each with a unique id tag, these can then have a CSS applied. However as Monnet and Shellman (2003) observe such projects to enable code reuse can reduce development time only if they are well supported and of high quality.

The resultant mapping of the SVG application to the control Flash model is, to a high degree, successful, no changes to the classes have been made and only limited changes to the message passing and variables are made. The implementation class models can be compared in appendix 6a and 6b. It is a feature of the applications that as a result of the similar mapping much of the code is, in principle, very similar. This is important, as one of the key aims of the project is to undertake an evaluation of the two formats, if the applications are similar in design and execution then any evaluation is more likely to succeed.

3.7 Limitations of the applications

Both applications were intended be fully extensible, with respect to proper use of variables to assist in redefining parameters such as speed of the target traversing the game play area, this is the case. A key limitation of both applications arises, in part, from the way they are modelled. The original scenario only envisaged one target on the screen at a time. This lead to both applications being developed using only one instance of a 'target' object, which traverses the screen according to parameters set by the level of difficulty.

It is now recognised that in Flash code of the generic form:

attachMovie("movieClipName", "NewMovieClipName");

and more specifically:

attachMovie("target", "target"+n,);

where 'n' is the 'nth' instance of the object.
This enables multiple instances of the target on the screen at one time, significantly enhancing the extensibility of the game.
In the SVG application, a similar outcome might have been achieved had JavaScript been used to create instances of a class by manipulating the DOM as Neumann and Winter (2002) argue is desirable. Appendix 10 demonstrates the SVG code required to create multiple instances of an object in this manner. This is a significantly more extensible method of instantiating instances of objects and would be a prerequisite in a more complex game.

Riel (1996) argues against the use of a God class, suggesting that it leads to poor encapsulation because it 'attempts to capture the central control mechanism so prevalent in the action-oriented paradigm' (p32). It can be argued that the 'Bullseye' applications breach this heuristic with the 'gamesWorld' class. However whilst it is the case that some classes contain primarily behaviour and get their data from the God class, it can lend clarity to a model and the developed application to have a class that sets global variables (especially in a game, which has multiple levels of difficulty) and controls the application status.

3.8 Application size

The developed Flash application consists of one .swf file of 55Kb, whereas the SVG application consists of 7 files totalling 81Kb. However this is not a true like for like comparison. For a true comparison it must be recognised that the sound files are in a Windows .wav format. Flash compiles these sounds as MP3, ASV3 also supports MP3 and to reduce the files in the SVG application to MP3 would save approximately 15Kb. Furthermore the all SVG standards (World Wide Web Consortium (1), 2003) support 'gzip' compression, if the JavaScript library was placed within the SVG file and compressed, this would save a further 10Kb overall (this was not done for reasons of simplicity). This would result in an SVG application that is only 1Kb larger than its Flash equivalent.

3.9 Conclusion to Design and Development

The developed applications conform to the requirements capture and specifications discussed earlier and as such are suitable to test the omissions revealed by the review of literature.

The following sections focus on the evaluation of SVG resources and the evaluation of the applications.

back to top