User Tools

Site Tools


haas:spring2024:comporg:projects:mpg0

Corning Community College

CSCS2650 Computer Organization

PROJECT: Make Playable Game (MPG0)

OBJECTIVE

Read through pertinent technical specifications and guides for Vircon32, and implement a functioning snake game that can be played in the emulator.

EDIT

You will want to go here to edit and fill in the various sections of the document:

MPG0

References

The Vircon32: C API reference page may be helpful - http://www.vircon32.com/api.html

Game Mechanics

Game loop

For this project, you will be making a Snake game.

The game loop for Snake is simple: you will control a snake around the screen to eat pieces of food. Once a piece of food has been eaten, your score will increase, and the snake will get longer.

The game ends when the head of the snake runs into either a wall, or another part of its body.

Sprites
  • There should be a sprite for at least a background, the snake's body and the food if you want to make your snake just a normal looking square.
  • Some good free sprite software's would be GIMP , Microsoft Paint, or maybe even Photoshop on a school computer.
  • A link to GIMP download: https://www.gimp.org/downloads/
  • You could also have a death screen for when your snake dies.

Another good option for designing your snake is downloading a photo off the internet(probably an animated/cartoon one). I personally got the following photo “https://pngtree.com/freepng/cartoon-snake_6160039.html” and cropped just the head. I then designed the body off of the colors from the head.

Gamepad input

There is obviously your arrow key inputs but there are other buttons available as well. At least for gamepad(0) we have button_?_ = ? for the average keyboard:

  • A = X
  • B = Z
  • X = S
  • Y = A
  • L = W
  • R = W
  • Start = Enter Key
Using controller

For those out there who want the whole experience of gaming, therein lies the ability to plug in a real video game controller, if your system allows (some laptops will at least). To that end, the controls are pretty straight-forward. Either console controller will rely upon the D-pad for movement, and the buttons should map to the controllers as well. For example, 'X' on a playstation controller should correspond to the “a_buttonpress” vircon command. The same should apply to 'A' on an Xbox controller.

Arrow Key Setup

If you are just trying to make the input based off of your arrow keys, you can simply copy the same setup:

// Buttons to move up, down, left, and right
bool mRight = (gamepad_right() == 1);
bool mLeft = (gamepad_left() == 1);
bool mUp = (gamepad_up() == 1);
bool mDown = (gamepad_down() == 1);

NOTE: You'll want to do this in your game loop (the while loop) and make sure it is inside of main but outside of you game loop have the following:

// Selects keyboard as gamepad to use for input
select_gamepad(0);

When making you gamepad you'll make gamepad_direction values, WalkX and WalkY for example purposes.

  • If WalkX < 0 then that mean you're going left.
  • If WalkX > 0 then that mean you're going right.
  • If WalkY < 0 then that mean you're going up.
  • If WalkY > 0 then that mean you're going down.

With those you would probably make it so that when WalkX < 0 var = 1. And then do:

if( var == 1 ) {
  Snake[0].X -= PlayerSpeed;
}

to make your snake constantly move after pressing an arrow key.

Alternate way of making endless mvoement

you could also set up a switch and do something like the following:

case RIGHT:
     SHead.X += speed;
     Break;

Things to note before doing the above. Youll need to create global variables LEFT, RIGHT, UP, and DOWN. In the given example there is a struct named Shead (Stands for snake head). You will also need the following:

 // The direction is updated based on given input
if (mRight && SHead.Direction != LEFT)
{
    SHead.Direction = RIGHT;
}

The “&& SHead.Direction != LEFT” prevents the snake from going back on its self.

Bounds checking

The screen on vircon32 is 640 by 360, however, you do not have to type these out every time you make a game in vircon32 as they are stored in the screen_width and screen_height variables respectively. One way of bounds checking is to see where you are about to spawn the snake's head, if it is within the screen window then it is fine. However, if it is outside that window then game over.

Handling motion

To handle motion you could do:

int SnakeX;
 
 
if( Right)
{
 
  SnakeX = SnakeX + 20;
 
 
}
Score Display

you need the string.h header file

make a variable for the score

make an array to display the score

use the itoa function to convert the data, then use the print_at function to print it on the screen.

you can use the Vircon32 tutorials as a guide to help build and display the strings: https://github.com/vircon32/ConsoleSoftware/tree/main/Tutorials/WritingText

 

SUBMISSION

To be successful in this project, the following criteria (or their equivalent) must be met:

  • Project must be submit on time, by the deadline.
    • Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
  • Executed programs must display in a manner similar to provided output
    • output formatted, where applicable, must match that of project requirements
  • Processing must be correct based on input given and output requested
  • Output, if applicable, must be correct based on values input
  • Code must be nicely and consistently indented
  • Code must be consistently written, to strive for readability from having a consistent style throughout
  • Code must be commented
    • Any “to be implemented” comments MUST be removed
      • these “to be implemented” comments, if still present at evaluation time, will result in points being deducted.
      • Sufficient comments explaining the point of provided logic MUST be present
  • No global variables (without instructor approval), no goto statements, no calling of main()!
  • Track/version the source code in your lab46 semester repository
  • Submit a copy of your source code to me using the submit tool by the deadline.

Submit Tool Usage

Let's say you have completed work on the project, and are ready to submit, you would do the following:

lab46:~/src/SEMESTER/DESIG/PROJECT$ submit DESIG PROJECT file1 file2 file3 ... fileN

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

RUBRIC

I'll be evaluating the project based on the following criteria:

39:mpg0:final tally of results (39/39)
*:mpg0:input via gamepad interface [8/8]
*:mpg0:proper bounds checking [13/13]
*:mpg0:display of snake and objects [9/9]
*:mpg0:custom build script and resources [9/9]

Pertaining to the collaborative authoring of project documentation

  • each class member is to participate in the contribution of relevant information and formatting of the documentation
    • minimal member contributions consist of:
      • near the class average edits (a value of at least four productive edits)
      • near the average class content change average (a value of at least 1024 bytes (absolute value of data content change))
      • no zero-sum commits (adding in one commit then later removing in its entirety for the sake of satisfying edit requirements)
    • adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
    • content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
      • no contributions, co-efficient is 0.50
      • less than minimum contributions is 0.75
      • met minimum contribution threshold is 1.00

Additionally

  • Solutions not abiding by spirit of project will be subject to a 50% overall deduction
  • Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
  • Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
  • Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
haas/spring2024/comporg/projects/mpg0.txt · Last modified: 2024/01/22 08:15 by 127.0.0.1