Essay:

Essay details:

  • Subject area(s): Engineering
  • Price: Free download
  • Published on: 7th September 2019
  • File format: Text
  • Number of pages: 2

Text preview of this essay:

This page is a preview - download the full version of this essay above.

Introduction

Multiplayer Online Games make it possible for people in different places throughout the world to play together, having a shared experience in entertainment. Millions of people on multiple platforms are connecting to each other every day, to enjoy the challenge and adventure that these games have to offer (Valve, 2015).

A common way for users in online games to connect to each other, is by first connecting to a server, hosted online by the game creators or a third party. The advantage of this client-server model, is that the hosting service can provide a dedicated server to run the game, providing maximum performance to the clients.

Another common method for connecting clients together, is through a peer-to-peer network. In this topology, there is no central server to provide game updates to the client. Instead, clients connect to each other. A disadvantage to this network, is that the performance of the game will rely on the performance of the individual clients. A network containing clients with poor internet or hardware performance will suffer, affecting the other clients in the game. However, the lack of a dedicated server is the greatest advantage of a peer-to-peer network, as it does not rely on a central point of weakness, upon which the whole network of clients depends.

The aim of this project, is to investigate how current networking techniques in Multiplayer Online Games affect their reliability and performance. This evidence will then be used in the creation of a game artefact, demonstrating a Multiplayer Online Game that primarily uses a client-server arrangement, with a backup peer-to-peer connection, in the event that the server becomes unavailable, so that the game can continue uninterrupted.

Chapter 1

1. Methodology

To ensure a structured and formal approach to the project, a methodology based on an established working process must be decided upon, before research is conducted.

1.1 What is a Methodology?

A methodology is an organised approach to a project. Methodologies are frequently used in small and large development teams, but can also be utilised in an individual project. They typically following a linear and structured approach to carrying out work. This is preferable to an unorganized approach because it ensures that a consistent volume of work is completed, and that the progress of the project is visible to members of the team, or the team leader. There is usually some indication of when various tasks, as well as the whole project, will reach completion. This is important in business, because it allows the project manager to devise and distribute an adequate amount of work to each member of the team, as well as give a realistic delivery date to the client, of when the project will be finished.

For the Peer-to-Peer Redundancy in Multiplayer Online Games project, one of these methodologies will be used. To decide upon an appropriate methodology that fits this scenario, three popular processes will be examined, highlighting their advantages and disadvantages. These methodologies are: Waterfall, Spiral, and Scrum.

1.2 Waterfall Development Model

The waterfall model uses an iterative approach to development, where each task is performed sequentially, from start to finish. The idea of a Waterfall Methodology was first discussed by Winston W. Royce at the 9th International Conference on Software Engineering (Royce 1987).

Figure 1 Waterfall Diagram

Figure 1 shows an initial idea of the Waterfall model, where development can deviate from a straight path. Each step in the development process follows the previous one. Royce stresses the importance of good planning and documentation in the initial stages of development, so that the Waterfall model can be followed throughout. The only deviation that should occur from this linear path, is with the preceding and proceeding step in the sequence. For example, In the Software Requirements stage shown in Figure 2, there may be overlapping development time spent on the previous step, System Requirements, and with the following step, Analysis.

However, a criticism of this method is that overlapping steps will add to development time, and therefore increase the cost of the project. For example, in the testing stage, it may be discovered that the initial software requirements need additions. The process shown in Figure 1 will not allow development to move backwards multiple steps, as this deviates from the Waterfall model.

The proposed solution to this, is illustrated in Figure 2. A notable addition to the model, is at the Preliminary Program Design stage. At this point, the developer can begin an initial design of the final product, enabling them to see any possible complications or alterations that would need to be made in the initial stages, to prevent regression from future stages.

Another addition in Figure 2, is comprehensive documentation at every stage of development. By compiling documentation at each stage of development, rather than at the end of development, each step in the process has a basis to work from. It also provides an interface between peripheral stages. For example, the Testing Stage proceeds the coding phase, taking data from the preliminary design and documenting it in the Test Plan Specification. The Test Plan Specification is first created during the Program Design Stage, when there is a final design for the project. Connecting this to the Testing Stage allows additions to the Test Plan after new information has been made clear after the Coding Stage has completed.

