Discussing Development Process - Semantic Scholar

Computer Game – Discussing Development Process Carlos J. Costa DCTI- ISCTE and ADETTI/ISCTE, Lisboa, Portugal [email protected]

Manuela Aparício ATML- Academia Tecnológica Metropolitana de Lisboa, Lisboa, Portugal Lusocrédito, Lisboa, Portugal [email protected] Abstract. Developing game is anymore essentially a personal effort. The game development process is an important issue. In fact, games are becoming more and more complex task, involving multidisciplinary teams composed by member with specialised knowledge and skills. In this paper, we propose a framework, based in the information systems development literature and aplied to game development. This framework is also illustrated in a case.

Introduction In 1962, some students from Harvard thought that the institutes’ giant mainframe computers could be used for some other and much more interesting things than number calculating. In the beginning of the seventies, several companies started to see a commercial value in these games and began producing arcade machines that were placed in arcade halls and burger joints all over the world. More games saw the light of day. Especially Pong and later Packman were a big determining factor in bringing games to the public. In the nineties, the publishers and developers alike started buying each other. Those with money in the bank bought

1

Carlos J. Costa & Manuela Aparício: Computer Game- Discussing Development Process

competitors left and right. The industry consolidated it self throughout the decade in gigantic corporations. In the mid nineties, the economic value of interactive entertainment became bigger than the film industry. But games have never been surrounded with the same prestige and broad cultural interest. The games industry has grown to an enormous size. Game production is not a personal obsession. The game development process is an important business. In fact, games are becoming more and more complex task, involving multidisciplinary teams composed by members with specialized knowledge and skills. All games begin with an inspired idea, but an idea alone is not a project for a game. The idea must be elaborated upon to the point where the various team members can begin their work. Then, a working team, including programmers, artists and designers may be involved in the game process development. Programmers will need to make good on the promised features. Artists will need to bring the various characters and places to life. Some roles are related to artistic activities, like graphic designers, sound engineers and writers. Those roles may need some kind of artistic skills. Nevertheless, they may also have computing knowledge, in order to produce image and sound files. Game Designers will need to put the world together in a way that entertains. Testers will need to verify and test that the resulting experience, and communicate shortcomings back to the rest of the team. Since design documentation is integral to every role in the game development process, it will benefit greatly to better understand design documents. In addition to this documentation, the team must also create contents for the game. A set of underlying rules is at the core of any game. From physical simulation to artificial intelligence, all aspects of a game are ultimately encoded in rules. If a game contains abstract ideas, such as events, units, objects or people, then its code must contain rules that govern these abstractions and their properties. The groundwork that defines the way the game will work is already produced. The purpose of this phase is to realize the idea that has been put forth in the game documents. The development team will also begin prototyping the game that they have been designing. At this moment, the team has created his game conceptualization, the game design, the artwork, and the game logic. Now the team must bring it all together, do the necessary balancing and tweaking, and come up with a prototype that shows the potential of the game and the main purpose. Everybody has at some point played a game with an impossible level, a game that crashed every five minutes, a game with the glaringly superior strategy, or a game with an unpleasant interface. At some point during one of these unfortunate experiences, it is not uncommon to wonder whether the game's creators had ever actually played the game before shipping it out the door. Many of these pitfalls

2


could have been avoided if the care was taken to more rigorously test these games. Certainly if the team take quality into account it would provide a fun experience to the player then they must take the time to ensure that the game meets certain standards of quality and playability. Unfortunately, many times developers find that testing reveals more issues than they have time to resolve. In these cases the team must prioritise what to fix based on factors such as what is most important to fix or what is easiest to fix. Testing, balancing, and prioritising are necessary for eliminating the bugs and honing the "fun-factor" of the games. As long as game development process is an important issue, our purpose, in this paper, is presenting a framework. This investigation methodology it is framed in the artefact’s approach (Jarvinen, 2000) or of design science (Simon, 1997). The research process used in this study is based in literature review (ISD and multimedia development), in a framework construction and in the use of the framework in a specific situation. We access the artefact, through an analytical approach and through a case study. This evaluation also refines the artefact (Hevner et al, 2004). We also illustrate the use of this framework and discuss its employ.

