haas/fall2026/cprog/projects/fwg3.md
... ...
@@ -0,0 +1,219 @@
1
+# CSCS1320 C/C++ Programming
2
+
3
+# PROJECT: FUN WITH GAMES (fwg3)
4
+
5
+## OBJECTIVE
6
+
7
+Using your Vircon32 build and installation from fwg0, and the game
8
+foundations from fwg1 and fwg2, implement your own 2D game of your
9
+choosing, this time organizing your game's data with **structs**. Rather
10
+than tracking each game object as a scattering of loose variables,
11
+you will group related data (position, velocity, size, state) into
12
+well-defined struct types, and start utilizing custom functions to assist
13
+in game operations.
14
+
15
+The choice of game is up to you. Some ideas:
16
+
17
+ * Space Invaders-style shooter (player ship, bullets, enemies)
18
+ * Frogger-style crossing game (frog, lanes of vehicles/logs)
19
+ * Asteroids-style (ship, rocks, shots)
20
+ * Snake, Pac-Man-style maze chase, Flappy-style side scroller
21
+ * Catch/dodge game (things fall from the sky, you catch or avoid them)
22
+ * something entirely your own: be creative!
23
+
24
+Your game should be simple enough to finish, but have enough going on
25
+that it is clearly a game: something the player controls, something that
26
+reacts or opposes them, and a way to win, lose, or score.
27
+
28
+## PROGRAM
29
+
30
+You are to write a Vircon32 C game that:
31
+
32
+ * has a player-controlled object, moved via the gamepad
33
+ * has at least one other kind of game object (enemy, obstacle,
34
+ projectile, pickup, etc.) that acts on its own
35
+ * detects collisions between objects, with a meaningful result
36
+ * keeps a score (or lives, or timer) displayed or otherwise tracked
37
+ * has a win and/or lose condition (even if it simply resets)
38
+ * is built around structs:
39
+ * define at least TWO distinct struct types in your game,
40
+ for example a player type and an enemy/projectile type
41
+ * each struct holds that object's state: position, velocity, size,
42
+ and an active/alive flag at a minimum (as relevant to your game)
43
+ * create struct variables for your game objects
44
+ * create and utilize functions that perform some game operation, such
45
+ such as `update_player()`, `draw_enemy()`, or `collide()`
46
+
47
+NOTE: you are free to use arrays of structs if your game calls for it
48
+(many enemies, many bullets), but the emphasis of this project is on the
49
+design and use of the structs themselves.
50
+
51
+NOTE: the first gamepad by default is mapped to the keyboard
52
+
53
+## STRUCT REMINDERS
54
+
55
+A quick example of the sort of thing we are after (yours will differ):
56
+
57
+```
58
+struct point
59
+{
60
+ int x;
61
+ int y;
62
+};
63
+
64
+struct sprite
65
+{
66
+ struct point pos; // where it is on screen
67
+ struct point vel; // how it moves each frame
68
+ int width;
69
+ int height;
70
+ int active; // is it currently in play?
71
+};
72
+
73
+void move_sprite(struct sprite *s)
74
+{
75
+ s->pos.x += s->vel.x;
76
+ s->pos.y += s->vel.y;
77
+}
78
+```
79
+
80
+Remember: use the dot operator (`.`) with a struct variable, and the
81
+arrow operator (`->`) with a pointer to a struct.
82
+
83
+## CARTRIDGE BUILD PROCESS
84
+
85
+All of these steps can be automated with the use of the provided
86
+`Makefile` simply by typing `make` at the prompt.
87
+
88
+NOTE that with certain modifications, you'll first need to modify the XML
89
+file as appropriate.
90
+
91
+### COMPILE
92
+
93
+First step is to compile the C code, which can be done with the following
94
+command from the Vircon32 developer tools C compiler (`compile`):
95
+
96
+```
97
+yoursystem:~/src/SEMESTER/cprog/fwg3$ compile fwg3.c -o fwg3.asm
98
+```
99
+
100
+This compiles, or translates, the C code into Vircon32 assembly language
101
+code, which will then need to be assembled to machine code:
102
+
103
+### ASSEMBLE
104
+
105
+Once you've compiled your code successfully, you can use the Vircon32
106
+`assemble` DevTool to assemble the assembly:
107
+
108
+```
109
+yoursystem:~/src/SEMESTER/cprog/fwg3$ assemble fwg3.asm -o fwg3.vbin
110
+```
111
+
112
+### IMAGE CONVERSTION
113
+
114
+Any PNG images you'd like to use need to be converted to Vircon32 texture
115
+format via the `png2vircon` tool:
116
+
117
+```
118
+yoursystem:~/src/SEMESTER/cprog/fwg3$ png2vircon background.png -o background.vtex
119
+yoursystem:~/src/SEMESTER/cprog/fwg3$ png2vircon sprites.png -o sprites.vtex
120
+```
121
+
122
+Note that you'll also want to ensure the XML file has been updated to
123
+reference these textures:
124
+
125
+```
126
+ <binary path="fwg3.vbin" />
127
+ <textures>
128
+ <texture path="background.vtex" />
129
+ <texture path="sprites.vtex" />
130
+ </textures>
131
+```
132
+
133
+### AUDIO CONVERSION
134
+
135
+Should you have any WAV files you'd like to use need to be converted to
136
+the Vircon32 sound format via the `wav2vircon` tool:
137
+
138
+```
139
+yoursystem:~/src/SEMESTER/cprog/fwg3$ wav2vircon backgroundmusic.wav -o backgroundmusic.vsnd
140
+yoursystem:~/src/SEMESTER/cprog/fwg3$ wav2vircon soundfx.wav -o soundfx.vsnd
141
+```
142
+
143
+Note that you'll also want to ensure the XML file has been updated to
144
+reference these sounds:
145
+
146
+```
147
+ <sounds>
148
+ <sound path="backgroundmusic.vsnd" />
149
+ <sound path="soundfx.vsnd" />
150
+ </sounds>
151
+```
152
+
153
+### PACKING THE ROM
154
+
155
+Once all the components have been built, you can pack them together into
156
+a Vircon32 cartridge for use in the emulator via the `packrom` tool:
157
+
158
+```
159
+yoursystem:~/src/SEMESTER/cprog/fwg3$ packrom fwg3.xml
160
+```
161
+
162
+## SUBMISSION
163
+
164
+To be successful in this project, the following criteria (or their
165
+equivalent) must be met:
166
+
167
+ * Project must be submit on time, by the deadline.
168
+ * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
169
+ * Executed programs must display in a manner similar to provided output
170
+ * output formatted, where applicable, must match that of project requirements
171
+ * Processing must be correct based on input given and output requested
172
+ * Output, if applicable, must be correct based on values input
173
+ * Code must be nicely and consistently indented
174
+ * Code must be consistently written, to strive for readability from having a consistent style throughout
175
+ * Code must be commented
176
+ * Any "to be implemented" comments **MUST** be removed
177
+ * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted.
178
+ * Sufficient comments explaining the point of provided logic **MUST** be present
179
+ * No global variables (without instructor approval), no goto statements, no calling of main()!
180
+ * Track/version the source code in your private semester repository
181
+ * Submit a copy of your source code to me using the **submit** tool by the deadline.
182
+
183
+### SUBMIT TOOL USAGE
184
+
185
+Let's say you have completed work on the project, and are ready to
186
+submit, you would do the following:
187
+
188
+```
189
+lab46:~/src/SEMESTER/cprog/fwg3$ make submit
190
+```
191
+
192
+You should get some sort of confirmation indicating successful submission
193
+if all went according to plan. If not, check for typos and or locational
194
+mismatches.
195
+
196
+### RUBRIC
197
+
198
+I'll be evaluating the project based on the following criteria:
199
+
200
+```
201
+234:fwg3:final tally of results (234/234)
202
+*:fwg3:code modified to meet project specifications [26/26]
203
+*:fwg3:screenshot or video posted to class DISCORD of game running [26/26]
204
+*:fwg3:at least two distinct struct types defined and used [26/26]
205
+*:fwg3:structs hold object state (position, velocity, size, active) [26/26]
206
+*:fwg3:utilize some functions to perform various game actions [26/26]
207
+*:fwg3:working collision detection between game objects [26/26]
208
+*:fwg3:game has scoring (or lives/timer) and a win/lose condition [26/26]
209
+*:fwg3:game uses at least one texture and one sound [26/26]
210
+*:fwg3:code compiles, cartridge builds with no warning or error [13/13]
211
+*:fwg3:committed project related changes to private semester repo [13/13]
212
+```
213
+
214
+Additionally:
215
+
216
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
217
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
218
+ * 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
219
+ * 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