Figure 2 Complete Waterfall Design

In following this linear development path, Royce aims to remove the need to jump between steps in development, which can substantially increase the overall development time. Instead, each step should be firmly established before moving on to the next.

1.3 Spiral Process Model  

The Spiral Process is an approach to development that uses a cyclical model, as shown in Figure 3. The Spiral Process was first publicised by Barry W. Boehm in his Article for the IEEE Computer Journal, titled A Spiral Model of Software Development and Enhancement (Boehm 1988).

Figure 3 shows a graph illustrating the Spiral Model. The spiral begins closest to x=0, y=0 on the graph, and extends outwards in a clockwise direction, with each subsequent spiral becoming larger than the previous. Each of the four quadrants of the graph represents a different step in development. The top-left quadrant contains the steps involved at the start of a cycle, where the objectives of the project are identified. The top-right quadrant is the next step, where risks involved with the project are identified and resolved. The third step is the bottom-right quadrant, where the findings from the previous step, such as risk resolutions, are implemented. In the initial cycles of the project, this may involve creating software requirements. In later stages, it will be producing a final product design, coding, and testing, as shown in Figure 3. The final step is the bottom-left quadrant, where a plan is made for the next cycle.

Figure 3 Spiral Process Model

The spiral initially begins small, close to the centre of the graph, and becomes larger after each cycle. This represents the scale, cost and time-commitment that increases, for each of the four stages.

The Spiral Process Model is categorised as a risk-driven approach to development. This means that risks involved with the project are identified at each stage in the project, and a plan is created on how the risks can be resolved. An example of risk evaluation and resolution is given in Boehm’s article (Boehm 1988). In an attempt to improve software productivity, part of the proposed solution involved issuing new workstations to employees. This solution posed a risk: the additional cost of purchasing and maintaining new workstations. Therefore, as part of the risk-driven development plan, a resolution had to be identified, that would address this risk. In Boehm’s example, workstation price projections would be created, to identify if the risks are significant or not. Based on the results of the projections, it was decided that the project would experiment with using dumb terminals and smart workstations, as well as deferring the operating system and tools that would be used on the new systems. A plan was then created for the next cycle of development, based on the findings from the previous cycle.

While the Spiral model can be applied to projects that are not driven by significant risk, Boehm expresses that risk-driven scenarios are where it is most advantageous. In projects where risks are not considerable, the Spiral model performs in practice similarly to the Waterfall model.

A criticism of the Spiral model is its ambiguity on stages of the cycle, length of stages and number of cycles. An advantage of this is that the model can be applied and adapted to different projects, in a bespoke manner. However, this can lead to an unspecific template. Projects may deviate too far from the original model, shown in Figure 3, by adding too many additional cycles, that add to development time, with no clear end-point.

Another criticism of the Spiral Model design, is it predisposes to the user that the stages of development must follow an exponential increase in time or cost at each subsequent cycle. This however may not be the case for all projects. For example, in low-risk projects, the size of the spiral in the top-right quadrant will be small, Risks may be unlikely to increase in the following cycles if there is a negligible risk, such as cost or time-constraints, in the initial stages of the project.

1.4 Scrum Methodology

The Scrum Methodology originated in 1987 by Ikujiro Nonaka and Hirotaka Takeuchi (Schwaber & Beedle 2001). The name was inspired by the Rugby ‘Scrum’ tactic, due to the similarities with the Scrum working process. More recently, Ken Schwaber, a management consultant, has been a driving force at the forefront of Scrum Development, publishing papers (Schwaber, 1995)  and books (Schwaber & Beedle 2001) on the techniques involved in implementing a Scrum workflow.  