In Search of a Development Process for Game Production Waterfall Development and Game Waterfall Process (GWP) Programmers began by noticing that in the development of a complex information system, they could divide the process in several phases. In this context, several models appeared more or less ad-hoc, with the purpose of surpassing the resulting problems of the little importance attributed to the development process (Canning, 1956). A great step was given when in the seventies the model waterfall was disclosed (Boehm, 1981, Enger, 1981). In this model, the several phases are clearly defined, constituting tight blocks, in which the results of a phase will correspond to the inputs of the following phase. It is in the context of this model that was disclosed the succession of the following steps in the information system development process: conception of the system, analysis, design, coding, implementation and maintenance. In each phases the information systems development process, team must define the corresponding objectives and final products. The waterfall development process is the one commonly used in game development. It has distinct phases that need to be completed in a certain order.

3


Once a phase has been complete there is no turning back and it is on to the next phase. Waterfall processes occur at various levels of complexity. The following are the larger categories found in game development, described in a common sequence of execution. Those phases are similar to those that characterises software waterfall development process (Enger, 1981): (1) Conception, (2) Game specification, (3) Storyboard production, (4) Analysis and Design Document, (5) Programming and production, (6) System Test (7) Release.

Improving Game Waterfall Process GWP has been used for years. It results in feedback along the way and everyone can be made aware of when each phase is complete. This way the development team and all people involved in the process are aware of the progress against the target date. So what is wrong with the waterfall process? By looking closely at this linear process it can be seen that each phase exposes the game to different classes of observers. The test team does not see the product until after the developers determine it is time for them to see it. In some cases the product managers will not see the game until the developers schedule a play test. If play tests are not scheduled early in the cycle, product managers may not see the game until late in the cycle. Alpha evaluators may not see the game until very late in the cycle. The reality is that as each of these teams sees the game, they may request drastic changes. This has a cascading effect, introducing problems into the game and sending the game back into phases that were expected to be complete, and possibly forcing the development team into emergency mode very late in the development cycle. The actual process may become very chaotic because the sequence of the waterfall development process has been broken. Development activity that should have occurred early in the cycle is actually occurring late in the cycle. In order to answer to this problem, Boehm (1988) proposed a spiral approach. Also, many unplanned minicycles may be occurring at the same time. These issues are common themes in game development post mortems. But, these are not new problems. Software engineers recognize those situations, because they have been plagued with them for a long time. The response has been new techniques, such as agile modelling (Schuh, 2005), rational unified process - RUP (Jacobsonet al. 1999, Kruchten, 2000), extreme programming - XP (Beck, 1999), and other hybrid processes to address the waterfall process's pitfalls. There are differences between the new approaches, but they all have a common theme. They all recognize that the software development process is iterative, not linear. Issues are

4


identified and problems arise all through the development cycle and need to be addressed. These techniques also seek to get more disciplines involved early in the development cycle, including testing personnel, product managers, business managers, developers, and others. The goal is to get as much interaction, dialogue, and goal setting done early in the cycle as possible. It also establishes formal communications between all involving parties. These communication mechanisms help as the product moves through the iterative process. All of the parties stay involved in all phases of development. Among the several models that constitute development of the waterfall it is of highlighting the V-model. •

The V-model is an approach that evidences the top-down design and the bottom up implementation.

•

The iterative approach, the development team can avoid great projects and have the certainty that something with value is given to the users in relatively small intervals of time. For example, as soon as the report of requirements is produced, the design may be initiated and programming, test and implementation may be done perhaps in less than two weeks. With the iterative development, the project is divided in smaller components. This allows that development teams demonstrate results earlier and that could obtain feedback of the users. Frequently, each one of the iterations is in fact a mini waterfall process

•

