Enhancement Proposal of SuperTuxKart

Team Neo-Tux Latifa Azzam - 10100517 Zainab Bello - 10147946 Yuen Ting Lai (Phoebe) - 10145704 Jia Yue Sun (Selena) - 10152968 Shirley (Xue) Xiao - 10145624 Wanyu Zhang - 10141510

1

ABSTRACT

This report outlines our enhancement proposal for SuperTuxKart, the addition of an endless game mode. The main motivation for this mode is to enhance the attraction of SuperTuxKart, thereby, leading to an increase in the number of players. It is also aimed to create a more distinctive kart racing game from its rival, Mario Kart.

The report explores our proposed alternatives for implementing this feature and the use of the SAAM analysis for examining the alternatives discussed. This analysis was crucial in determining which of the alternatives has more advantage over the other. The analysis involves exploring the pros and cons of each alternative in connection to the Non-Functional Requirements of the proposed enhancement feature.

We also investigated the effects of this new feature on other subsystems in our conceptual architecture. This was achieved by analyzing the source code to discover the files and directories that would be affected by the new feature. This in-turn, helped us in identifying the corresponding subsystems impacted by the feature. After this, we explored our plans for testing the impacts of the new feature on the subsystems and the potential risks of the enhancement feature.

2

TABLE OF CONTENTS

1. Introduction and Overview 2. Enhancement Proposal 2.1.The Proposal 2.2. The effects of the enhancement on the maintainability, evolvability, testability, performance of System 3. Alternatives for realizing the proposed enhancement are presented 4. SAAM analysis for the alternatives 5. Diagrams 5.1. Use Case Diagram 5.2. Sequence Diagrams 6. Effects of the enhancement on the high level and low level architecture 6.1. Impact on the Concrete architecture 6.2. Impacted directories and files 7. Architecture styles and Design patterns 8. Testing/Impact Analysis - Plans for testing the impact of interactions between the ​ proposed enhancement and other features 8.1. Summary of the interactions of the proposed enhancement with other features 8.2. Testing Analysis 9. Potential risks due to enhancements 10. Development team issues 11. Discussions of the limitations of reported findings 12. Concurrency 13. Lessons learned 14. Conclusion 15. References

3

1. INTRODUCTION AND OVERVIEW SuperTuxKart is a free and open-source kart racing game developed in 2004. For the first assignment, we explored the game’s conceptual architecture. This was done in order to create a blueprint of what we envisioned the structure of the SuperTuxKart game to be. The second assignment involved looking into the source code to determine the concrete architecture of the game. The process helped to both verify and eliminate some of our conceptualized ideas of the game’s architecture. We also discovered a couple of new components and dependencies among the subsystems in the architecture.

This final assignment is aimed at proposing an enhancement feature for SuperTuxKart that has not been implemented. The purpose of this is to delve into a more practical approach of analyzing and implementing part of a game’s architecture. The approach will be based on the knowledge from the analysis of its conceptual and concrete architecture. The current state of the system relative to the enhancement was evaluated during this process and various methods of implementation of the proposed enhancement was explored. The SAAM analysis was used to evaluate the game’s architecture in order to examine the effects of each implementation pertaining to the Non-Functional Requirements of the enhancement feature. We then were able to choose the better implementation method of the two.

This report also outlines our investigations into the effects of our chosen implementation method on the files and directories at the low and high levels of the STK architecture’s subsystems. We also discussed our plans to test the interactions between our proposed enhancement, other features in the game and the potential risks associated with the enhancement feature.

2. ENHANCEMENT PROPOSAL 2.1. The Proposal - Endless Game mode The new feature proposed is the addition of an endless game mode to SuperTuxKart. The motivation behind the implementation of the feature is due to the constant scrutiny of the game in comparison with its rival, mario kart. We also wanted a feature that would appeal and entice loyal players of STK. This is to be achieved by creating intrinsic satisfaction to players experience by beating their high score. This accomplishment motivates them to seek and repeat that experience. This feature is also appropriate for this assignment as it affects a few subsystems in our architecture.

Once the mode is chosen, the player does not select any of the available pre-game options such as the difficulty level and the tracks. The mode consists of several world maps connected together and is it designed to randomly choose maps to load. This gives the player the opportunity to experience racing on the locked tracks unavailable to him/her in other modes. If the player already has all the tracks unlocked, then the mode just randomly places all the tracks into the game world.