Scrum differs from other methods such as Waterfall or Spiral, in that it places emphasis on the people that make up the development team, and what their role is in the project is, from an organisational point of view. Scrum encourages high cohesion between team members, by allowing for regular feedback, review and discussion. This ensures that team members are clear on their objectives, and refocused on their tasks. Similar to the Spiral Methodology, Scrum uses a cyclical approach, which iterates over the same stages multiple times in the lifecycle of the project. Scrum takes this a step further, as each development cycle intends to finish with the project at a stable point. In the case of a software product, this could mean the project is building or running without errors.

There are several different entities important to implementing a Scrum workflow, rather than a more linear A-to-B approach, as is more typical with the methodologies described previously. For the sake of clarity, these are described under individual headings below.

Figure 4 Scrum Sprint Diagram

1.4.1 Scrum Master

The Scrum Master takes on a managerial role, overseeing the project's different members. It is the Scrum Master's responsibility to act as a middle-man between the scrum teams, management, and the customer. Therefore, to be effective in the role, the Scrum master must understand the customer's wishes, relay important project information, such as progress and costs, to management, and to assign tasks to the team, in order to maintain a constant velocity of development. The Scrum Master ensures that the team can focus entirely on their current sprint of development, resolving external problems and making decisions on behalf of the customer and management rapidly (Schwaber & Beedle 2001, p. 31-32).

1.4.2 Product Backlog

The product backlog is a list of requirements, bugs, improvements and ideas related to the final product. Initially the backlog may contain steps for the first 30-day sprint, but can evolve to contain the outlook for the project over multiple years. Tasks on the backlog are organised in order of priority. For example, urgent bug fixes will have a higher priority than new product features.

The product backlog is maintained by the Product Owner. The product owner is a single individual who is responsible for maintaining the product backlog. Items are added, removed, modified and moved to a sprint by the product owner, with the advisement of the Scrum Master and the Scrum Teams. The required time and resources needed to complete a task on the product backlog is described as the ‘effort’ needed. This is determined by the product owner, in cooperation with the scrum teams. Initially this predicted effort may be inaccurate, especially on the initial sprints undertaken by the team. This is an acceptable hindrance, as without previous experience with the project, it is impossible to give an accurate estimation of how long tasks will take. After completing several tasks and sprints, the product owner can re-evaluate the estimated effort for each task, and make adjustments accordingly. This helps to produce an accurate estimate for the duration of the project and for various project milestones (Schwaber & Beedle 2001, p. 33-35).

1.4.3 Scrum Team

The Scrum Team is made up of individuals who work together to achieve their set of tasks chosen from the product backlog by the Product Owner. The team is made up of a variety of individuals who use their specific strengths to complete the team's tasks by the end of the sprint. In Scrum, it is encouraged to allow the team to self-organise, settling differences and resolving problems internally, with the least amount of interference from the Scrum Master and no interference from external sources like customers and management. The recommended team size is 7, as this is small enough to allow full interaction between team members while not being too large that members of the team have no want or need to interact between each other. This small size also allows for easy communication between members of the team and the Scrum Master in the daily meetings. Large teams of people can be subdivided into small scrum teams with their own Scrum Master, who then meet together with an overall Scrum Master, who coordinates the individual teams.

Although team members may be chosen for their particular area of expertise, there are no roles or titles assumed by members of the team. This encourages members to contribute to the objectives in any way they can, seeking advice from peers and ultimately learning new skills. This is preferable to team members fulfilling what they assume to be their work, based on their expertise, and then waiting around with no work to do, while other members of the team complete theirs (Schwaber & Beedle 2001, p. 35-39).

1.4.4 Daily Meetings

The daily Scrum is a core part of the methodology, where the Scrum Master and team members meet, for a brief period. This is usually 15 minutes. In the meeting, each team member informs the Scrum Master and colleagues on their progress. This will include:

● What was done since the last scrum?

● What will be done before the next scrum?

● Are there any blocking points hindering progress to achieve the goals.

Outsiders such as managers or users may be invited to observe the Scrum, but are not allowed to interfere. This is an opportunity to get regular feedback for the Scrum Master and team members on their work, helping to project an outlook for the project. It is the Scrum Master's responsibility to listen to the concerns and problems of team members, and attempt to resolve these blocking points as soon as possible, so that progress can resume (Schwaber & Beedle 2001, p. 40-46).

