Research Report 9/00
Software Product Lines - Three Examples
editor Jan Bosch
Department of
Software Engineering and Computer Science University of Karlskrona/Ronneby
S-372 25 Ronneby Sweden
ISSN 1103-1581
ISRN HK/R-RES00/9SE
Software Product Lines - Three Examples
editor Jan BoschISSN 1103-1581
ISRN HK/R-RES00/9SE Copyright © 2000 by Jan Bosch
Software Product Lines Three Examples
Jan Bosch (editor)
Table of contents
TABLE OF CONTENTS 3
1 INTRODUCTION 7
2 SOFTWARE PRODUCT LINE FOR GAMES 8
2.1 BUSINESS CASE ANALYSIS 8
2.1.1 Current situation 8
2.1.2 Post SPL situation 9
2.1.3 Software product line aim 10
2.1.4 Key figures 10
2.2 SCOPING 11
2.2.1 Feature definitions 11
2.2.2 Candidate product selection 11
2.2.3 Candidate feature selection 11
2.2.4 Feature graph specification 12
2.2.5 Depends-on 12
2.2.6 Mutually exclusive 12
2.2.7 Conflicts 12
2.3 PRODUCT AND FEATURE PLANNING 13
2.3.1 Expected feature graph specification 13
2.3.2 Modifications 13
2.4 PRODUCT LINE ARCHITECTURE DESIGN 14
2.4.1 Functionality-based architectural design 14
2.4.2 Architecture assessment - Maintainability 16
2.4.3 Architecture transformation 17
2.5 COMPONENT REQUIREMENT SPECIFICATION 17
2.5.1 Game Engine 17
2.5.2 User Interface (UI) 17
2.5.3 2D Gfx 18
2.5.4 3D Gfx 18
2.5.5 2D Sound 18
2.5.6 3D Sound 19
2.5.7 Game Communication 19
2.5.8 Network 19
2.5.9 Live Update 20
2.5.10 Verification 20
2.6 COMPONENT DESIGN 20
2.6.1 Game Engine 20
2.6.2 2D Gfx 23
2.6.3 3D Gfx 25
2.6.4 2D Sound 29
2.6.5 3D Sound 30
2.6.6 UI 32
2.6.7 Game Com 34
2.6.8 Live Update 35
2.6.9 Network 37
2.7 PRODUCT DERIVATION 1 – ALIEN SLAUGHTER 38
2.7.1 Features 38
2.7.2 Product Feature Table 39
2.7.3 Assessment 40
2.7.4 Data dictionary 40
2.8 PRODUCT DERIVATION 2 – MAGIQUEST 43
2.8.1 Features 43
2.8.2 Product Feature Table 45
2.8.3 Assessment 46
2.8.4 Data Dictionary 46
2.9 EVOLUTION 51
2.9.1 Scenarios 51
3 SOFTWARE PRODUCT LINE FOR AN E-COMMERCE COMPANY 54
3.1 BUSINESS CASE FOR WEBBER AB 54
3.1.1 The organization today 54
3.1.2 Organization goals 54
3.1.3 Investment analysis to convert to product line approach 55
3.1.4 Conclusion 56
3.2 SCOPING 57
3.2.1 Candidate products 57
3.2.2 Candidate features 57
3.2.3 Products areas 57
3.2.4 Feature graph 59
3.2.5 Conclusion 59
3.2.6 Product requirements 60
3.3 PRODUCT AND FEATURE PLANNING 60
3.3.1 Future planning 60
3.3.2 Future additions 60
3.3.3 Technical roadmap for the SPL 61
3.3.4 Extensions to feature graph 61
3.3.5 Cost for the inclusion of the extensions to the product line 61
3.4 PRODUCT LINE ARCHITECTURE DESIGN 61
3.4.1 The design 61
3.4.2 Defining system context 62
3.4.3 Archetypes 62
3.4.4 Product instantiations 62
3.4.5 Assessment 62
3.5 COMPONENT REQUIREMENTS 64
3.5.1 Product storage web page 64
3.5.2 Presentation pages 64
3.5.3 Search engine 65
3.5.4 E-mail sender 65
3.5.5 Shopping basket 65
3.5.6 Database connection 66
3.6 COMPONENT DESIGN 66
3.6.1 Introduction 66
3.6.2 Description 66
3.6.3 MailSender 67
3.6.4 DatabaseConnection 67
3.6.5 SearchEngine 68
3.6.6 Shopping basket 69
3.6.7 Presentation pages 71
3.6.8 ProductStorageWebPage 73
3.6.9 Scenarios 73
3.7 THE AB BYGGPRODUKTER PRODUCT 76
3.7.1 Requirements 76
3.7.2 Architecture 77
3.7.3 Product feature graph 77
3.7.4 Assessment 77
Design 79
3.7.6 Variability 80
3.8 THE BIBLIO BIBLIOTEKSSYSTEM PRODUCT 80
3.8.1 Requirements 80
3.8.2 Requirements description 80
3.8.3 Architecture 81
3.8.4 Product feature graph 82
3.8.5 Assessment 83
3.8.6 Design 85
3.9 EVOLUTION 88
3.9.1 WAP 88
3.9.2 Customer dependent buying 89
3.9.3 The Electronic Payment Scenario 89
3.9.4 Supermarket 90
3.9.5 Security 91
3.9.6 State of PLA after the changes 92
4 SOFTWARE PRODUCT LINE FOR REMOTE OPERATION 93
4.1 BUSINESS CASE ANALYSIS 93
4.1.1 Current situation 93
4.1.2 Prediction of costs and benefits 94
4.1.3 Conclusion 95
4.2 SCOPING 95
4.2.1 Candidate products 95
4.2.2 Candidate features 95
4.2.3 Conclusion 97
4.3 PRODUCT AND FEATURE PLANNING 97
4.3.1 New products 97
4.3.2 New features 97
4.3.3 Extended feature graph 98
4.4 PRODUCT LINE ARCHITECTURE DESIGN 98
4.5 COMPONENT REQUIREMENT SPECIFICATION 99
4.6 COMPONENT DESIGN 103
4.6.1 Communication 103
4.6.2 Application Logic 105
4.6.3 Blackboard 107
4.6.4 Package 108
4.6.5 Timer 110
4.6.6 Watchdog 112
4.6.7 HW specific 113
4.6.8 Rules (Product specific) 115
4.6.9 Example scenario 116
4.7 PRODUCT DERIVATION 117
4.7.1 Organizational and time considerations 117
4.7.2 PLA features 117
4.8 THE VIDEO CONTROL SYSTEM PRODUCT DERIVATION 118
4.8.1 Merging product and PLA features for the video control system 118 4.8.2 Deriving a product architecture for the video control system 118 4.8.3 Component selection and instantiation for the video control system 119
4.8.4 Video control system design 120
4.9 THE HEATING SYSTEM PRODUCT DERIVATION 121
4.9.1 Merging product and PLA features for the heating system 121
4.9.2 Deriving a product architecture for the heating system 122
4.9.3 Component selection and instantiation for the heating system 123
4.9.4 Heating system design 124
4.10 EVOLUTION 125
4.10.1 PLA present feature set 125
4.10.2 The existing architecture of the PLA 125
4.10.3 The security change scenario 126
4.10.4 The transmit images & video scenario 126
4.10.5 The house agent(s) scenario 127
4.10.6 The broker system scenario 127
4.10.7 The robot scenario 128
4.10.8 The house comfort scenario 129
4.10.9 Conclusion 130
5 CONCLUSION 131
REFERENCES 131
1 Introduction
This report presents the results of a course on software product lines. The assignment in the course was to develop a software product line based on the approach described in a book authored by me [1].
For details about the approach, I refer to the book. During the course, the students had to develop the following artifacts in groups:
• Product line architecture, including the business case analysis, product line scope in terms of features and products and other relevant aspects.
• Component designs, that is a detailed design for the components that are defined as part of the software architecture for the product line.
• Product derivations for two or three products that are built based on the shared assets in the software product line.
• Modifiability assessment. Each group got three change scenarios from the other groups, describing a possible change to one of the products in the product line or affecting software product line as a whole. These change scenarios had to be incorporated in the designed product line assets and an analysis of the modifiability of the software product line had to be performed.
• Prototype. For one of their products, each group should implement a small prototype that illustrated the various product line assets and the ideas underlying it.
The course consisted of 11 master students and 5 Ph.D. students. The master students were organized in three groups. Each group was free to choose a domain for their software product line.
The groups selected the following domains:
1. Games: The product line includes 2d real time strategy, 3d first person shooter and online role- playing games. The members of this group were: Richard Hultgren, John Johansson, Erik Mattsson and Mattias Svensson.
2. Web-based applications: The domain of the product line covers topics such as e-commerce pages, corporate information pages and database applications for the world wide web. The members of this group were: Magnus Hjelmer, Mats Ljungkvist and Faith Asekenye.
3. Mobile remote device control: The software product line offers access to a variety of systems using a WAP-enabled mobile phone. Examples of systems include safety and security systems, heating systems and consumer electronic devices such as video recorders. The members of this group were: Torbjörn Eriksson, Håkan Nilsson, Magnus Nilsson and Per Stråkendal.
This report presents the results of the groups as developed during the course. In the following sections the artifacts developed by each group are presented. Section 2 discussion the software product line for the games domain, section 3 web-based applications and section 4 the software product line artifacts for mobile remote device control.
The intention of this report is to illustrate the approach to adopting and evolving a software product line as presented in [1], but also to publicize the, very interesting, results of the course to the general public. I hope you will enjoy reading the material and that you will obtain inspiration for your own work with software product lines.
2 Software Product Line for Games
The members of the group developing this software product line were:
Richard Hultgren, John Johansson, Erik Mattsson and Mattias Svensson.
The purpose of this section is to describe a software product line for the gaming industry. By using the described software product line in developing games, it will decrease the time-to market for new products, which is one of the more important business attributes for the game industry.
This section starts with describing the business case for a made-up company that has been in the game industry for three games. The business case analyzes whether a software product line (SPL) will be a worthwhile investment. The SPL must be limited to hold features that all derived products needs, which is described in section 5. The SPL must also be able to embrace future additions and changes of features, therefore planning for this is discussed in section 6. How the actual SPL architecture will be assembled is described in section 7. From the architecture, components can be extracted that builds up the SPL, those components are included in section 8.
2.1 Business case analysis
This business case is based on a Swedish made-up company that has been in the gaming industry for several years. They have developed three games prior to this report and are analyzing if a Software Product Line (SPL) may streamline the developing of game products.
The three earlier games have all been based on the same game idea and are actually three different versions following each other. The game idea behind the earlier games was the first person shooter concept, where the player needs to remove all other players from the game by any means available.
The company feels that the pure first person shooter genre is becoming smaller and smaller because of the actual lack of original game idea. Therefore, the following games must move their focus to other niches in the first person shooter domain.
The next coming games are; a realistic combat simulator in a first person view and a medieval sneak game in a first person view or adventures. The two games share many components and have similar architectures, since they in the pure game are the same game type. The first game and the SPL will be developed side by side to limit the financial risk of the SPL; the second game will then later make use of the produced SPL. The company will not be dependant of success of the SPL, and can deliver the first game without the SPL, if it doesn’t work out.
The platform that our company focuses on is the Windows platform, using the DirectX API. This platform is one of the largest for games. We hope that Microsoft will release their console product so our share of the market will increase. Using the DirectX API also removes the need for modifying the games for specific hardware.
2.1.1 Current situation
Currently the company employee consists of eight game developers that worked in the company during the last game development, beside the normal necessary administrational personnel. The developers have all been in the gaming industry for at least two to three years in different game companies. In last years the developers have been educated and attained experience about new methods and processes used in the software engineer domain. In the last developed game the developers started to build small components for varying purposes. Therefore we think that the maturity level is high enough for our development team to be able to design and develop a SPL.
The current situation for game development and the Time-To-Market (TTM) are described in the following table.
Type of game development Time to Market
(calendar years)
New game with new technology 3-5 years
New game built on earlier game technology 2-3 years
Expansion packs (Maps and levels) 1 year
Figures above are based on actual statistics from existing game companies to develop a game from an idea to the actual release of the game. Most studied game development teams consist of six to ten
Software product lines or reusable components are not commonly used in the game industry, according to [1]. As the normal software-engineering domain matures further, the gaming industry will do so but slightly behind. This is because of the often highly competitive market for game companies, which doesn’t give any room for working an extra mile for later benefits. Another cause is the ever-changing technology that all games must adhere too and making it hard to develop a modification prepared architecture.
The strength of the current situation is that it’s easier to do optimization since all components can be more closely coupled, minimizing the flow of information and data. This is not possible in the SPL since some components must be extracted from the actual game flow and placed on a higher layer.
Unfortunately, closely coupling reduces the possibility for a well thought through design and architecture for the development. The current approach also has a low training level before new team members, outside experienced game developers, can be incorporated into the team and develop the game. The organization is also streamlined for developing one game at a time, and adapting it for the SPL may take longer than expected.
The cost will remain the same as the above tables state but may be decreased around one to five percent for each game. The cause of the decrease is that the teams become more and more streamlined into the first person genre’s domain problems and solutions. The team members neither have to adapt to a new organization nor adapt to a new way of thinking of the technology behind the games.
Training on software product lines isn’t needed, but the team may stagnate in their development process and not being able to embrace new development processes or ideas.
2.1.2 Post SPL situation
In the later years many companies have positioned themselves as a game genre leader and been sticking to a winning game concept. These companies will most likely benefit from an SPL since most games do have similar designs and ideas. This is the position where our company is located.
The benefit of the SPL can first be reaped after the first game, and the figures presented in this section are predicted from the presumed benefit of the SPL. The development of games today involves many none game specific components such as a GUI, network traffic handling and different engines for 3D graphics, music and sounds. This leads to many none game specific components that are considered more dull and uncreative. By reducing the development effort of these components, the team can be more concentrated on the actual development of the game idea and design.
The development of the SPL will not have a huge cost since most components are already well defined, developed and have been used in the first three games. We predict that the cost for developing none game specific components is around 15-25 % of the total development effort. This includes design, development and maintenance of the components in a game. That means that the Time-To-Market will be decreased by the same percent figure. With an SPL, the Time-To-Market will be less as explained by the following table. The percent figures, above, are set low, because the 3D engine will be purchased, but if it would be developed in-house then the percent figure will be substantially higher.
Type of game development Time to Market
(calendar years)
New game with new technology and an SPL 2-4 years
New game built on earlier game technology and an SPL 1,5-2,5 years
Expansion packs (Maps and levels) and an SPL 1 year
Figures above are based on the estimation that an SPL will decrease the development effort by 15- 25 % than it would take without an SPL. (The original figures are presented in the table above).
The expansion pack TTM will not be decreased with an SPL since this often only incorporates artists for creating new models, maps, levels with a very low involvement of developers.
Since the components must be lifted out from the actual game and placed on a more abstract layer than before, this will increase the cost for developing the none game specific components with five to ten percent. As stated in the beginning the SPL will be developed side by side with the next coming game, to minimize the financial risk for the company.
Cost With SPL
Game cost 75 %
None game specific cost -
SPL cost 30 %
Process change cost 5 %
Organization change cost 5 %
Total cost 115 %
The figures above describe the situation when the company develops the SPL and the first game product simultaneously. The percentages describe the more development effort that is needed for the next coming game with an SPL than with the current process without a SPL.
As the above table states, the cost for developing the next coming game will be higher than normal development. However, as more games are developed after the first game, the organization and process change cost will be removed completely and the SPL cost can be deducted on next three games.
The maintenance process will be greatly enhanced by an SPL, reducing problems before the release of the product since the lifted out components can be automatically tested more individually than before. As the first game receives their bug reports, the fewer problems will be present in the second and subsequent games. The effort per average maintenance will be decreased compared to the current situation.
Training of the team members will be increased before developing the SPL but this shows that the company is interested in their personnel and can make the team open for new ideas and solutions. If the game company hires any new personnel, then they need to understand the purpose and how to use the SPL. This makes the training of new team members more extensive than the current situation.
It may even be feasible to license the SPL or the components in the SPL to other companies for a considerable sum since it will help other companies develop their first person game quicker and can concentrate on the actual game design and development. The license can be extended by support, education and upgrade options that further increase the financial return of the SPL. Even in the worst- case analysis, where the SPL doesn’t save a lot in the actual development cost, the licensing can promote producing an SPL.
Unfortunately the game industry constantly change and new demands on games change too.
Therefore when the third game is developed with the SPL, it might become obsolete because of the changes. But if the technology dependant components can be updated along with the technology then this would not pose to be a problem. Therefore it is important that the very technology dependant components are lifted up from the game into the SPL. The benefits from the SPL would also be more noticeable if two games are developed side by side with the SPL. But this can first be achieved after the SPL has been developed; i.e. after the next coming game has been completed and released. Of course when the next game has been released and is successful, then the company can hire more personnel to be able to have two projects developed at the same time.
2.1.3 Software product line aim
The aim of the SPL will be to reduce the cost of developing none game specific components, and thereby reducing the cost of developing a new game. The main quality attributes in our organization are prioritized as follows: performance, maintainability, user friendliness and robustness. This must be taken into consideration when developing the product line.
2.1.4 Key figures
Cost Without SPL With SPL 1st
game
With SPL 2nd game
Game cost 75 % 75 % 75 %
None game specific cost * 25 % - -
SPL cost - 30 % 5 %
Process change cost - 5 % 2 %
Organization change cost - 5 % -
Total cost 100 % 115 % 82 %
* - None game specific costs are moved into the SPL cost, since the SPL consists of none game specific components.
The percentages describe the more, or less, development effort that is needed for the development of the next coming game than with the current process.
This shows that even though the initial investment of developing the SPL will decrease the cost for
2.2 Scoping
In the scoping process we have chosen the minimalist approach because the variability of the products within the SPL must be high. This is because different games should have different game specific features and it also limits the cost of developing the SPL and thereby the TTM for the first product using it. A smaller SPL is also a less financial risk.
A feature is defined as a logical unit of behavior that is specified by a set of functional and quality requirement [1].
2.2.1 Feature definitions
Feature Definition
2D graphics The product is capable of drawing 2D graphics.
3D graphics 3D drawing capable of true six degree's of freedom, colored lighting, mip mapping, portals, mirrors, alpha transparency, reflective surfaces, 3D sprites, scripting. 8-bit, 16-bit, and 32-bit display support. Direct3D under Window.
2D sound The product is capable of producing 2D sound.
3D sound The product is capable of producing 3D sound.
Local Area Network (LAN)
The functionality to transfer data over a local area network. In this feature we include Ethernet communication only.
Internet The functionality to transfer data over Internet (TCP/IP).
Multi player Settings and playing for up to 16 simultaneous human players on a LAN and up to 8 human players on the Internet.
Single player Settings and playing for one human player interacting with computer players.
Live-update Binary update of the software using the Internet to transfer the necessary files.
Environment rules A collection of what the entities in the game can/cannot do.
Scoring system A way of keeping track of the score obtained by the objects in the game.
Graphical User Interface (GUI) framework
A framework that allows an easy construction of a graphical user interface.
First Person Shooter Non-realistic environments, rules and creatures.
First Person Sneaker Realistic environments, rules and creatures.
Dedicated Server The product is run as a server that only has remote clients connected to it.
Game demos Demos of other games available from the publisher.
Virtual Reality The ability to present the game in virtual reality using a helmet, glasses or similar.
2.2.2 Candidate product selection
In this section we consider both the existing products as well as planned. We have identified three products from our current set of products that are suitable for the product line. They were selected not only because they represent the products closest to our business goals but also because they are the products most similar to our competitors’ products. Two other up-coming products have also been selected as candidates. These are the Game A (first person shooter) and Game B (first person sneaker) described in the business case. They are considered more important as they contain more of what we predict will be the most common future requirements.
2.2.3 Candidate feature selection
Below is a table in which we have identified in which products the features reside.
Candidate feature Existing games Game A (shooter) Game B (sneaker)
2D graphics X X X
3D graphics X X X
2D sound X X X
3D sound X
Local Area Network X X
Candidate feature Existing games Game A (shooter) Game B (sneaker)
Internet X X
Multi player X X
Single player X X
Live-update X X
Environment rules X X X
Scoring system X X
GUI framework X
First Person Shooter X X
First Person Sneaker X
Dedicated server* X X
Game demos** X
Virtual Reality X
Existing games are our current set of products.
* Demanded by the online-gaming rental service division.
** Requested by the publisher.
2.2.4 Feature graph specification
Feature Depends-on Mutually exclusive Conflicting 2D graphics
3D graphics Sound engine(P)
2D sound 3D engine(P)
3D sound Sound engine, 3D
engine
3D engine(P), TTL*
Local Area Network TTL*
Internet TTL*
Multi player LAN, Internet
Single player
Live-update Internet
Environment rules Scoring system GUI framework First Person Shooter First Person Sneaker Dedicated server P – Performance
TTL – Time to learn the product
* More advanced settings needed.
2.2.5 Depends-on
Clearly, both multi player and live-update depends on the network, as they need to send data over either the local area network or the Internet. The 3D sound engine takes use of the ordinary sound functions found in the sound engine as well as the needed entity location and relation calculated in the 3D engine.
2.2.6 Mutually exclusive
We have not found any features to be mutually exclusive except in the LAN feature (token-ring and Ethernet) but we made the decision not to include token-ring in our network definition.
2.2.7 Conflicts
If a 3D sound engine is included there will be more options to consider for the user. The same is true for both the LAN and the Internet feature. An increased number of user options will make the product more complex from the users point of view and increase the TTL.
Virtual reality is not yet fast enough (at least not the commercial and cheaper products) to be able to achieve the frames per second we want.
2.3 Product and feature planning
This section adds the expected future features to the SPL. There are also some features found only in the latest planned game that cannot be omitted despite the extra cost since they will be crucial for success in our future products. Giving support for these changes now saves us some money in the long run.
One of these features is the capability of including game demos as a part of the product. The product line will contain the needed utilities to play these demos. This is basically a business decision since the publisher is interested in such a feature. A 3D sound engine should be included, as we already have seen new products on the market using such a feature. A new game standard has been set and to maintain our status as a successful FPS game company we should include it since it cannot be left out in future products.
2.3.1 Expected feature graph specification
Feature Depends-on Mutually exclusive Conflicting 2D graphics
3D graphics Sound engine(P)
2D sound 3D engine(P)
3D sound Sound engine, 3D
engine
3D engine(P), TTL*
Local Area Network TTL*
Internet TTL*
Multi player LAN, Internet
Single player
Live-update Internet
Environment rules Scoring system GUI framework First Person Shooter First Person Sneaker Dedicated server Game demos
Virtual Reality P
2.3.2 Modifications
The only additions to the expected feature graph are the features Game demos and Virtual Reality but the additions will most likely grow as the market evolves.
2.4 Product line architecture design
The figure above describes our software product line architecture schematically. The interrelationships between the different components of the product line are further explained in section 2.5. See section 0 for a more detailed description of the Game Engine component.
The UI-component handles the user interaction. This is basically a framework for event handling.
The input to the game is sent to the Game Engine and is processed there according to the rules of the specific game. The Game Engine in turn sends information about the movement of entities and game events to the 2D and 3D Gfx and Snd components. The user interface also has a direct relation to the 2D Gfx component for handling of reactive responses, for instance if a button on the screen is pressed by clicking the mouse, the button is highlighted and if a menu item is clicked, the menu is expanded, etc.
2.4.1 Functionality-based architectural design
Product context
The product context in which this product line should operate in is DirectX-based Microsoft Windows environment. The representation of the User Interface component is included in the PLA but the UI framework supported only contains the abstract implementations of buttons, menus, lists, and edit boxes. The visual representations of these framework concepts (skins, bitmaps, etc) are implemented as product specific.
Archetypes
The only clearly defined archetype in our PLA is the relation between the Server and the different types of entities, which is of client-server type, within the game engine. Although the game engine is highly product specific the common internal structure if it should be implemented as such, according to the product line architecture.
UI
Game Engine
2D Gfx
3D Gfx
2D Snd
Game Com Network
Live Update Input Device Output Device
3D Snd
Dotted arrows are control flow.
Line arrows denotes inheritance.
Arrows with filled circles are aggregate relations (“has”).
The server has a number of clients, entities. An entity can either be a player or a prop. An example of a prop is any type of moving, dead objects for instance a projectile, a movable stone, a door or a window.
Players are actors in the game. A local player is controlled by user input. User input also controls the remote players, but trough a network layer (see the com objects in section 2.4.2). Finally, the bot is a type of player that is controlled by some artificial intelligence. An example of a bot is a monster.
Both players and Props are constrained by the Environmental Rules.
The server keeps track of the movements and the events performed by the entities. The world is a construction of the static objects in the game area. Static objects are walls, floors, staircases etc.
Product instantiations
We have found that the client-server archetype is suitable for all variations of the product i.e. Single Player, Multi Player and Dedicated Server. The current architecture should have the ability to cover all variations of the product.
If one should try to define the extremes of product instantiations of the PLA, one approach can be to take the traditional pure first-person-shooter game as one extreme and a more adventure-oriented game as the other.
The instantiation of the first product has emphasis on the environment, the graphics and the performance while the second product is more of an adventure game. The development effort of the first game lies in the calibration of the environmental rules, and the critical component of the second game is the product specific parts of the Game Engine, which handles the strategy and gaming rules.
The First-Person-Shooter game development is concerned with components that lie within the PLA and the refinement of those components is beneficial for the entire PLA. The adventure game, however, which has the focus on the Game Engine part does not contribute to PLA in any other ways than perhaps improving the staff experience. These two examples show that at least this range of product instantiations is covered by the architecture.
Game Engine
World 3D
Server
Player
Local Player Remote Player
Bot Network
User Input Artificial Intelligence User Input
Prop
Environmental Rules Entity
2.4.2 Architecture assessment - Maintainability
We found that the divided game engine was too fine-grained for the assessment of the maintainability attribute, so we decided to assess the Game Engine as one component. We used the first person shooter as our reference product for the assessment.
Maintainability scenarios
1. Add a new map to an existing game.
2. Replace the 3D Gfx component since the old 3D Gfx component has become obsolete.
3. Patching of the Game Engine component through the Live Update.
4. Change the game type from a realistic combat simulator to a unrealistic fantasy game.
5. Add a Virtual Reality component.
6. Remove 3D Snd component from the game.
7. Adding a network protocol for in-game communication.
Scenario consequences
1. New binary map files are added to the map directory.
2. Probably adapt the interface of the new 3D Gfx component to the existing game.
3. Replacement of existing binary files of the Game Engine.
4. Environmental rules must be changed in the Game Engine.
5. New input/output device must be implemented and connected to the UI component.
6. Changes to the interfacing components, which is the Game Engine component.
7. The Network component must be changed in order to use the new network protocol.
Scenario Component
1 2 3 4 5 6 7
Game Engine X X X X
World server
User Interface (UI) X X
2D Gfx
3D Gfx X
2D Snd
3D Snd X X
Game Communication
Network X
Live Update
X – A change in a component.
Component Changes
Game Engine 4
User Interface (UI) 2 2D Gfx
3D Gfx 1
2D Snd
3D Snd 2
Game Communication
Network 1
Live Update
2.4.3 Architecture transformation
Variants: No variants of the product line architecture exist. According to the minimalistic approach, which we have taken, this architecture should only cover the minimal common parts of the chosen domain.
Optionality:
• Different types of Game Communication components such as Voice- and Text/Chat communication. These features are optional for each specific product as described by this figure.
• Alternative input UI components, such as VR-gloves, keyboard input, or other controlling devices. (not described in the architecture)
2.5 Component requirement specification 2.5.1 Game Engine
Functionality
Functionality in this component will be to control and run the game, it is very game specific and only a few internal modules can be reused. The component will run a server that clients (users/players) will connect to. No difference if the user is local or connecting via the network.
Interfaces
The Game Engine has interfaces to the User Interface, 2D Gfx, 3D Gfx, 2D Snd, 3D Snd and the Game Communication.
- Provided: The provided Interfaces will be to the 2D Gfx, 3D Gfx, 2D Snd and the 3D Snd components. Network traffic will be exchanged with the Game Communication component.
- Required: It will require interface from the User Interface.
Quality Attributes
The quality attributes in the Game Engine is performance and robustness. It is of utmost importance that the Game Engine can manage to perform the game play and that the Game Engine doesn’t goes into a faulty state during the game play.
Variability
The Game Engine will be replaced in each product, except for the client/server modules that isn’t specific for each product.
2.5.2 User Interface (UI)
Functionality
The component will receive user inputs from the user and presents the user outputs to the user.
Interfaces
- Provided: The User Interface provides an interface to the Game Engine. The component makes inputs to the Game Engine. The inputs can be from keyboard, mouse or different controlling devices, such as joysticks or game pads.
Game Com
Voice Text/Chat Game state
- Required: The User Interface requires interfaces to the 2D Gfx, 3D Gfx, 2D Snd and the 3D Sound components, for output to the user.
Quality Attributes
Maintainability so the component can be updated with new types of user interaction devices.
Variability
The component doesn’t change between the products.
2.5.3 2D Gfx
Functionality
The component draws and presents images onto the user screen.
Interfaces
- Provided: The 2D Gfx component provides interface to the User Interface.
- Required: The 2D Gfx component requires interface to the Game Engine and the User Interface.
The component receives control data, what images to show, from the Game Engine. It also receives control data directly from the User Interface for the displaying images that do not require to be controlled by the Game Engine.
Quality Attributes
Robustness must be high so that the user interaction completes flawless.
Variability
The image format is likely to change.
2.5.4 3D Gfx
Functionality
The component function is to calculate the world image and the camera angle for the user view.
Interfaces
- Provided: The 3D Gfx component provides an interface to the User Interface. The output from the component to the User Interface, is a modeled 3D view ready to be shown for the user.
- Required: The 3D Gfx component requires an interface to the Game Engine. The component receives a virtual world from the Game Engine.
Quality Attributes
This component needs much CPU time and is very sensitive for the performance quality attribute.
Variability
All products in the product line are going to use the 3D Gfx component and the worlds from the Game Engines are going to in the same format in all products. So the variability should not be a problem in this case.
2.5.5 2D Sound
Functionality
The Sound component plays the selected sound at the right time.
- Required: The 2D Snd component requires an interface to the Game Engine. The component receives control data in form of what sounds to play from the Game Engine.
Quality Attributes
Maintainability is important for bug fixing in this component.
Variability
The sound format is likely to change over the time.
2.5.6 3D Sound
Functionality
The Sound component plays the selected sound at the right time.
Interfaces
- Provided: The 3D Snd component provides an interface to the User Interface.
- Required: The 3D Snd component requires an interface to the Game Engine. The component receives control data in form of what sounds to play from the Game Engine.
Quality Attributes
Maintainability is important for bug fixing in this component.
Variability
The sound format is likely to change over the time.
2.5.7 Game Communication
Functionality
The component derives 3 variations: Voice, Text/Chat and Game State. The Voice variation makes it possible for the users to communicate via voice in the game. The Text/Chat variation transmits text between the users so that they can chat. At last the Game State variation sends data regarding the game play, not for the users to see.
Interfaces
- Provided: The Network component. The data that comes from the Game Engine can be pure voice, text/chat and game specific control data.
- Required: The Game Communication component requires an interface to the Game Engine.
Quality Attributes
Robustness so that the network interface works properly in the game play. Maintainability is important for the maintenance of the component.
Variability
The included modules of the component will probably not be the same in all products. The Voice, Text/Chat and Game State variations should be independent from each other.
2.5.8 Network
Functionality
Network component connects, sends and receives raw data.
Interfaces
- Provided: The Network component requires interface to the Game Communication component.
- Required: The Network component provides interface to the Live Update component.
Quality Attributes
Robustness, the component must handle all kinds of network disturbance.
Variability
The component will be the same in all products.
2.5.9 Live Update
Functionality
The functionality of the component is to update game files and receives new files for the game over the Internet.
Interfaces
- Required: The Live Update component has an interface to the Network Component. The component sends and receives data through the Network Component.
- Configurable: The components must be configured of the game file structure.
Quality Attributes
Robustness, so that the component doesn’t make the game faulty in some sort of way. Maintainability, the component will be reused so it must be easy to maintain.
Variability
The component will be used as it is in most of the products.
2.5.10 Verification
No verification can be done at this moment.
2.6 Component design
In this section, the design of the various components is discussed.
2.6.1 Game Engine
Description
The Game Engine is the core of the game. Here the different Entities that make up the World are defined. An entity is the building blocks of the world, and the world exists entirely of them. Entity is also the base class for Players, Weapons, Projectiles and Armors. New game specific entities can be added to the component by deriving from the Entity class. The Player class is a representation of an actor, which can either be a human player or a computer player. The human player class is controlled by an input device from the User Interface, or controlled by a remote player through the network.
Each entity has a rule set that affects the entity, such as friction or velocity. The world is used by the 3D Gfx component, which uses the User Interface for output.
The server in the Game Engine receives updates from each entity; and updates the world according to rule set in each entity and world. The server also manages the Players in the game and controls which map is played. The game server uses the 2D Snd and 3D Snd to play sounds around the local player.
Class diagram
Data dictionary
Name Entity
Description An entity is the base class for objects in the virtual game world.
model Entity model.
texture Entity texture.
position Position of entity in x, y, z. Upper left corner.
id Identification of entity.
Attributes
entityTypeName Type name of the entity.
getName Returns the name.
createEntity Creates the entity with specified properties.
destroyEntity Removes the entity from the world.
Methods
getProperties Returns the properties for the entity.
Relations Entities exist in the World.
S e r v e r m a x P a y e r s c u r r e n t P l a y e r s d e d i c a t e d l e v e l : W o r l d
s t a r t ( ) q u i t ( ) i n i t ( )
P l a y e r s t a m i n a s t r e n g t h a g i l i t y h e a l t h m a n a m a g i c p e r c e p t i o n a r m o r p l a y e r N a m e t e a m s c o r e i n v e n t o r y
L o c a l P l a y e r k e y S e t t i n g s
R e m o t e P l a y e r
g e t P l a y e r ( ) B o t
skill
W e a p o n f i r e R a t e w e i g h t E n t i t y
m o d e l t e x t u r e p o s i t i o n i d
e n t i t y T y p e N a m e : E n t i t y R u l e s
g e t N a m e ( ) d e s t r o y E n t i t y ( ) c r e a t e E n t i t y ( ) g e t P r o p e r t i e s ( )
E n t i t y R u l e s f r i c t i o n d e n s i t y v e l o c i t y 1
W o r l d : E n t i t y : W o r l d R u l e s
s h u t d o w n E n g i n e ( ) s e t W o r l d ( ) s e t B s p ( )
w o r l d R e n d e r Q u e ( 1
1 . . n
W o r l d R u l e s g r a v i t y w i n d d e n s i t y v i s i b i l i t y
1
P r o j e c t i l e w e i g h t a p d a m a g e r a n g e
A r m o r a r m o r T y p e a r m o r V a l u e
Name Player
Description This entity is specific for players.
stamina strength agility health mana magic perception armor player name team score Attributes
inventory
Attributes for the player.
Relations Derived from Entity.
Name LocalPlayer
Description The local user controls this player entity.
Attributes keySettings Settings for the local player.
Relations Derived from Player.
Name RemotePlayer
Description A remote user, through multi-player, controls this player entity.
Methods getPlayer Gets the remote player.
Relations Derived from Player.
Name Bot
Description This player is controlled by an Artificial intelligence.
Attributes skill The skill of the bot.
Relations Derived from Player.
Name Projectile
Description Projectile is needed for a weapon to fire.
weight Weight of projectile.
ap Armor piercing capabilities.
damage Damage caused by projectile.
Attributes
range The range of the projectile.
Relations Derived from Entity.
Name Armor
Description Armor objects for entities.
Attributes armorType The type of armor. Kevlar, chain, etc.
armorValue Resistance of the armor type.
Relations Derived from Entity.
Name Weapon
Description Weapons can be used by a player to fire upon other players.
fireRate The maximum fire rate of the weapon.
Attributes
weight Weapon weight.
Relations Derived from Entity.
Name Server
Description This class handles all the game specific details. It creates and updates the world. Handles the connection from the local and remote players.
maxPlayers Maximum number of players on server.
currentPlayers The current number of player on the server.
dedicated Dedicated mode.
Attributes
level The level in use.
start Starts the server to handle the world and player.
quit Quits the server.
Methods
init Initiates the server properties.
Relations
World
See 3DGfx.
Name EntityRules
Description The rules for the entities.
friction The entity friction.
density The entity density.
Attributes
velocity The entity velocity.
Relations Used by Entity.
Name WorldRules
Description Rules for the world.
gravity The gravity of the world.
wind The wind .
density The density of the air. Higher altitude means lower density.
Attributes
visibility The visibility in the world.
Relations Derived from Entity.
2.6.2 2D Gfx
Description
The 2D Gfx component consists of an inheritance hierarchy of abstractions of two-dimensional objects. The purpose of this component is to paint 2D-graphics to the screen. The GUI class in the UI component uses this component to draw the menus, list boxes, edit boxes, and texts in the game.