An heart item for extra life, and a clock item for extra time will be created and added into the endless game mode. However, other existing game items such as the gift box and banana peel are still available to the player. In this mode, the user is given a challenge to complete within a certain time limit and the game ends whenever the time limit is up. The players are awarded achievement points for the total distance covered during the race. This motivates them to strive towards exceeding their previously attained score. To also prevent players from getting

4

bored with this new feature, they are rewarded for every 5,000m distance covered during the race. The rewards range from additional game points to the heart and clock items. When the user completes a challenge, they get transported to a new game world made up of a different track, a different challenge, and a new time limit.

2.2. The effects of the enhancement on the maintainability, evolvability, testability, performance of System Maintainability involves the ease and speed at which the system can change and adapt to new requirements. Our current architecture for the SuperTuxKart game has high cohesion amongst its subsystems and this allows for the easy implementation of the new feature into the game since every subsystem is responsible for doing one thing. This allows developers to easily maintain both the pre-existing and newly written code. They are also able to easily trace faults caused by error in the code. For example, if a glitch were to happen when loading a world map, the code associated with this feature can be easily traced since the only one component involved in map loading is also located within the controller subsystem.

The capacity at which the system is able to adapt to changes over time refers to its evolvability. Since maintainability increases evolvability, the addition of this enhancement does not hinder SuperTuxKart’s ability to evolve. Testability is the ease at which faults in the software are found. For every new script file added, tests need to be written in order to ensure each new script behaves as they should and not affect negatively to the existing functionalities in the game. Performance refers to the game’s operating speed. Our new feature affects the current performance level of the game due to the requirement of loading and connecting various world maps together. This means more resources would be needed to construct this new game mode.

3. ALTERNATIVES FOR REALIZING THE PROPOSED ENHANCEMENT ARE PRESENTED We will be looking into ways to integrate the connection of the various game worlds for the different challenges in our proposed endless game mode.

For the first implementation, the game worlds would be preloaded at the beginning of each challenge causing a delay in the game. Preloading a map would take about a minute at most to load all the textures, meshes and materials in the background. Also, if the player’s computer has a slow hardware disk drive it could take longer. Additionally, information on the challenge and tips for being successful will be displayed for the player to read on the loading screen during the preloading time.

The second implementation involves all the game worlds set up at the beginning of the mode. So when a player finishes one challenge, they automatically get transported into the next game world. Compared to the first implementation, the satisfiability in terms of the flow of ​ the game is better as each world transitions into the next smoothly. Players would not have to wait every time they finish the challenge for that track. However, since this implementation involves having to preload all the available maps before the games starts, a large amount of memory will be required to store them.

4. SAAM ANALYSIS FOR THE ALTERNATIVES

5

We applied the SAAM analysis to compare and contrast our two possible implementations. The analysis was used to evaluate the game’s architecture, the process of achieving specific application quality for the system and how possible changes in the future will affect the system’s quality attributes based on hypothetical cases studies. For our analysis, we outlined SuperTuxKart’s Stakeholders relative to their Non-Functional Requirements (NFRs) as shown below.

Players Developers Testers

Performance Efficiency Testability

User Satisfaction Maintainability Maintainability

Next, we examined how each of the possible implementations, as mentioned earlier, will affect these Non-Functional Requirements. The table below outlines the descriptions of the non-functional requirements in addition to the pros and cons of each implementation.

Non-Functional Description Implementation 1 Implementation 2 Requirements

Performance Response time for Bad Good (Players) loading the game The response time for The response time is faster in worlds should be less loading the mode will be this implementation since the than one minute 95% slower than the second maps have already been loaded of the time implementation as the maps before the player enters a new need to be loaded at the start track. of each race.

Efficiency In standard workload, Good Bad (Developers) CPU usage shall be Only the features of the The features from all the less than 60%, leaving currently loaded game world preloaded game worlds takes up 40% for background takes up the system’s the system’s memory and jobs resources. resources.

Testability Test cases written to Good Good (Testers) cover the newly It is easy to create test cases It is easy to create test cases to implemented feature to test the features of this test the features of this new must adequately test new mode if the developers mode since we already have a the system to identify have a thorough good understanding of the all the faults. understanding of the functionalities of existing functionalities of existing features we’ll be integrating into features we’ll be integrating it. into it. Bad Bad If the feature is developed by If the feature is developed by new contributors to the game new contributors to the game who do not have a good who do not have a good understanding of the existing