A prototyping model is used very frequently, because it is difficult to know all the requirements of the system in the beginning. Typically the users know which are many of the objectives that they want to see solved with the system but they do not know which the nuances neither every detail of the system and possible capacities. The use of prototypes comes to help significantly. In fact, when a prototyping model (Naumann & Jenkins, 1982) is used, development team builds a simplified version of the proposed system and introduces it to the user so that they criticize it. When giving its feedback, the user will contribute to incorporate in the system the proposed readjustments. Sometimes, the prototype is laid out as soon as the development team identifies requirements, being developed new programs. Typically, the phases of the prototyping model consists in defining and picking up of requirements (identical but fewer deepened than in the waterfall), designing, creating or modifying the prototype, evaluation, and refinement of the prototype and implementation of the system.

The prototyping consists of the creation of a model that works, instead of creating the drawing in the paper. In fact, when confronted with the drawing in the paper (screen layouts, structured language, flowchart, data flow diagrams),

5


the users can look at the design of the project and not noticing the real impact of all those outlines. The prototyping can be used basically at three levels: design of the interface with the user, performance design and determination of the functional requirements. The prototyping is used in most of the cases as helping way of conception of the interface with the user. This process is costlier than the traditional method of conception of the layout of the screen in the paper, however it is also much more effective. The second more frequent use of the prototyping is the modelling of the performance. The modelling of the performance is accomplished in a phase more assault of the development cycle than the conception of the interface with the user, consisting of the accomplishment of a model to evaluate the performance of the system. This use of the prototyping was especially useful before the beginning of the use the relational model in databases. With the use of data bases little alterations to the implementation remains. On the other hand, with the use of machines with powerful processing capacities, the evaluation of the performance of the system started to have smaller importance. This prototyping type is still important for situations in that the performance is reputed of great importance. The functional prototyping is more recent than the other types. This application of the prototyping is concerned with the iterative development of the specification. This approach becomes difficult to distinguish from the iterative development. The fundamental difference results from the fact that iterative development consists in production of a piece of the whole system while the prototype is developed with the purpose of not using the prototype in the end. This way the code developed for the prototypes doesn't present the same quality. However, this can be discussed, and in a lot of situations the prototypes can be incorporate in the final system. Gilb (1988) suggests that successful large systems started out as successful small systems that growth incrementally. Based in this premises, it was proposed the incremental approach. • An incremental approach performs some initial analysis to scope the problem and identify major requirements. Those requirements that will deliver most benefits to the client are selected to be the focus of a first increment of development and delivery. The installation of each increment provides feedback to development team and informs the development of subsequent increments. The spiral model (Boehm, 1988) was created to include the best characteristics of the waterfall and prototyping, at the same time that introduces a new component of evaluation of the risk. This model can be viewed as supporting incremental delivery, although Gilb (1988) arguing that spiral model does not fully support his

6


view of incremental development, as there are aspects of systems development that does not emphasize or include. Intimately related with the iterative processes is the participants' involvement in the development process. It is in this picture that new approaches appeared: • Joint applications development (JAD), • Participatory development (PD) • Socio-technical systems theory (STS). IBM originally presented JAD in the ends of the seventies, having received attention of the industry some years later. The JAD was related to the BSP (Business Systems Planning) IBM Methodology. This methodology emphasizes structure and agenda. Everything is explained in detail: "to do" lists are included, as are masters of useful forms (Woods & Silver, 1989). While JAD has as goal to improve system, PD main goal is the improvement of workplace. Consequently, criteria for validation are also different: while JAD uses quantitative criteria like performance index or time saving, PD has qualitative criteria based in democratic concepts, like mutual learning, mutual education or conflict resolution (Kensing & Munk-Madsen, 1993, Carmel, et al. 1993). A variant of the prototyping model is RAD or rapid application development (Martin, 1991). • RAD introduces very narrow limits of time in each development phase, leaning on strong tools of fast development, what allows more efficiency. Some researchers support that user involvement is especially important in prototyping development, especially in CSCW applications (Gronbaek et al. 1993). Some researcher identified two types of system development: a customer development environment and a package development environment. The first one has as goal the software development for internal use and usually not for sale. The package development has as goal software development for external use and typically for sale. Customer participation may be possible in both perspectives but in order to make it possible it is necessary to establish customer development links. As customer developer links can be used: support lines, survey, user interface prototyping, requirements prototyping, or interviews (Keil & Carmel, 1995). The basic premises of the reuse model (Woods & Silver, 1989) are that the system should be constituted using existent components, in opposition to the systems based on new components. Booch (1994) suggests an iterative incremental approach to object-oriented software development. It is in this scope that models supported in objects are incorporated. During the 90s, the advantage of objects orientation paradigm became obvious for many software engineering academics; they started to develop methodologies that integrated techniques and languages supported in this paradigm. But the large number of methodologies that

