Sprint 0: Getting Started

First (Early Bonus) Deadline: Sun Jan 25 at 11:59pm

Second Deadline: Sun Feb 1 at 11:59pm

Objective

This is an individual assignment to get everyone comfortable using Visual Studio and/or VSCode, .NET, C#, and MonoGame, as well as designing and implementing objects and interfaces. Advanced students may also make use of the Command design pattern. The core requirements of this Sprint are content loading, sprite drawing, and input handling, in an event loop.

This assignment has two due dates. You are expected to turn in whatever you have completed by the first deadline, but will be allowed to turn in your work again without a late penalty as long as the resubmission is turned in by the second deadline. If you completly finish the assignment by the first deadline you will earn a 5% extra credit bonus, possibly going over 100% for the assignment.

Sprint Outline

Step 1: Software Setup

The short version of this step is to follow MonoGame’s Getting Started Page and ensure you can create, build, and run an “empty” MonoGame project using either Visual Studio or Visual Studio Code. When selecting the MonoGame project template to use, make sure you select the “MonoGame Cross-Platform Desktop Application” template. If successful, you should have an application that shows a blue window when it runs. You can proceed to step 2 once you have this accomplished. The rest of this section provides more detailed information on environment setup and troubleshooting.

Miscellaneous Troubleshooting - read these before you ask for help on the install!

• The most common of unexpected problems encountered here stem from Visual Studio behaving poorly when dealing with white space in file names when building MonoGame projects, the first reported error is usually: “…Xna namespace cannot be found…” when this occurs. Make sure the Visual Studio project you create does not contain whitespace characters to avoid this problem. This may no longer be an issue with recent Visual Studio versions, but it cannot be ruled out. In short, when you name your project do not include whitespace, and place your project in a path without spaces.

• To use the MGCB Editor tool for building of content projects, you may need to install some Visual C++ Redistributables. If your development machine is one you also use for gaming you may already have some of these installed without realizing it. Based on setup in previous semesters, we recommend downloading and running the 2012, 2013, and 2019 packages. The most common error message that should cue you that you need to do these steps is “Unable to build content - Cannot load FreeImage”; more info on this error can be found here and here.

• For students working out of Caldwell Labs, the project templates may not be showing up (we had this issue with MonoGame 3.7.1 but it might not reproduce with 3.8). If that is the case, either create the project using the CLI (see here) or see below for a project template.

• Also for students working out of Caldwell Labs, note that Visual Studio is used, not Visual Studio Blend.

• The MonoGame community isn’t incredibly large, but you might find additional install and setup help on their forums.

Step 2: Working with MonoGame - Basic Tutorial

For understanding the basics of working with MonoGame, there is an excellent Building 2D Games tutorial maintained by the MonoGame team. Sections 1 through 11 of this tutorial cover everything you need to know about MonoGame for this assignment. Read these sections and make sure you understand the core concepts and the MonoGame API, specifically around Game1, ContentManager, SpriteBatch and the Keyboard/Mouse classes.

Step 3: Programming Assignment

Your task is to implement a very simple interactive program. At run-time, the user should be able to select between display of a motionless and non-animated sprite (ex: luigi standing still), a motionless and animated sprite (ex: luigi running in place), a moving and non-animated sprite (ex: dead luigi floating up and down), and a moving and animated sprite (ex: luigi running right and left). Note: only one of these sprites should be visible at a time. The user should also be able to quit the program with a key press (the 0 key). Additionally, you should use a text sprite to display your name and the source of your art assets. One significant purpose of this assignment is to gain experience using interfaces (designing them, implementing them, and using them like objects). Carefully read and follow these requirements:

• Create some interfaces:

  • Create an interface for any and all controllers, IController.

  • Create an interface for any and all sprites, ISprite.

  • Optionally, using the Command Design Pattern, create an ICommand interface.

• Then make some concrete classes that implement the interfaces:

  • Implement a concrete class for a Keyboard controller.

  • Implement a concrete class for a Mouse controller.

  • Implement a concrete class for the non-moving, non-animated sprite.

  • Implement a concrete class for the non-moving, animated sprite.

  • Implement a concrete class for the moving, non-animated sprite.

  • Implement a concrete class for the moving, animated sprite.

  • Implement a concrete class for a text sprite.

  • If you made an ICommand interface, implement a concrete class for each Command the user can trigger: one for each different sprite that can be set and one to quit the game.

• For keyboard input:

  • Have a key (0) to quit.

  • Have a key (1) that has the program display a sprite with only one frame of animation and a fixed position. This should be the initial state of the program.

  • Have a key (2) that has the program display an animated sprite, but with a fixed position.

  • Have a key (3) that has the program display a sprite with only one frame of animation, but moves the sprite up and down on screen.

  • Have a key (4) that has the program display an animated sprite, moving to the left and right on screen.

  • Note on sprite motion: Instead of the moving sprites periodically changing direction, you may opt to have the sprite move in only one direction and have its position wrap around to the opposite edge once it reaches the end of the screen. The exact motion required for sprite movement is up to you, but movement must be controlled by the timing information passed to your game’s Update and Draw methods through GameTime.