6

understanding of the existing features, it might be difficult to features, it might be difficult create test cases to create test cases

Maintainability Automated tests must Good Good (Developers / exist for all the newly Tests are easily automated Tests are easily automated since Testers) added components in since high cohesion exists high cohesion exists amongst the order to validate amongst the components components changes made to the existing system.

User Satisfaction The loading time of Good Bad (Players) the world maps should The user will be required to Requires a long time to load the not hinder the player’s wait for a short amount of world maps at the beginning of satisfaction of the new time as each world map the mode, thereby increasing the game mode loads, but this is better than player’s waiting time. waiting for a longer period of time at the beginning of the game.The loading screen is also built to provide information about the next challenge.

Performance refers to the game’s operating speed. This requirement is specified such that the response time for loading the game’s resources should be less than one minute 95% of the time. Implementation 1 requires a longer time to preload all the features of the new world map at the beginning of each challenge. However, Implementation 2 enables smooth transitions into all the world maps since they’ve already been loaded and stored in the memory.

In terms of efficiency, the CPU usage should be less than 60% in standard workload. The second implementation performs poorly in relation to this NFR as it requires the preloading and storage of all the world maps and features. This takes up a lot of the player’s hardware resources.

Both implementation methods are evaluated equally on testability and maintainability. In regards to testability, test cases must be created to cover all the newly added features in order to identify faults in the system. The pros and cons depend on how well the developers and testers understand the functionalities of the new feature to be added. If they have a thorough understanding, the test cases will be easier to generate. Maintainability deals with the running of automated tests for the newly added features. Since the enhancement doesn’t have much substantial effect on our high level concrete architecture, the architecture is still highly cohesive and easily to automate the tests.

User satisfaction is concerned with the player’s overall contentment. So far, the biggest drawback of the new feature would be the loading time of the world maps. For the first implementation, the waiting time has already been distributed over the game play period. The

7

player’s focus is also to be engaged during the waiting time by displaying details on the next challenge and also providing some helpful tips for successfully completing it. However, for the second implementation, the waiting time at the start of the game would be significantly increased and this is not favourable from a player’s perspective.

The first implementation was chosen as our method of implementation due to more favourable advantages from the technical perspective (i.e. it is more efficient in terms of resource usage).

5. DIAGRAMS 5.1. Use Case Diagram

The use case diagram illustrates the actions carried out by players in the new mode. The player can choose a kart, play the game, pause the game, exit from the game, select game settings, and view his/her info. Playing the game involves actions such as controlling the kart, colliding with the game world objects, completing challenges, and so on. Selecting the settings implies that the player can make changes to game settings such as adjusting the game’s audio volume, screen resolution and language. Viewing the player’s info involves the user checking his/her achievements and highscores.

5.2. Sequence Diagrams Scenario 1 The sequence diagram below illustrates the scenario of the player obtaining a heart item during the game. The endless_mode_world script file in the controller is triggered when the heart item is collected. It then calls the kart.cpp script file which uses the method from the item.cpp file to add the collected item to the player’s kart. The item.cpp then communicates back with the endless_mode_world to update the number of extra lives the player has. The heart item is then displayed on the screen through the output system.

The player collects a heart item during gameplay

8

Scenario 2 The player gets an increase in achievement points after racing for a distance of 5000 m

In this scenario, the player obtains an increase in the number of achievement points after racing a distance of 5000 meters. The endless_mode_world in the controller is triggered at the start of the race and keeps track of the distance covered by the the kart as it progresses through the race through the use of a method in the kart.cpp script file. Once the kart covers a distance of 5000m, the function in the kart.cpp will notify the endless_mode_world. Endless_mode_world will then calls achievements_manager to update the player’s achievements.

6. EFFECTS OF THE ENHANCEMENT ON THE HIGH AND LOW LEVEL ARCHITECTURES 6.1. Impact on the Concrete Architecture

9

just as the banana peel and the gift boxes are obtained in the current version of the game. The new scripts also include the effect of the items. The heart item allows for the restoration of the player’s life in order to continue game play at whatever position on the track the game’s time limit runs out. The clock item increases the current time limit, allowing the player to race longer.