1.5 Evaluation of Methodologies

Altogether, three methodologies have been examined: Waterfall, Spiral and Scrum. These methodologies each have their own strengths and weaknesses, making them suitable for different types of situations.

The Waterfall methodology presented a linear approach to a project, with a clear trajectory from start to finish. The simplified version of this is shown in figure 1. A more comprehensive version of this is shown in figure 2, with more detailed intermediate steps where prototyping and analysis can be performed, to aid the main waterfall of development. A criticism of the Waterfall approach is that, despite the more detailed prototyping stages, development has to follow a linear approach. This can become problematic when new discoveries and realisations are made later in development, that require modification to earlier stages, for example, if customer requirements change after seeing the product in the later stages, changes must be made to the software requirements. Because of the linear approach that the Waterfall Model takes, this would not be possible.

The Spiral Process Model demonstrates an iterative approach to development, shown in figure 3. Using this risk-driven process, development begins as a small examination of the risks involved in the project, and slowly increases in cost and commitment as the project grows, reaching its end-point. An advantage of this technique over the Waterfall model is its iterative, rather than linear, approach to development. This allows requirements and features to be changed throughout development, as is common in a risk-driven scenario. A criticism of this technique however, is that in a low-risk environment, where there is less need for risk-based changes, it can quickly devolve into a Waterfall-like approach. The shape of the spiral diagram, as well as Boehm’s explanation, also suggests the project should increase exponentially in time and cost. In his article (Boehm 1988) he admits that ‘Some artistic licence has been taken with the increasing cumulative cost dimensions to enhance legibility’, which could be negatively deterministic in deciding a project's timeframe and budget. This raises the question of how suitable this shape is in explaining all types of projects. For example, an in-house software project with minimal risks may increase in cost up to the point when full development begins by the team members, and then remain constant. Using the Spiral model, it could be assumed that costs should still increase exponentially, leading to over-budgeting for the project.

The Scrum methodology uses an incremental and iterative approach, where team members work on a set of tasks for a short duration, such as 30 days, and finish the Sprint with an early working form of the project. This model focuses more on team arrangement than Waterfall or Spiral, attempting to subdivide colleagues into small cohesive groups, to increase productivity and reduce external distractions or influence. A disadvantage of Scrum when compared to the Waterfall model, may be that it doesn’t explicitly explain the use of documentation as an interface between different stages of the project, instead focusing on meetings and discussions to decide upon requirement changes and considerations. An advantage of the Scrum Methodology, is the Sprint-cycle for development. In the Waterfall and Spiral processes, there is a start and end-point to the project. This approach can invite failure to a volatile project, as delays and stopping points in the project leave it un-finished, with no usable progress to be shown. Scrum however, attempts to develop a working prototype after 1 month: the first Sprint. Each subsequent sprint also aims to finish with a working version of the project, in its current form. This is has significant benefits, as the team has a demonstrable version of the project to show to customers, peers and management early-on, helping to encourage interest in the project. In the event of a pause or stop in the project, it leaves a product with partial functionality that is easier to be picked up by the development team in the future.

For the purposes of this project, the most suitable of these methodologies would be an adaptation of the Scrum Methodology. This is because the Scrum Methodology suites an evolving project with development cycles. As this project involves investigation and prototyping of software, using development sprints allows adaptation of requirements throughout development, as the project moves towards a functional solution. The use of a Product Backlog also allows for clear organisation of project tasks that can be modified to suit the changing requirements. With the use of Sprint-cycles of development, stopping points can be established throughout the project, where a working form of the project is produced. This is a benefit to the project, as a demonstrable version can be shown to interested parties.

...(download the rest of the essay above)

About this essay:

This essay was submitted to us by a student in order to help you with your studies.

If you use part of this page in your own work, you need to provide a citation, as follows:

Essay Sauce, . Available from:< https://www.essaysauce.com/essays/engineering/2016-2-1-1454342763.php > [Accessed 15.10.19].