User Tools

Site Tools


haas:fall2023:discrete:projects:mpg0

Corning Community College

CSCS2330 Discrete Structures

PROJECT: Make Pong Go (MPG0)

OBJECTIVE

Read through pertinent technical specifications and guides for Vircon32, and build a functioning pong 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 website and Github has lots of great references that will help you complete this project and familiarize yourself more with the Vircon32 system and it's tools.

- The Github repository “Vircon32Documents” guides for the C compiler, The C language, how the console works, and how to make games for Vircon32.

- The Github repository “ConsoleSoftware” includes tutorials and test programs that you can walk through and inspect. Doing so will reveal how some different aspects are made with their example functions and assets.

- The Vircon32 website itself has a “C API reference” tab under Documents that is a complete reference for all functions included in the C compiler used for Vircon32. This will show you what is included in each file of the standard library, and how the functions behave.

Game Mechanics

Game loop
Sprites

Sprites are two-dimensional graphic objects used in computer graphics, particularly video games. You can use something like a sprite editor to make the objects needed for this project.

Including Sprites In The Game

To include a sprite in the game cartridge you have to change the make.sh file to include the png. It should look something like this.

  echo
  echo Convert the PNG textures
  echo --------------------------
  png2vircon Texture.png -o obj/Texture.vtex || abort_build

There is no limit to the amount of pngs you can convert, however you also need to include the texture in the pong.xml file to have the texture show up in the cartridge.

    <textures>
        <texture path="obj\Texture1.vtex" />
        <texture path="obj\Texture2.vtex" />
    </textures>

after finishing this, you should be good to use the pngs in your code, Rom texture numbers begin with 0, so selecting texture 0 would result in Texture1.vtex

  select_texture( 0 ); //selects the Texture1 set in the .xml file
  select_region( 0 );  // Sets the selected texture region to the given texture ID
  define_region( int min_x, int min_y, int max_x, int max_y, int hotspot_x, int hotspot_y );

These x and y values correspond to the pixel coordinates in the selected texture. Once the region is defined it can then be drawn to the screen.

Gamepad input

The game controls can be modified in the Config-Controls.xml file in the emulator file. To get game input in we must store the X and Y direction of the controls even if you do not intend to use them.

  #include "input.h"
  int directionX, directionY;
 
  gamepad_direction( &directionX, &directionY );
  paddle += directionY;
Bounds checking

One key factor of pong is that the ball will and should reflect off the top and bottom of the screen and pass through the left or right sides of the screen. The top and bottom edges can be considered walls while the left and right can be considered goals.

It may be wise to consider setting a few variables such as wallWidth and paddleY. Using said variables in conjunction with screen_height you'll be able to prevent your paddles from phasing through both top and bottom walls.

The same can be said for the ball, with a variable aptly named ballY you could prevent the ball from phasing through the walls.

Handling motion

Motion from the player will be used from controller input. You have to be able to check if the player is holding/pressing the keys that relate to up and down on the y axis. If the key is pressed, then you will move the sprite up or down on the y axis at a speed you set through a variable that gets added to the sprites location each loop.

Motion not from the player can be activated on your own set conditions. such as using bool to activate or deactivate the ball and if functions to run through a set of code if the ball is active or not.

Score Display

To display a score, you'll need to declare a couple integers first to mathematically keep track of each player's points.

#int [name of variable for paddle 1];
int [name of variable for paddle 2];

While here, you're also going to need to declare a couple arrays (we'll need them for later). The arrays don't need to be too long, for our purposes 10 is large enough, just that we'll need 2 arrays (one per paddle). Keep in mind Vircon32 has a different format for arrays compared to other C code:

type[array size] name

Drawing the score on the display is simple, the process used in btt0's “Hello World” project mostly works here. However, you'll first need to convert the integer to a string, as Vircon32's print function can only print strings.

We'll need to make use of itoa() used from the string.h library. In order to convert the score integer to the score string, do:

#include "string.h"

itoa( [name of integer score], [name of array], [numerical base] ); 

In order to print out the score for this specific paddle, use the name of the array in the print function. To keep track of score, increment either paddle's score integer in your code that resets the arena upon each score.

 

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:

26:mpg0:final tally of results (26/26)
*:mpg0:input via gamepad interface [7/7]
*:mpg0:proper bounds checking [7/7]
*:mpg0:display of ball and paddles [6/6]
*:mpg0:some other enhancement [6/6]

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))
      • near the class content contribution average (a value of at least 1kiB)
      • 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/fall2023/discrete/projects/mpg0.txt · Last modified: 2023/08/24 13:52 by 127.0.0.1