• For mouse input:

  • Left mouse click, when the mouse cursor is in the top left quarter of the window, should display a sprite with only one frame of animation and a fixed position (i.e. the same as pressing 1).

  • Left mouse click, when the mouse cursor is in the top right quarter of the window, should display an animated sprite, but with a fixed position (i.e. key 2).

  • Left mouse click, when the mouse cursor is in the bottom left quarter of the window, should display a sprite with only one frame of animation, but moves the sprite up and down on screen (i.e. key 3).

  • Left mouse click, when the mouse cursor is in the bottom right quarter of the window, should display an animated sprite, moving to the left and right on screen (i.e. key 4).

  • A visual example of these four portions, labeled as Quad#, is shown below.

  • Right-mouse click anywhere in the window should quit.

• Finally, in the main game class, use the interfaces to animate/update the current sprite. If you are not using commands you will also need logic to switch between sprites and quit in the main game class (or in the concrete controllers). IMPORTANT: Your main game class should only refer to the sprites and controllers through the ISprite and IController interfaces, respectively, except for the initial creation of the objects.

The above is an illustration of what is meant by quad. You don’t have to draw the lines or Quad# text in the actual program. However, having a mode in your program to display the quads as perhaps colored rectangles can aid debugging.

Design Suggestions:

• Include a Dictionary in the Keyboard controller class that maps keys (buttons) to concrete instances of ICommand (based on the input keys/buttons listed above).

• In the Update method of the controllers, for each input key/button that is pressed, create and execute its corresponding Command.

• Alternatively, for the controller code if you are not using Commands, consider splitting up input logic into multiple classes (in this case QuittingController and SpriteSettingController).

• In the Game (main) class, only use the interfaces in the Update and Draw methods.

• Carefully consider which methods to add to your interfaces, and which arguments are passed to them. What is needed each time your sprite is drawn versus what is only needed at sprite creation time?

• Use GameTime to control your animation and movement. Do not assume your game’s Update and Draw methods will always be called at the same frequency.

The following are the recommended class layouts:

        classDiagram
direction BT
KeyboardController ..|> IController
MouseController ..|> IController

class IController{
    <<interface>>
    +void YourMethodsHere()
}
class KeyboardController {
    +void YourMethodsHere()
}
class MouseController {
    +void YourMethodsHere()
}
    

        classDiagram
direction BT
NMNASprite ..|> ISprite
NMASprite ..|> ISprite
MNASprite ..|> ISprite
MASprite ..|> ISprite

class ISprite {
    <<interface>>
    +void YourMethodsHere()
}
class NMNASprite {
    +void YourMethodsHere()
}
class NMASprite {
    +void YourMethodsHere()
}
class MNASprite {
    +void YourMethodsHere()
}
class MASprite {
    +void YourMethodsHere()
}
    

Sprite Resources:

• You can find spritesheets for Super Mario Bros. and The Legend of Zelda in links on the Resources page.

• You are free to use other spritesheets, but do not use a spritesheet that is already is the format of a texture atlas - the learning objective here is in figuring out how to work with any spritesheet, not just ‘convenient’ ones. You may use a spritesheet formatted as a texture atlas if you edit the image to have this format yourself - include a before and after image in your submission if you do this.

Project Template:

If you are having difficulty installing the MonoGame templates and creating an initial project, you can use the CSE3902 Group Project Template. But please try to create your own project first as it is a valuable learning experience!

Work to turn in:

• Do a Build->Clean in Visual Studio [Code], and then without rebuilding, zip/compress the directory containing your solution.

• It is recommended that you unzip the file elsewhere, then build and run it to see if it is working correctly. It is your responsibility to ensure the project builds! Test it before submitting!

• Turn in zipped file on Carmen under the assignment page named “Sprint 0”.

• The dropbox is set up to accept multiple submissions, only the latest submission before the deadline will be graded.

• Start early and do not wait until the last minute to submit work! Seriously, this is the number one issue with students not completing the assignment!

• When adding content to your MonoGame Content Project, make sure you select the option to copy the file instead of link it. Selecting copy will ensure it gets copied to your project directory. If you select link, it will only add the path to the file to your project. Unless the file is already in your project directory, the link will point to a file that does not exist on any other computer, including the grader’s!

Grading Criteria

If you cannot complete enough functionality to reach 60% on this assignment, you will have a difficult time being able to contribute on the team project. You should be able to evaluate your work using the rubric provided below and reach out for help before the assignment’s deadline if it looks like you will come up short. If you are not able to complete the assignment by the date of the resubmission option it is recommended that you consider dropping the course. Understanding the basics of sprite animation and user input is a fundamental building block of this course. If you have any questions, ASK!

Your grade on this assignment will be based on correctness and adherence to the stated requirements, but you will also receive feedback on how you could improve upon the quality of your code.

Criterion	Points
Support for keyboard input	20%
Support for mouse input	20%
Support for the four sprites types	10% each; 40% total
Support for text drawing for the application’s credits	20%

For each criterion, both functional correctness and adherence to stated requirements will be assessed. For example, proper use of interfaces and concrete implementations are considered part of the criteria, not code quality.

Code Quality (is the code simple, readable, maintainable, and reusable):

• Readability: Follow C# capitalization conventions, as shown here. To summarize:

  • Most names will be in PascalCase where the first letter is capitalized along with the start of each word concatenated to it.

  • The exceptions where camelCase (first letter lowercase then capitalize the start of concatenated words) is used for parameterNames and classMembers

  • You do not need to use ‘_’ for private members.

• Readability: Use meaningful names for interfaces, classes, and variables so that you do not need or have any comments explaining them

• Maintainability: The interfaces should be complete, but as simple as possible

• Maintainability: Using interfaces in the Game class instead of the concrete types

• Simplicity and Reusability: Following the design suggestions in the list of objects and interfaces above (if you want to come up with your own design talk to the instructor first)