7


had been proposed reminded the negative experience that had already occurred with the structured methodologies. Consequently, the idea of creating a unified methodology seemed to be the most adequate to the case.

Rational unified process (RUP) and Extreme programming (XP) and agile modelling For RUP (Jacobsonet al. 1999), documentation (that is, artefacts) and use cases in particular play a key role in keeping the development process on track and well communicated to all participants. Use cases are collaboratively developed user expectations for the product, visually and verbally representing how an end user will interact with it. (In some cases, the user is another application or machine.) RUP continues from the initial use cases (based in Jacobson, 1992 approach) to more detailed artefacts that reveal the technical specification for the product. RUP acknowledges that at each phase of development facts may be revealed that cause a return to an earlier phase. In fact, RUP encourages this iterative recycling as opposed to discouraging it. The use of RUP lets a project stay on track, despite the existence of many mini-cycles, by forcing all teams to collaborate. Everyone is aware of the state of development and can make adjustments. Documentation plays a key role because it gets continually recycled to reflect the actual state of the project. This combined with the emphasis on multidisciplinary collaboration creates a communication feedback loop that lets decision makers make the right calls to keep the project on track. The discipline required to follow and document the iterative phases ironically contributes to less iteration in the development process. Recognizing the collaborative nature of development and the religious demand for documentation together decrease the need for changes. The RUP process is not endlessly iterative; it doesn't allow gross changes to design and specifications to the bitter end. It does assume that this process in itself will result in fewer and fewer changes to design and specification as the project proceeds towards the release date. During the 1980 and 1990 countless proposals had appeared. These had been called object-guided methodologies (Table 1). The XP (Beck, 1999) and agile approaches (Schuh, 2005) are philosophically similar to RUP, but with some key differences. XP is not documentation-centric in the traditional sense and it is influenced by RAD (McConnell, 1996). It is geared toward short cycle development and projects that are engineered in relatively small development groups. XP is very interactive-centric and proposes that through the process of peer programming and intense small team interaction, the program and product itself become the documentation. A key differentiator for XP is its emphasis on testing early in the development cycle. It proposes that test cases, test harnesses, and test examples should be created before the application

8


code is developed. This discipline forces the development team to think about the end result of the development before development begins. I believe this discipline, by forcing agreement on what the product is supposed to do before development begins, achieves the same results as use cases. Methodology SSADM (Weaver et al. 1998) Yourdon System Method (Yourdon, 1994) Engineer Information (Martin, 1991) Stradis- Structured Analysis, Design and Implementation of Information System (Gane & Sarson, 1982)] Booch (Booch, 1994) OMT-Object Modelling Technique (Rumbaughet al. 1991) OOSE - Object Oriented Software Engineering: (Jacobson, 1992) OOAD - Object Oriented Analysis and Design (Coad, P. & Yourdon, 1991) RUP (Rational, 1998) XP (Beck,1999)

Paradigms Structured approach incorporating spiral model Structured Structured emphasizing information architecture Structured Incorporating Object Oriented techniques Incorporating Object Oriented techniques Special emphasis to use case approach Object Oriented Incorporating Object Oriented techniques. Artefact oriented approach. Programming oriented approach

Table I – Methodologies used in the information systems development