Output: states_screens The Output subsystem is responsible for generating output depending on the player’s input. With the enhancement, three new things need to be displayed on the screen: the icon for the heart item received, the player’s time countdown, and the challenge to be completed for the current track.

6.2. Impacted Directories and Files Within the Controller subsystem, files in the config, race and replay directories are used but not modified. Within the achievements directory of this subsystem, changes need to be made to update the achievements_manager.cpp script file whenever the player races for a distance of 5,000m. In the challenges directory of this subsystem, an endless_ mode_status.cpp script for generating and monitoring challenges during a race should also be created. Within the mode directory, a new script called endless_mode_world.cpp needs to be created to set up The incorporation of new features effects a couple of subsystems in our Concrete Architecture: the Controller, Game-Specific subsystem, Gameplay Foundations, and the Output System. Despite the number of affected components, our architecture remains the same. Recalling from the previous assignment, the following are the modules contained within each of the affected subsystems: Controller: race, mode, config, achievements, challenges, and replay ​ Game-Specific: items, karts, and tracks ​ Gameplay: audio, physics, graphics, and scriptengine ​ Output: states_screens ​

In our architecture, the Controller is responsible for distributing data to the appropriate subsystems depending on the user’s input. It also stores data on the game’s challenges and the player’s achievements. The Controller should handle the new challenges for each game world to be added within our endless game mode. At the start of each new track in the mode, the specific challenge associated with that track is retrieved from the challenges directory within the subsystem. Also, once the time limit is up, i.e. when the user fails a challenge, the game

10

should know that this signifies the end of the mode and therefore needs to display the player’s updated highscore onto the screen.The subsystem also needs to be updated to include a new script file under the modes directory located in it. This new file would handle the countdown and updating of the time limit, as well as the tracking of the distance covered by the user’s kart as the game progresses. The properties of the AI karts competing with the user within the mode subsystem also need to modified. These modifications include having the karts readily transported with the player’s kart once the user completes the current challenge and is transported into a new track.

The continuous change of game tracks as the user completes challenges would also affect the Gameplay Foundations subsystem.Within the audio directory, new script files that deal with the generation of new sounds for the new items need to be created. However, we also make use of the current sounds that indicate the start of a specific track whenever the user is to start a new challenge on a new track.

In order to implement the new game items i.e. the heart and clock items, new script files need to be added within the items directory in the Game-Specific subsystem. This is because we plan to implement these items separately and not incorporate them with the existing items obtained from the gift box item. In other words, these items would be collected by the user the properties for our mode’s game world. Some of these properties include: the creation of the time-limit countdown function for all the challenges in the game worlds within the mode and generation of the AI karts. The script should also make calls to the world_with_rank.cpp file to rank the player and the AI karts at the end of each race. The world_status.cpp script also needs to be modified in order to increase the time limit and kart lives whenever the clock and heart items are collected.

In the Game-specific subsystem, modifications are required within the items directory. A clock.cpp script file which handles the properties of the new clock item needs to be generated. The existing item.cpp and item_manager.cpp scripts need to be modified to include methods that aid in the development of the scenario when either a heart or clock item is collected. Within the karts directory, changes should be made to the karts.cpp script for the same scenario mentioned above. The directory also keeps track of the distance covered by the kart and calls the achievement_manager.cpp script (inside the Controller) to update the player’s achievements.

Within the Gameplay Foundations, a new sound for the new items is created to be played whenever a player’s kart collides with any of the new items under the audio subsystem. Also, within the graphics directory, the render.cpp script file needs to be modified in order to generate new graphics for the heart and clock items.

Finally, in the Output subsystem under the states_screens directory, the existing main_menu_screen.cpp script is modified to call the endless_game_screen.cpp script file, which deals with the generation of the main menu selection screen for our new game mode. After a certain track is chosen, the game objects of the endless game world need to be included and shown within the world on the player’s screen. This is to be done under the edit_track_screen.cpp script, so it also needs to be modified. The race_gui.cpp and race_gui_base.cpp script files also need to be modified to call the getIcon method that generates icons for the heart and clock items.

11

