Counterkart

How to 3D

Project: Counterkart

Counterkart

This semester you will learn more about computer graphics by implementing your own two-player, couch-competitive kart-racing game. We'll refer to the application as Counterkart in this specification. Feel free to adopt a different name in your implementation.

Counterkart has the following features:

As with all the renderers you write this semester, Counterkart is implemented in TypeScript with help from just a couple Node.js libraries: vite for bundling and cannon-es for physics. All other code is written by you.

Your instructor has designed this project after witnessing many semesters of unmet learning objectives, stress preceding due dates, and the overspecification that comes from automated grading. The following features of this project are an attempt to address these concerns.

One project, five milestones. Building your own game is no small endeavor. You've got to learn how design 3D models, assemble worlds, situate and respond to the viewer, control motion, and breathe animated life into your characters. The project has therefore been decomposed into five separate milestones. You'll enjoy the focus of building a single piece of software, but accomplish it in manageable stages.

Full credit when done. Each milestone comes with a list of requirements that you must meet to receive credit. You've been a student long enough to expect partial credit for partial work. Partial credit is nice way for you to salvage some points for something you've turned in, but it's got some problems. For one, it's pure fiction. If your instructor says A, B, and C are important, and you demonstrate only A, the instructor has to somehow decide what A is worth by itself. For two, assigning partial credit burns up time that your instructor would rather spend helping you achieve full credit. In this project, if a milestone asks you to complete A, B, C, that means they're all important. You won't get partial credit for only completing A. That sounds severe, but the good news is that you don't turn a milestone in until you've completed all the requirements. There aren't fixed due dates by which a milestone needs to be submitted. The policy is not no partial credit but rather full credit when done.

Submit on ready dates. Taking away due dates entirely is a recipe for disaster when life is full of other obligations that do have due dates. This project therefore is structured by a more flexible time constraint called a ready date, which is a day that you may choose to submit a milestone. You have seven ready dates across which you may scatter your submissions:

Only one milestone may be submitted per date. You can't, for example, submit all five milestones on the last ready date. Milestones don't have to be completed by a particular date, but they do need to be completed in order. You can miss any two of these dates and still submit all five milestones, but you shouldn't feel like you need to complete all five. If you try to submit a milestone that does not meet all the requirements, it will be rejected and you will have to wait until the next ready date to resubmit.

Read on for a specification of each milestone.

Milestone 1: 3D Models →