XP is perhaps more iterative aware than RUP because it does not explicitly establish phases, in which use cases, class diagrams are adopted or design documentation is produced. XP is a scrum type development cycle that facilitates rapid development by discarding formal documentation phases; it substitutes, from the start of development, unit tests for documentation. The project moves along the cycle and continues to add unit tests as the product becomes more sophisticated. With each build, these unit tests are executed to make sure that the product is working according to the understanding of what the product should be doing. XP development is meant to be fast. Six months appears to be the average term of the development cycle. It also assumes a very close working relationship for all of the parties involved in the success of the product. If any team is not well represented throughout the cycle the development could suffer. Summarising, developing game is anymore essentially a personal effort. The game development process is an important issue. In fact, games are becoming more and more complex task, involving multidisciplinary teams composed of member with specialised knowledge and skills.

9


Proposing a Framework Phases of the Game Waterfall Process correspond to the basic activities that should be developed in a Game Project. A process may be decomposed in several iterations. In each iteration, the development team performed parts of each one of the following activities: • Conception • Game specification • Storyboard production • Analysis and Design • Programming and production • System Test The Conception is a result of interaction between several people. The business analysts, product managers, and senior development personnel get together and discuss what the game should be. Among other issues, they may discuss the following: audience, platform, development time frame, some of the features of the game and some of the high-level technical and artistic challenges The team may (or may not) produce a document describing all of the expectations for the game and some of the detail about how a team might approach development. In some cases, discussions results in a go or non-go decision. Then game specification is developed. In this phase, the product manager (and/or producer) produces a document is, describing what the user experience will be in the game. This involves play characteristics, platform decisions, and potential artistic mock-ups of the game. It is a description of the game from the end user's perspective. This document is circulated to high-level art directors, game designers, and architects. Game specification should include: title, synopsis and description, game summary, game overview, production details and game world. The game should have an appropriate title and a one-sentence description describing the game. Specifically distilling a game concept down to a single sentence can help pin down what's at the core of the project. The Game Summary contains an attention-grabbing paragraph describing the game, along with a list of novel features that the game will have. The Game Overview contains the details relevant to the high-concept of the game, such as: the concept, the genre, player motivation, a list of novel features, the target platform, high-level design goals, notes on how the game will play, etc. The Production Details describes the team, how they will accomplish the development of this game, and what the timeline for this undertaking will look like. The Game World section describes the setting and characters of the game. For a narrative style game, this means some back-story for the world, descriptions of

10


the characters and their roles they will play, and descriptions of any other important artefacts in the game world. For a non-narrative game, such as a puzzle game, it will still have some playing field, and objects interacting on that playing field in many different ways- the field, these objects and their interactions will need description. Development team is responsible for turning in one document containing all of the following: statement of artistic vision, functional content requirements, listing of content to be used and justifications thereof. Storyboard document is a panel or series of panels of rough sketches outlining the scene sequence and major changes of action or plot in a production to be shot on film or video (Simon, 2000, Begleiter, 2001, Larkin, 1996, Lockhart, 1983). The storyboard production includes two different dimensions: story and visual. In this phase some of the ideas presented in the game specification are clarified, the art style is defined and mock-ups are produced. The story is also explored, including scenario elements, player objectives and emotion elements in a global point of view, given by different people. In Analyse and Design phase, the engineers detail the architecture of the game. Analysis and design document was expressed in unified modelling language (UML). Core fundamental tools are defined and a platform for the game is recommended. The interactions between art assets and programming code are defined. Security and access methods might be part of the game technical specification. Implementation is performed in a phase where several tasks were already made. The decision is made to go ahead; architecture and concept documents are completed; the platforms have been established; the full team responsibilities are defined; and the development environment is up and running. Then people begin implementing the game. The producers, managers, and project leads form the organizational glue within their respective disciplines and across organizational lines. The artists and developers begin to develop the game using all of the documents that have been previously developed. Testing includes quality assurance system test, play testing, alpha and beta testing. Upon completion, pieces of the game go to the quality assurance organization, which takes all of the previously mentioned documents and tests the game against these documents. Any problems that are found are logged and reported back to the development teams. The development team responds by fixing the problems, redesigning certain key modules, or adding additional functionality. Once the quality assurance organization has an opportunity to give feedback to the development teams and the game is up in some working order, play testing begins. Producers organize group sessions to demonstrate the play characteristics of the game. Product and marketing managers as well as members of the