7. ARCHITECTURE STYLES AND DESIGN PATTERNS Our architecture style is not affected by the proposed enhancement feature. As mentioned earlier, only files and directories are affected in the subsystems as a result of the modification and addition of new elements in order to incorporate our new feature. Hence, our architecture maintains its Object-Oriented structure and contains the same design patterns discussed in the concrete architecture report.

8. TESTING/IMPACT ANALYSIS 8.1. Summary of the interactions of the proposed enhancement with other Features This new mode is to be added into the existing SuperTuxKart’s Single Player mode. This is to allow for a simplified integration of the feature into the existing source code. Once the user chooses this mode, options such as the level of difficulty, the number of AI karts, and the specific track to be played on are not made available. Since we will be having challenges for the user in the mode, we disabled the difficulty level option because this would be taken into account as the user progresses from one track to another in the mode. We also have the tracks option is disabled because all the tracks need to be used for the enhancement feature.

This new mode includes AI karts alongside the player’s kart, hence, current game items such as the banana peel, bowling ball etc., are made available in the mode. So the user can still use items such as the swatter to flatten his opponent’s (the AI) kart. The mode adopts the existing game tracks in its implementation of the various game worlds existing in the mode. The Endless mode also needs to update the player’s achievements during each gameplay. For example, when the player reaches the 5000 m in the mode, achievement point will be awarded when player finishes the track.

8.2. Testing Analysis For the testing analysis, the software developers will need to engage in test driven development practices during the implementation of the new mode. These practices involve turning the enhancement requirements into very specific test cases, and then improving the game’s software to pass the new tests. Once the implementation of the mode is complete, we would then test the endless mode by itself. Aspects of the feature in the mode such as the flow of the game, the loading of the map, the loading screen, and the interaction between player and the newly created items will be tested. After testing the mode by itself, the enhancement is then integrated into the SuperTuxKart game with its existing components and tested. This is to ensure none of the existing functionalities of the game is broken by the addition of the new feature. Once the integration is complete with no faults, we will perform beta testing on SuperTuxKart with the new feature included. This is a form of user acceptance testing method which involves releasing the new version of the game to groups of people, known as beta testers, so that further testing can ensure the product has few faults or bugs.

9. POTENTIAL RISKS DUE TO ENHANCEMENTS The implementation of the enhancement does not result in a lot of changes to our concrete architecture since the enhancements are simply added to the existing architecture. Since our architecture is already highly coupled, adding more features to the game would increase the

12

existing dependencies in the game. This could potentially increase the probability of the introducing new errors or bugs into the components of the existing subsystems if the feature is implemented incorrectly. There’s also the possibility that the new mode might not be adopted by the SuperTuxKart community. The implementation of the features might also not be realized due to lack of resources on the part of the SuperTuxKart team such as contributing developers.

10. DEVELOPMENT TEAM ISSUES The implementation of this enhancement feature would require experienced developers to combine several game world maps into one mode. Also, considering the modifications that need to be made to the several existing and new scripts (that need to be written), a lot of testing is required to ensure none of the existing functionalities are broken. We also need to test to ensure that the intended changes are actually realized. Hence, this would require effort from the current SuperTuxKart management team on acquiring more developers and testers to contribute towards the development of the new mode.

11. DISCUSSIONS OF THE LIMITATIONS OF REPORTED FINDINGS There were a few limitations to our reported findings. Similar to the previous assignment, there was a lack of documentation on the part of the game’s contributing developers. It was hard to understand the code itself because there was little or no comments on what the implemented code was trying to accomplish. Another limitation faced was the team’s limited knowledge on the implementation of the endless mode feature. Due to this, we had to research this topic on the internet by reading game discussion forums, informations provided by other games that have similar aspects of our feature, and informational sites on game mechanics. Still, these resources were limited and hard to obtain. Furthermore, it was hard to generate the NFRs associated with our enhancement without actually implementing the feature.

12. CONCURRENCY Concurrency is the composition of independently executing processes - dealing with (not doing) a lot of things at once. SuperTuxKart is a multithreaded system. It currently has its threading system implemented in the Library and Utils subsystems of its Concrete Architecture. The game turns off its support for multithreading in cases such as when the user’s platform doesn’t support atomic instructions or when the form of threads (either windows or posix threads) to be used isn’t chosen. For our implementation of the endless game mode, we would be using the current multithreaded system that exists in SuperTuxKart. This includes the use of the threading system to implement the loading of the game’s resources whenever a new world map is to be used. So basically our new feature follows the same principles being used in the current existing modes of the SuperTuxKart game. For example, when displaying the game results on the player’s screen at the end of the mode (through the output system), the graphics component is used to create images for that screen while the player’s achievements are concurrently accessed through the controller subsystem to display the player’s previous scores.

