haas/fall2026/common/projects/gfoX.md
... ...
@@ -202,9 +202,8 @@ growing list of results.
202 202
As gfoX may be issued multiple times during the semester, each iteration
203 203
is to capture the following snapshot of data in its reporting results:
204 204
205
- * gfo0: start of semester through and including week 4 deliverables
206
- * gfo1: start of semester through and including week 8 deliverables
207
- * gfo2: start of semester through and including week 12 deliverables
205
+ * gfo0: start of semester through and including week 6 deliverables
206
+ * gfo1: start of semester through and including week 12 deliverables
208 207
209 208
You'll notice there is a two-week lag from the end of the sampling window
210 209
(gfo0 -> week 4) and when that project is due (gfo0 will be due alongside
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