11


development staff usually attend these sessions. The goal is to validate or critique the play characteristics of the game at that point in time. These sessions may occur a number of times during the testing cycle. Each play test session involves feedback that must be addressed by developers. The feedback can require cosmetic or fundamental changes to the game. When producers, product managers, and developers agree that the game is ready for a wider audience, the producer will release the product to a select group of evaluators that provide feedback on the game. This feedback can result in required changes to the game. Some of these changes could be substantial. The assumption is that the changes will not be drastic in nature. In the beta testing phase the game is released to a much wider audience with little knowledge of the game. People play the game and provide feedback on problems that occur, features they like or dislike, and the overall game experience. For console games it is difficult to get a comprehensive beta test because the game is usually kept inside the company that is making it. On the Web the first release of a game is frequently considered the beta test. Sometimes this is called release 1.0 and is quickly followed by a subsequent more robust release. With all the feedback received and changes made, the game is released to the general public. Resources/Results: It is also important to identify what kinds of resources/results or artefacts (using the RUP terminology) are produced in each activity. Some of the examples may be the following: specification document, analysis document, storyboard, text, images, sounds, videos, game logic and finally a game. Tools Activities

Tools

Results

Conception

Brainstorming

Game specification

Sharing

Storyboard production

PDA + Upload

Storyboard document

Analysis and Design

Diagramming tool (ex.: UML)

Analysis and Design

Programming and production

Programming languages

Create/upload images files

Game platforms

Link images to scenes

Video, Image editors

Create/upload sound files

Upload CVS

Link Sound to sense Insert text to scenes Crete new game

System Test

Discussion tool

Tested Game

Table II – Activities, tools and results

12


Several tools may be used thought the development process. One of the most important is the platform used to develop the game. But, other tools may also be used. In the following table, we may see activities performed, main tolls as well as expected results.

A Case In order to illustrate the proposed approach, we describe here a case. This game was not developed in a game specialized company. In fact, a software development team developed it; incorporating designer and people form didactics. The game resulting from the need of incorporating a simulation task performed by professional education attendants. The client proposed the development of a trading game. In order to help in the production of the storyboard, designer used a PDA to sketch scenes.

Figure 1 – PDA support to storyboard

Images created in the PDA may be uploaded and put in a groupware platform, in order to foster interaction between team members. Details of the game were formalised using UML diagram. Use case diagrams were used to identify main interactions with players and roles that players performed.

13


S ubS ystem Navigation

Navigate

M erchant

Going to land

S ubS ystem M arket

Buying

M erchant.

Selling

Shiping

S ubSystem Pi rates Island

Paying M erchant.. Shi pi ng.

Sub S ystem CastaWay Isl and

Gi vi ng products

M erchant...

S hi pi ng..

Figure 2 - Use Case Diagram

Those diagrams were not very successful in the communication process with clients. In fact, the development of prototypes was much more effective. Nevertheless, as long as the development team has experience in development process, they found it useful as internal tool and also as support to game programming, as well as user and technical documentation production.

14


Scre en 0 ..* Jum pT oScreen ()

Cha ra cter

0 ..*

M erchant

Pirate

Castawa y

Se ll i ngPri ce : i nt Bu yin gPri ce : i nt

Steal M on ey ()

Stea lProd ucts ()

Se ll s () Bu ys ()

Figure 3 - Class Diagram Example