13. LESSONS LEARNED Having played the SuperTuxKart several times, the team could easily brainstorm ideas for enhancing the game. Once we chose the feature to be implemented, one of the issues we encountered was deciding on the alternatives for implementing it. The team initially assumed

13

that this meant exploring various methods for implementation at the lowest (source code) level. Because of this, we wasted a bit of time doing the wrong research. Ergo, we realized that we should have asked the professor for clarifications before we proceeding with the assignment. We also learned that we should have had the full storyline for our proposed feature written up before starting the assignment. We realized that having it helped clarify the aspects of the enhancement that could be materialized in different ways, with each implementation method having its pros and cons. Also, in order to fully implement new features to any software, the current state of the software needs to be in good shape. This involves having a well structured and well commented source code. From this assignment and the previous one, the team had a hands-on learning experience on the importance of the use good coding practices during the development of programs. We learnt that not following these practices could have a negative impact on other developers (including ourselves) that may read our code in the future.

14. CONCLUSION To conclude, for this report, we proposed the inclusion of an endless game mode as our enhancement feature. We proposed the preloading of the game worlds at the start of each challenge in the mode as the first method of implementation. Hence, the game would need to load for a few seconds before they start the next challenge. The second implementation method involves having all the game worlds set up at the beginning of the mode, so when a player finishes one challenge, they automatically get transported into the next new game world. We used the SAAM analysis to evaluate these two implementations in order to choose the better option. The impacted directories and subsystems in our concrete architecture were flagged and our plans for testing the impact of interactions between the proposed enhancement and other features were also presented. Finally, we identified the potential risks that need to be addressed due to the addition of our enhancement feature to the existing SuperTuxKart game.

15. REFERENCES

Erick, Schonfeld. (2010, August 25). SCVNGR’s Secret Game Mechanics Playdeck. Retrieved from https://techcrunch.com/2010/08/25/scvngr-game-mechanics ​

Joshua Lee, Nelson Yi, Andy Chu, Percy Teng, Hassan Haq, Simon Zhang. (2015, December 4). Architecture Enhancement Report. Retrieved from https://cisc326groupomg.files.wordpress.com/2015/11/cisc326-a3-doom3architectureenhance ment.pdf

Ian. Thomas. (2015, September 17). Hpl3:game:map. Retrieved from https://wiki.frictionalgames.com/hpl3/game/map#preloading

Couldn’t all games avoid post-start loading?. (2016, April 26). Retrieved from http://gamedev.stackexchange.com/questions/120577/couldnt-all-games-avoid-post-start-load ing

SuperTuxKart. (2016, December 01). Retrieved from https://en.wikipedia.org/wiki/SuperTuxKart#Tracks

14

Jason Gregory. (2009). Game Engine Architecture. Retrieved from http://www.latexstudio.net/wp-content/uploads/2014/12/Game_Engine_Architecture-en.pdf

Todd Merritt. (2013 January 07). Software Architecture Analysis Method. Retrieved from https://dzone.com/articles/software-architecture-analysis

Andrew Gerrand. (2013 January 16). The Go Blog: Concurrency is not parallelism. Retrieved from https://blog.golang.org/concurrency-is-not-parallelism ​

Andrew Stellman. (2010 February 17). Understanding nonfunctional requirements. Retrieved from http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html ​

Sanjeev Patwa, Anil Kumar Malviya. (2010 October). Testability Of Software Systems. Retrieved from http://www.arpapress.com/Volumes/Vol5Issue1/IJRRAS_5_1_10.pdf ​

Gunter Mussbacher. (2009). Non-Functional Requirements. Retrieved from http://www.site.uottawa.ca/~bochmann/SEG3101/Notes/SEG3101-ch3-4%20-%20Non-Func tional%20Requirements%20-%20Qualities.pdf

Hongyu Pei Breivold, Ivica Crnkovic. ( 2008 February). Using Software Evolvability Model for Evolvability Analysis. Retrieved from http://www.mrtc.mdh.se/publications/1405.pdf

15