User Tools

Site Tools


Sidebar

projects

wcp1 (due 20240828)
btt0 (due 20240904)
wcp2 (due 20240904)
pct0 (bonus; due 20240905)
pct1 (bonus; due 20240905)
pct2 (due 20240905)
abc0 (due 20240906)
msi0 (due 20240911)
pct3 (bonus; due 20240911)
wcp3 (due 20240911)
msi1 (due 20240918)
pct4 (due 20240918)
wcp4 (due 20240918)
dsr0 (due 20240926)
pct5 (bonus; due 20240926)
wcp5 (due 20240926)
gfo0 (due 20241002)
pct6 (due 20241002)
pnc0 (due 20241002)
wcp6 (due 20241002)
dsr1 (due 20241009)
pct7 (bonus; due 20241009)
wcp7 (due 20241009)
bwp1 (bonus; due 20241016)
pct8 (due 20241016)
pnc1 (due 20241016)
wcp8 (due 20241016)
pct9 (bonus; due 20241023)
pnc2 (due 20241023)
wcp9 (due 20241023)
gfo1 (due 20241030)
mag0 (due 20241030)
pctA (due 20241030)
wcpA (due 20241030)
mag1 (due 20241106)
pctB (bonus; due 20241106)
wcpB (due 20241106)
mag2 (due 20241113)
pctC (due 20241113)
wcpC (due 20241113)
pctD (bonus; due 20241120)
wcpD (bonus; due 20241120)
bwp2 (bonus; due 20241204)
gfo2 (due 20241204)
pctE (bonus; due 20241204)
wcpE (bonus; due 20241204)
EoCE (due 20241216)
haas:fall2024:discrete:projects:msi1

Corning Community College

CSCS2330 Discrete Structures

PROJECT: Make Space Invaders (MSI1)

OBJECTIVE

Convert your functional space invaders game from msi0 from the array backend to one using a singly-linked list that you implement.

EDIT

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

msi1

The primary difference between the last and current project is that instead of using arrays, linked lists are to be employed instead. Essentially, all instances of arrays in msi0 must now be retired in favor of the singly linked list. This game will utilize new struct attributes and functions to achieve this goal. The end product should feature ZERO arrays, and, if done correctly, one or more linked lists (pending designer preference).

malloc

You start with nothing, then there is the great sneeze! Or in this case the malloc! At this point you should all know that malloc is memory allocation. In the Joe O classes you may be familiar with the term Newed Up? It's essentially that.

Sprite* Node
Node = (Sprite*)malloc(sizeof(Sprite));

Congratulations you now have a Node! You might also find it useful to have a List so List struct and malloc that in the same manner.

Also, remember that whenever you allocate memory(malloc) you are also responsible for freeing that memory at the end of your program. You can do this by using

free(Node);

pointer arithmetic

With Lists and Nodes, unlike Arrays since elements are not stored contiguously, you can't simply add the size of the element to the address to reach the next. While it is faster to do it that way, this project is about Lists and thus we will do it this way.

Using Lists requires Structs but not any Struct will do, these Structs require a fancy maneuver called next whose type will be a pointer of the same name as the Struct

  • Example
struct Node {
  int data;
  Node* next;
};

Using the next property and assigning it to point at a new Node “once that's created” will in essence be your arithmetic. You can then use something akin to

Struct* current = NULL;
current = myList->start;
while( current != NULL ) {
  ...
  current = current->next;
}

This will get you through the entire length of your list if that were to be some objective of yours

node struct

To make your node struct, you need to take whatever you are making into a list, in this case your Sprite/Enemy/GameObject struct, and add a next pointer to it ie

struct Sprite {
   int X;
   int Y;
   bool Active;
};

will become

struct Sprite {
   int X;
   int Y;
   bool Active;
   Sprite *next;
};

list struct

Currently a list needs two things: A start and an End

struct List
{
   Sprite *start;
   Sprite *end;
}

If you would like to run through a list to get the values. A good idea would be to make a temp * and have it start and end at null. For example.

// Before the while loop.
temp = start;
while (temp != null)
{
// Do a thing

// After the thing
temp = temp * next
}

Always make sure that the end has a NULL or else it will loop forever!

singly-linked list

A singly linked list is a group of nodes that each have some way of finding the next node in the list.

space invaders

The original Space Invaders was a game where the player character was positioned at the bottom of the screen and moved solely along the x-axis. You would fight enemies who would be organized in rows and columns at the top, they would also move along the a-axis and move towards the player by one row when an alien made contact with the left and right “walls” respectively. The enemies could also shoot at the player at random. The player, in their own defense, had shields to protect them from the enemies' advance. The shield had its own health value, and as the enemies would shoot at the player, the shields would eat up the damage to spare the player but deteriorate as time went on. Eventually, they would disappear entirely. The player could move and shoot back at the enemies. This is Space Invaders in a nutshell.

The objective is to create your own personal twist on Space Invaders. This could be introducing a new theme, or mechanics, while remaining true to the original. Enemy array formation / random attacks, player shooting, hit detection, and custom structs are a MUST.

You could add something like multiple lives, dropped by enemies when killed, allowing players to continue on even after losing their first life. Or have enemies that can take multiple hits. Another option is movement or bullet speed upgrades, dropped by certain enemies.

It also would not hurt to consider having custom sprites, sounds, music, and/or a score for the player.

You can get a feel for how the game is meant to be played https://freeinvaders.org/

 

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:

52:msi1:final tally of results (52/52)
*:msi1:singly linked list implemented and used [26/26]
*:msi1:functioning space invaders with working lists [26/26]

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/fall2024/discrete/projects/msi1.txt · Last modified: 2024/09/02 14:27 by 127.0.0.1