During the process of development new ideas will arise that need to be incorporated in the product. In a game, the creative feedback loop is a classic example of the need for frequent collaboration and iteration. So in the development process was identified the need of adoption of several tools. In want concerns to the development, the use of prototypes supported in Macromedia Flash, changed drastically from the initial intentions of the programmers. In fact, in the beginning of the project, developers expected to develop a system in Delphi. But, as long as Flash prototypes had good acceptance, it was decided to develop the game in Flash. This may be due to several factors. The two main factors are: lack of experience in the game development and programmers prejudices in what concerns the potentialities of Flash. The game was named “The Merchant”, which is about commercialisation of goods. The player, is the merchant, he has to purchase goods in the producer and sell those goods in to the customer, in order to achieve the maximum profit. The game takes place in the time of the Portuguese discoveries in the XV century, dangers also exist in the sea, that, this merchant needs to be prepared for the eventual pirates, which can rob money or life. The merchant is in a boat to navigate in the Ocean. In case it intends to go the earth to do business, the player should press on the sea zone. Even so, in a random way the following situations can appear: 1) City of Aljazair; 2) Green forest; 3) Island of the Shipwrecks; 4) Island of the Pirates. The game ends when one of the following situations is verified: to the end of some time of sailing or in case the merchant loses the whole merchandise and all the money. The figures above present the start screen with the number of defences

15


the number of coins and amount of merchandise should start the game buying goods. ,

. The player

Figure 2 – Entrance screen and the Green Forest (local merchant)

1) City of Aljazair and Green Forest Aljazair is a place where one can find merchant Adbul and the mercenary Afonso dos Passos. Afonso dos Passos in change of remuneration defends from the pirates' merchants. For every time that the player clicks on the mercenary, he " sells " a " defence ". Each defence will be worn-out for every time that goes by the pirates. Abdul sells (sell) goods receiving a value in coin. He also buys (buy) goods paying the same price. The sale or the purchase takes place being enough for such to point for the respective pot and to click. In case it is aimed for the top of the pot the transaction it is done more quickly (figure 3).

Figure 3 – City of Aljazair

In the green forest the merchant (player) founds a local merchant, he sells (sell) goods receiving a value in coin. He can still buy (buy) goods paying the same price. 3) Island of the Shipwrecks and the Island of the Pirates The shipwrecks are starved and ragged. Whenever a ship goes by its island they remove the merchants a part of the merchandise.

16


Once in the pirates' island, these extort all the money and the goods. However, they don't have any interest in the merchandise. In case the merchant gets to survive to the pirates, he can continues to sell goods. In case the player has defences, it can protect his own money. In the figure 4, are presented these two screens.

Figure 4 – Island of the Shipwrecks and the Island of the Pirates

To summarise the phases that were undertaken to create the framework, we have completed the following table (3). Activities Conception Game specification Storyboard production Analysis and Design Programming and production

System Test

Tools

Results

Comments specially concerning use of tools

Brainstorming

Partially adopted

Sharing

Not adopted

PDA + Upload

Storyboard document

Partially adopted

Diagramming tool (ex.: UML)

Analysis and Design

Adopted

Upload CVS,

Share results

Not adopted

Programming languages Game platforms Video, Image editors Upload CVS

Create/upload images files Link images to scenes Create/upload sound files Link Sound to sense Insert text to scenes Crete new game

Tools adopted were different from those planned

Discussion tool

Tested Game

Not adopted. Results could be improved if those tools could be adopted.

Table III – Activities, tools and results

The exact number of phases and iterations was not clearly established. In fact, the number of iterations was often very chaotic. This may be related to the

17


personal and emotional involvement of team groups that often forgot that game development is a professional task.

Conclusion Developing a game is anymore essentially a personal effort. The game development process is an important issue. In fact, games are becoming more and more complex task, involving multidisciplinary teams composed by members with specialized knowledge and skills. It is in this context, a framework was proposed. This framework was supported in several approaches, but then adapted to game production. During the process of development new ideas will arise that need to be incorporated in the product, in order to refine the game. In a game, the creative feedback loop is a classic example of the need for frequent collaboration and iteration. Iterative process including client participation also may have consequences either in tools to be used either in the adopted platform.

