PROG2215留学生代写、代写DirectX、C++程序语言调试、代做C++代写

日期：2019-02-12 11:34

Assignment 1 SET Trek

Software Requirement Specification

PROG2215 – Graphics, Animation and Sound

Version 1.1

Revision History

Contents

Contents2

1Overview Scope (Solo efforts only… no partners/groups)3

2Functional Requirements (6pts x 5req’s = 30pts)3

2.1View Background3

2.2Place Planets3

2.3Assemble and Place Starship4

2.4Move the Starship4

2.5Resize the Application Window4

3Non-Functional Requirements (Ungraded – See below)4

3.1Language4

3.2Graphics Engine4

3.3Buffering and performance4

4Deliverable Requirements5

4.1Coding Report Document (10pts, see below)5

4.2Marking Summary5

4.3Due Date5

1Overview Scope (Solo efforts only… no partners/groups)

This document specifies the functional, non-functional, and deliverable requirements for the SET Trek multimedia software development assignment. In effect, this assignment leads to the next two assignments in which you will be building up a Win32/C++/DirectX 11 application. Meeting the functional requirements helps you learn the deeper workings of Graphics, Animation and Sound.

The concept of this application centers around building a small game in a DirectX compatible framework. SET Trek will feature different play modes, but otherwise be somewhat simple as a game. Instead, the real learning behind this and the follow up assignments is the need to create a well-designed, extensible game engine framework that will allow you to complete several GAS-goals. Compositing images, procedurally drawing objects, animation sequences and sound effects are all in-scope activities as we put this game together.

For our first assignment, our goal is to assemble a good tool kit of functionality that will allow us to the draw main game board, and place and move several objects on the screen.

2Functional Requirements (6pts x 5req’s = 30pts)

The following functional requirements must be implemented to complete the assignment.

2.1View Background

2.1.1 The user must be able to see the bitmap Background.bmp resized to fit the viewspace. A later requirement (See below) asks you to ensure that the screen can be resized seamlessly. Consider starting with a 1024x768 window size.

2.1.2 The background scene MUST be managed and incorporated into game as though it had a ‘grid’ of 10 spaces wide by 10 spaces tall. This will give us a playing surface of 100 squares – but these squares should never be rendered to the screen! They are just used to control movement and positioning of assets (see below).

2.2Place Planets

2.2.1 In our game, our starship will travel around the map, exploring strange new worlds, and encountering challenging obstacles. To start with, we are provided with 3 assets that represent these worlds to be explored. They feature a ‘green screen’ background that must be chroma key adjusted to fit nicely into our scene.

2.2.2 Our space grid has 100 squares in it. You should write code to ‘populate’ our star sector with these planet assets according to these rules:

Each square has a 1 in 20 chance of having a planet asset in it.

If a square gets an asset, which asset is placed is determined randomly (they all have equal ‘weighting’ for this purpose).

2.3Assemble and Place Starship

The starship in our game, USS Conestoga, is provided to you as two different files - ShipBase and ShipDetail. You must composite the final ship asset in your application, and place it on the sector grid (e.g. in a starting point in the upper left). An example of what the ship should look like is below:

2.4Move the Starship

The USS Conestoga should move across the sector grid, from square to square.

The ship should start at the left/middle of the screen and proceed from center-point to center-point of each grid square, heading to the right of the screen.

The ship should pause for 500ms, before proceeding to the next point (e.g. it should take about 5s to head across the screen).

When the ship reaches the border of the right side of the screen, it should ‘warp’ to a new sector. This means that you should initialize a new ‘sector’ with randomly placed planets just as with the initial scene, and place the ship back at the left/middle starting point, to continue its left to right journey.

2.5Resize the Application Window

The user must be able to resize the application window. The multimedia application must stretch the three background images to accommodate the new window size.

3Non-Functional Requirements (Ungraded – See below)

The following non-functional requirements must be implemented to complete the assignment.

3.1Language

SET Trek must be coded using C++ as a Win32 GUI application. Please do not use the UWP framework or the UWP DX11 template packages. This will cause more grief than it is worth.

3.2Graphics Engine

SET Trek must use Direct X 11 as its rendering engine. If you really want a challenge and would like to consider a different graphics engine (E.g. OpenGL, Vulkan, etc.) talk to me before starting A1… I’ll consider it, but I’d want you to commit to using that engine throughout A1/2/3 and final project.

3.3Buffering and performance

SET Trek must use double buffering to combat flickering, and should otherwise perform well as we head into demos of functionality later in the semester.

3.4Do NOT zip your document!

Your only deliverable for A1 is a MS Word or PDF document as documented here. There is no need to zip your submission for this assignment, and doing so will interfere with TurnItIn.

Grading Note: C Cap - The non-functional requirements are ungraded, but nevertheless important. The noted absence of any one of these non-functional requirements will cap your mark at a grade of 60% maximum.

4Deliverable Requirements

4.1Coding Report Document (10pts, see below)

A document providing a summary of your implementation effort is required. It must include:

A paragraph for each functional requirement in section 2 identifying your effort to implement each requirement. This should be a description suitable for mildly technical audiences. Consider making reference to your source code appendices (see below).

Supporting evidence of your effort to implement each functional requirement. To meet this goal, please provide 1-2 screenshots from the finished product outlining where the requirements were met.

Source code appendices – Provide one or more appendices to the document that includes your SET commented code. The code provided should cover the functional requirements outlined in Section 2 of this document only. DO NOT provide code from generic, Visual Studio files, headers and the like. The need is to see how you met the functional requirements with your code, not how well you can manage a VS project

Coding Report Document Marking Scheme

5pts – Supporting screen shots (hey, this is a visual app after all!) provided sufficiently show/support student’s efforts to meet functional req’s.

5pts – Source Code Appendices are professionally presented and easy to review.

C Cap – Failure to sufficiently follow the SET standards for coding, reports and submissions will result in a maximum possible grade of 60%.

4.2Marking Summary

Functional Requirements Met (and documented in report) – 30pts

Coding Report Document (Screen Shots, and Readable Code) – 10pts

BEWARE – Grade Caps are in effect for this assignment.

Assignment is marked out of 40pts.

4.3Due Date

Please consult the eConestoga DropBox associated with this assignment for due date/time.