References Beck, Kent (1999) Extreme Programming Explained: Embrace Chang Addison-Wesley Professional. Begleiter, Marcie (2001). From Word to Image: Storyboarding and the filmmaking process. Michael Wiese Productions. Boehm, B. (1988) "A Spiral Model of Software Development and Enhancement." Computer (May, 61-72) Boehm, B. (1981) Software engineering Economics; prentice-Hall; Englewood Cliffs; NJ; Booch, G. (1994) Object-Oriented Analysis and Design with Applications, 2nd. Edition. Addison Wesley. Canning, R.G. (1956); Electonic Data Processing for Business and Industry; John Wiley & Sons, NY Carmel, E.; Whitaker, R. & George, J. (1993); “PD and Joint application Design: a transatlantic Comparison”; Communication of the ACM, June; Vol. 36; No.4. Coad, P. & Yourdon, E.. (1991) Object-Oriented Analysis, 2ª edição. Yourdon Press,. Enger, N. (1981) "Classical and Structured Systems Life Cycle Phases and Documentation" in Cotterman, W., Conger, J, Enger, N. Harold, F. (Ed) System Analysis and Design: A foundation to th 1980s; Elsevier North Holland; NY; Gane, T & Sarson, C. (1982) Structured Systems Analysis. McDonnell Douglas, Gilb, T. (1988) Principles of Software Engineering Management, Vokingham, Addison-Wesly,. Gronbaek, K.; King, M. & Mogenen, P. (1993) "CSCW Challenges: Cooperative Design in Engineering projects" Communications of the ACM; Jun; Vol. 36; No. 4; pp 67-77. Hevner, A. et al (2004) “Design Science in Information Systems Research” MIS, Quarterly, 28 (1), pp. 75-105

18


Jacobson, I. (1992) Object-Oriented Software Engineering: A Use Case Approach. Addison Wesley,. Jacobson, I., Booch, G. & Rumbaugh, J. (1999) The Unified Software Development Process. Reading, MA: Addison-Wesley, Jarvinen, P. (2000) “On a variety of Research Output Types”, Proceedings of the 23 rd Information Systems Research Seminar in Scandinavia, pp. 251-265 Keil, M & Carmel, E.; (1995) "Customer-Development Links in Software Development"; Communications of the ACM; May; Vol. 38; No 5; pp. 33-44. Kensing, F.& Munk-Madsen, A (1993) "PD: Structure in the toolbox"; Communication of the ACM; Jun; Vol. 36; No. 4; pp78-84. Kruchten, Philippe (2000) The Rational Unified Process: An Introduction, 2e. Addison-Wesley, Larkin, Greg. (1996) "Storyboarding: A Concrete Way to Generate Effective Visuals." Journal of Technical Writing and Communication 26:273-289. Lockhart, Bill. (1983) "The Storyboards of Palau." School Arts 82:37-39. Martin, J.; (1991) Rapid Application Development; MacMillan; NY; McConnell, S. (1996) Rapid Development. Redmond, WA: Microsoft Press, Naumann, J. & Jenkins A. (1982) “Prototyping: the new paradigm for systems development”, MIS Quaterly; 6 – 3; September, pp. 29-44. Rational. (1998) Rational Unified Process, Best Practices for Software Development Teams. A Whitepaper,. Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy & W. Lorenzen. (1991) Object-Oriented Modeling and Design. Prentice Hall,. Schuh, Peter (2005) Integrating Agile Development in the Real World, CHARLES RIVER

MEDIA Simon, Mark (2000). Storyboards: Motion in Art. 2nd ed. Focal Press, Simon, H., (1997) Administrative behavior: a study of decision-making processes in administrative organizations (4 th ed.). Simon & Schuster Inc. Weaver, Ph., Lambrou, N & Walkley M. (1998) Practical SSADM Version 4+, 2 nd edition. Financial Times Prentice Hall Woods, J. & Silver D.; (1989) Joint Application Design: How to Design Quality Systems in 40% Less Time; Wiley, NY Yourdon, E.; (1994) object oriented systems design: an integrated approach; Prentice-Hall International edition

19